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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286179

--- Comment #28 from Zhenlei Huang <[email protected]> ---
(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.