Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jan 2019 00:57:34 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 234985] kernel panic when destroying epair interface of vnet jail after using ifconfig inside the jail
Message-ID:  <bug-234985-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234985

            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@FreeBSD.org
          Reporter: henno@schooljan.nl

Created attachment 201173
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D201173&action=
=3Dedit
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 usi=
ng
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 hap=
pens
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 scr=
ipt
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 w=
orst
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 syst=
em,
and can supply a kernel memory dump if you need it.

So what side effect would this innocent ifconfig command have that it affec=
ts 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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234985-227>