Date: Fri, 20 Jan 2017 22:18:05 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 216304] Adding xn0 to bridge0 causes kernel panic Message-ID: <bug-216304-8-Izem86KcfC@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216304-8@https.bugs.freebsd.org/bugzilla/> References: <bug-216304-8@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 the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216304-8-Izem86KcfC>