https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216304
Kristof Provost <k...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roy...@freebsd.org
--- Comment #2 from Kristof Provost <k...@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 the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
