On Sun, Jul 22, 2007 at 09:07:59AM +1200, Andrew Thompson wrote: > On Sat, Jul 21, 2007 at 08:38:59PM +0200, Attilio Rao wrote: > > 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. > > > Please test this patch. One more time with the file attached.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:15 UTC