RE: [Xen-devel] "kobject add failed"

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

> -----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... ;-)

--
Mats



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