[Bug 216304] Adding xn0 to bridge0 causes kernel panic

[bugzilla-noreply at freebsd.org]

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

Kristof Provost <kp at freebsd.org> changed:

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

--- Comment #2 from Kristof Provost <kp at 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_ioctl()
calls xs_rm(xenbus_get_node(dev), "feature-gso-tcp4"), which tries to compose 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 warns us
about this.

If we're unlucky enough to actually try to acquire the bridge lock from another
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 because
he touched the xen-netfront code at some point.

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

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