RE: [Xen-devel][PATCH][RFC] "kobject add failed" Suggested workaround.

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----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
Description: patch.try_tap_3_times

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel