Change Details

Currently, and even historically (as I've recently determined), if_free can return without the interface having actually been freed. If we're in the middle of an if_ioctl handler, for instance, destruction is deferred until the ioctl handling is complete. This adds a post-free handler, if_freed, that takes the softc associated with the ifnet and invokes it after the ifnet's actually gone away. Drivers can then use it to safely cleanup softc state rather than ad-hoc hacks to workaround the potential race between ioctl/destroy. The tuntap(4) conversion to this model has been added to this diff as an example, but I can spot similar changes being needed in bridge/gif/vxlan at a minimum. I'd like to move the callback to the end and burn an ispare for MFC to at least stable/12 and maybe stable/11, as I'm sure there are other places the current situation can bite us and it'd be a good idea to clean it up.

This pushes us towards a mode of operation similar to other teardown routines, where we're guaranteed to be free of clashing operations after if_detach/ether_ifdetach returns. The current version of this starts to touch on related vnet issues, as well- ensuring that we block on detach if a vnet's already started shutdown until the ifnet's been properly rehomed to the parent vnet, and making sure any in-progress if_vmove is finished and blocked prior to detaching. Not addressed here is that a vnet can commence shutdown while we were already in the middle of if_detach_internal and the vnet state can get torn down partially, leading to a panic in in_ifdetach. The read of ifp->if_vnet->vnet_shutdown has been deferred until as late as possible in if_detach_internal, with the hopes of minimizing this race window... but it really needs proper resolution.

Currently, and even historically (as I've recently determined)This pushes us towards a mode of operation similar to other teardown routines, if_free can return without the interface having actually been freed. If we're in the middle of an if_ioctl handlerwhere we're guaranteed to be free of clashing operations after if_detach/ether_ifdetach returns. The current version of this starts to touch on related vnet issues, for instanceas well- ensuring that we block on detach if a vnet's already started shutdown until the ifnet's been properly rehomed to the parent vnet, destruction is deferred until the ioctl handling is completeand making sure any in-progress if_vmove is finished and blocked prior to detaching. This adds a post-free handler, if_freedNot addressed here is that a vnet can commence shutdown while we were already in the middle of if_detach_internal and the vnet state can get torn down partially, that takes the softc associated with the ifnet and invokes it after the ifnet's actually gone awayleading to a panic in in_ifdetach. Drivers can then use it to safely cleanup softc state rather than ad-hoc hacks to workaround the potential race between ioctl/destroy. The tuntap(4) conversion to this model has been added to this diff as an exampleThe read of ifp->if_vnet->vnet_shutdown has been deferred until as late as possible in if_detach_internal, but I can spot similar changes being needed in bridge/gif/vxlan at a minimum. I'd like to move the callback to the end and burn an ispare for MFC to at least stable/12 and maybe stable/11,with the hopes of minimizing this race window... as I'm sure there are other places the current situation can bite us and it'd be a good idea to clean it upbut it really needs proper resolution.