[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] "kobject add failed"
> -----Original Message----- > From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] > Sent: 03 May 2007 18:27 > To: Petersson, Mats; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] "kobject add failed" > > > > > On 3/5/07 18:19, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote: > > >> However, the invocation of tun_set_iff() is wrapped in > >> rtnl_lock()/unlock() > >> so should be concurrency safe. Still, this is where I would > >> concentrate my > >> search if I were you. > > > > Indeed, the tun_set_iff() is protected by rtnl_lock/unlock()... Any > > reason to believe that doesn't work? > > Your crash report. :-) > > However tun_set_iff() is not in the oops backtrace... Perhaps > I'm wrong > about which ioctl is being executed, or the path taken > through the Linux > kernel. According to my dump of the tun.o object file, "tun_set_iff" is inlined into tun_chr_ioctl(), so it's no real surprise it's not in the call-stack... > > However, it definitely does look like a lack of locking > around picking a > device name and registering it. I'm fairly confident that > this will turn out > to be the problem. You might want to add some tracing to the > kernel to find > out what paths you take during qemu-dm startup (this might > cause the race > not to happen any more, but you can remove the tracing once > you know which > functions you should be staring at). I'll look at it on Wednesday. -- Mats > > -- Keir > > > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |