[Bug 234985] kernel panic when destroying epair interface of vnet jail after using ifconfig inside the jail

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 234985
           Summary: kernel panic when destroying epair interface of vnet
                    jail after using ifconfig inside the jail
           Product: Base System
           Version: CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Keywords: panic, vimage
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: henno at schooljan.nl

Created attachment 201173
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=201173&action=edit
vnet_epair_test.sh: Script for reproducing vnet jail epair destroy panic

When creating an epair interface pair for a VNET enabled jail, and then using
ifconfig within this jail, the kernel will often panic later when destroying
the jail and finally the epair interface again. However this will not happen
when ifconfig is not used within the jail or when it is used outside of the
jail, and it will not happen every time. But when it happens, it always happens
at the moment the ifconfig destroy epair is done.

This has been tested and reproduced on 12.0-RELEASE-p2 and 13.0-CURRENT
r343065.

I have included a script which reproduces this. It is based on an older script
which tested for a similar issue, and I changed it so that it will test this
999 times, with an optional 'panic' argument for triggering the critical
ifconfig command that makes the difference here.
With the panic argument it will reliably panic my system on every run, at worst
after a couple hundred loops or so (perhaps it is some kind of race
condition?). Without the panic argument the system never crashes.

I have also included the kernel trace I obtained from the 13.0-CURRENT system,
and can supply a kernel memory dump if you need it.

So what side effect would this innocent ifconfig command have that it affects a
later ifconfig destroy command? It also does not matter which interface you
query with it, like when you run ifconfig lo0 or something else, as long as I
use ifconfig at least once I can trigger this.

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