This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-devel] "kobject add failed"
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 3 May 2007 19:37:28 +0200
Delivery-date: Thu, 03 May 2007 10:36:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C25FD9E1.E5E0%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceNmT0esnMamshHQgCftANOeSweVQACJPy4AAAGsIAAAMJU7AAAcFqwAABf97AAAA0DMA==
Thread-topic: [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

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

>  -- Keir

Xen-devel mailing list