[Bug 286179] Passing a vlan interface to a vnet jail result in a stuck dying state

[email protected]
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286179

--- Comment #30 from Peter Ganzhorn <[email protected]> ---
Thank you very much for your explainations!

I don't use any drivers from ports, so my igb driver is the one from the
kernel.
That idea of a difference between virtual and 'real' interfaces probably wasn't
correct and just a wild guess.

I recall using ifconfig to assign an ip address to the igb interface in the
jail, but I am not sure if I actually physically connected it to a network.
If it never received any traffic, isc_rxd_pkt_get may have returned without an
error causing CURVNET_RESTORE() to be called in iflib_rxeof()? I probably
should have made sure to test with traffic...
The port of the X710 I created the virtual function on was definitely connected
and therefore received traffic.

After your explanation of the sequence I understand you beeing skeptical now.
If the refcount needs to reach zero before actually beginning the teardown of
the vnet, my patch shouldn't have made a difference if there is another
(earlier) issue at hand.

I will try to do some tests with different configurations for the jail
filesystem and share what causes the jail to get stuck and if/what (e.g.
forcefully unmounting) will let it finally stop or not.
Hopefully that will help to narrow down where a reference may be held.


And finally: I think I created a situation while testing where the dataset was
set jailed=on and delegated to the jail.
Still, it was mounted on the host and visible with zfs list at the same time.
I will try to recreate that configuration and share it with you. I didn't keep
copies of all the different configurations I tested with...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.