[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel][PATCH][RFC] "kobject add failed" Suggested workaround.
> -----Original Message----- > From: Petersson, Mats > Sent: 14 May 2007 17:37 > To: Petersson, Mats; Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xen-devel] "kobject add failed" > > > -----Original Message----- > > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx > > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of > > Petersson, Mats > > Sent: 03 May 2007 18:37 > > To: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxx > > Subject: 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... > > Just to get back to this rather old subject (I got > side-tracked with the "stuff left in xenstore" problem last > week), here's the comment for register_netdevice: > > /** > * register_netdevice - register a network device > * @dev: device to register > * > * Take a completed network device structure and add it > to the kernel > * interfaces. A %NETDEV_REGISTER message is sent to the > netdev notifier > * chain. 0 is returned on success. A negative errno > code is returned > * on a failure to set up the device, or if the name is > a duplicate. > * > * Callers must hold the rtnl semaphore. You may want > * register_netdev() instead of this. > * > * BUGS: > * The locking appears insufficient to guarantee two > parallel registers > * will not get the same name. > */ > > So it seems like there's a problem using the mutex-locking to > prevent a name-collision. > > I don't know if I should pursue this... I presume that if it > was real trivial to fix, it would have been fixed already... ;-) Would a patch like the attached be a valid workaround for this problem? -- Mats > > -- > Mats Attachment:
patch.try_tap_3_times _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |