[Bug 271474] Possible to "lose" a tap(4) interface in a jail

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

            Bug ID: 271474
           Summary: Possible to "lose" a tap(4) interface in a jail
           Product: Base System
           Version: 13.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: misc
          Assignee: bugs@FreeBSD.org
          Reporter: freebsd@kumba.dev

So after some trial and error, I have discovered that it is possible to
literally "lose" a tap(4) interface inside of a jail during shutdown if the
conditions are right.  I am trying to run bhyve within a VNET jail, and thought
I would be OK to create 'tap0' inside the jail itself via /etc/rc.conf rather
than at the host level and passing it in via VNET.

This kinda works for the most part, but in the process of trying to work out
how to get bhyve to run inside of a jail, I had to start/stop the jail several
times.  In one of those instances, I forgot to run "bhyvectl --vm=foo
--destroy" before I ran "jail -r foojail".  The jail shutdown like it should,
then when I went to run "jail -c foojail", I noticed in the console output that
it was unable to create the 'tap0' interface because it already existed.

Dropping into the jail, 'ifconfig' showed no visible 'tap0' interface.  Same at
the host level.  Somewhere in kernel memory, though, there was a 'tap0'
interface with no way to get at it.  Doing a proper shutdown of the bhyve
instance did not release it, nor did restarting the jail.  Only a full system
reboot got things back to normal.

That's the problem description, anyways.  As for a fix, I honestly don't have a
good suggestion.  Starting and stopping of jails is really just being clever
with shell scripting in /etc/jail.conf, so it would be really hard to handle a
case where jail shutdown can catch a failure to stop an interface and return
that back to 'jail' and have it abort the shutdown.  For me, I decided to play
it safe and moved the creation of the tap(4) interface to the host level and
then just pass it to the jail as a vnet.interface parameter.

-- 
You are receiving this mail because:
You are the assignee for the bug.