Date: Wed, 22 Apr 2026 20:37:52 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 286179] Passing a vlan interface to a vnet jail result in a stuck dying state Message-ID: <bug-286179-7501-gyK0pHSn50@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-286179-7501@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286179 --- Comment #28 from Zhenlei Huang <zlei@FreeBSD.org> --- (In reply to Peter Ganzhorn from comment #26) > The following if_input() in iflib.c looks suspicious to me. I expect the CURVNET_RESTORE() run too early. Well this should be another issue. ``` CURVNET_RESTORE(); /* make sure that we can refill faster than drain */ for (i = 0, fl = &rxq->ifr_fl[0]; i < sctx->isc_nfl; i++, fl++) retval |= iflib_fl_refill_all(ctx, fl); if (mh != NULL) { if_input(ifp, mh); DBG_COUNTER_INC(rx_if_input); } ``` > The lines you mentioned also caught my eye, you may very well be up to something > there as well. My understanding of the code isn't good enough for a clear opinion in > my own though. Actually iflib(4) calls ether_ifattach() to assign ether_input() as the input routine. So if_input(ifp, mh) will calls ether_input() which has set the curvnet correctly. > As far as I understood the CURVNET_SET was introduced when pfil was to be used in > the code and wasn't required for anything else. I looks bad smell to spread CURVNET_SET() in the drivers. The vnet ( virtual net ) is a concept of the net stack, which the drivers should be noob about it. If things go right, a leaking curvnet shall make no differences, given vnet-aware components ( say ether_input() ) will handle it correctly. > The only thing I can tell for sure is that the addition of the missing > CURVNET_RESTORE() definitely had an impact on the returning of the network interface > to the host. > This works rock solid now and failed almost always before. That is the part puzzling me. I see no reasons it can have any impact. Or there're something else I'm missing. We need a strong reason why it fails without it, why that fixes, otherwise other developers will get confused. That is a reason why I removed the `PR: <286179>` in the commit message. I'm open to add `PR: <286179>` when MFCing the commit to stable/15 before 15.1-BETA1. Still we need a strong reason why it fixes. I'm not sure the underlaying reason can be spotted as I can not repeat. I have igc(4) which is iflib(4) based to test with. I can help if you want to spot the underlaying reason. > I noticed a zfs dataset that is jailed can be kept available/manageable and mounted > on the host while the jail is running while testing different configuration options. I'm not expert on ZFS, but that sounds wrong to me. Can you please share the steps ? > Is that intended to be actually possible or should the dataset become invisible to > the host while being delegated to a jail? `zfs jail foo somedataset` let the jail foo to handle the dataset. So in the jail you can list / mount / umount / set properties as needed. But that does not mean the dataset is invisible to the host, say if you want to **revoke** via `zfs unjail` ? -- You are receiving this mail because: You are on the CC list for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-286179-7501-gyK0pHSn50>