Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jan 2017 22:18:05 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-amd64@FreeBSD.org
Subject:   [Bug 216304] Adding xn0 to bridge0 causes kernel panic
Message-ID:  <bug-216304-6-RBhwWRNFIb@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-216304-6@https.bugs.freebsd.org/bugzilla/>
References:  <bug-216304-6@https.bugs.freebsd.org/bugzilla/>

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

Kristof Provost <kp@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |royger@freebsd.org

--- Comment #2 from Kristof Provost <kp@freebsd.org> ---
I think what happens here is that the bridge code (through bridge_ioctl_add=
()
calls the xen driver's ioctl() handler for SIOCSIFCAP, which through xn_ioc=
tl()
calls xs_rm(xenbus_get_node(dev), "feature-gso-tcp4"), which tries to compo=
se a
string with the sbuf functions, which use a M_WAITOK allocation.

That means that we can end up sleeping (because malloc(M_WAITOK)) with the
bridge lock (a standard mutex) held.
That violates locking rules, by sleeping with a mutex held, so WITNESS warn=
s us
about this.

If we're unlucky enough to actually try to acquire the bridge lock from ano=
ther
thread (say because we want to transmit a packet) we can end up panic()ing.

It's not obvious to me how this can be fixed however. I'm cc-ing royger bec=
ause
he touched the xen-netfront code at some point.

Perhaps we can allocate the strings the xs_rm() needs at device initialisat=
ion
time, but that would require the result of xenbus_get_node(dev) to be const=
ant,
and I don't know if that's a valid assumption.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



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