Date: Sat, 21 Jul 2007 20:38:59 +0200 From: Attilio Rao <attilio@FreeBSD.org> To: Doug Rabson <dfr@rabson.org> Cc: current@freebsd.org Subject: Re: if_bridge crash Message-ID: <46A252C3.5050804@FreeBSD.org> In-Reply-To: <200707211925.59698.dfr@rabson.org> References: <200707211925.59698.dfr@rabson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > I've been using if_bridge and if_tap to join various qemu virtual > machines onto my local network. I use this script to set up the bridge: > > ifconfig bridge0 create > ifconfig tap0 create > ifconfig bridge0 addm vr0 addm tap0 up > > I had forgotten what stupid mac address qemu had made up for its > interface and I needed to adjust my dhcpd config so I typed 'ifconfig > bridge addr' to list the addresses on the bridge and got an instant > panic. Qemu was not running at this point. The kernel address where it > crashed was good - it was the userland address which faulted. > > The crash was in generic_copyout+0x36 called from bridge_ioctl+0x1ae. I > took a look at the code and as far as I can make out, trap() got a bit > confused and managed to ignore the pcb_onfault marker left by copyout. > Its hard to tell exactly what happened since the damn compiler has > optimised the crap out of the code there. > > As far as I can see, the bridge code is calling copyout with a mutex > held. Is that allowed? It doesn't sound like it should be allowed but > I'm not quite up-to-date on that aspect of the current kernel api. Since a copyout() can generate a page fault (which can let the thread sleep) it is not allowed to mantain neither a blockable lock (mutex, rwlock) or a spinlock over a copyout. In the case the lock is a sx or lockmgr it is allowed. Attilio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46A252C3.5050804>