[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Thu, 3 May 2007 19:19:07 +0200
  • Delivery-date: Thu, 03 May 2007 10:17:55 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceNmT0esnMamshHQgCftANOeSweVQACJPy4AAAGsIAAAMJU7AAAcFqw
  • Thread-topic: [Xen-devel] "kobject add failed"


> -----Original Message-----
> From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] 
> Sent: 03 May 2007 18:03
> To: Petersson, Mats; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] "kobject add failed"
> On 3/5/07 17:45, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:
> > I haven't seen it before. Any idea why this would happen 
> now, and not
> > before?
> Because now you are doing two save/restores in a loop at the 
> same time.
> > Why would it happen only when doing two save/restore sessions (of
> > different domains of course) on the same machine (which I have done
> > before - but not that recently).
> It looks like there might be a race in 
> drivers/net/tun.c:tun_set_iff(). Two
> invocations of ioctl(TUNSETIFF) can both resolve "tap%d" to 
> "tap0" (because
> both observe that tap0 is not registered). The second one to execute
> register_netdevice() then bugs out because the interface 
> already exists!

Ok, I'll try to track that down - not sure I'm at home figuring how to
fix it, but at least I can probably prove that it is re-entrancy in the
function or not. 

It will have to wait until Wednesday tho', as I'm off work tomorrow and
Tuesday (and for those not familiar with UK holidays, Monday is a
"bank-holiday", meaning "public holiday"). 

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

>  -- Keir
> > I got a second backtrace like that. I've since tried to avoid it by
> > removing the (unnecessary) vif= in the setup of the 
> simple-guest (it's
> > got no code to deal with network devices anyway). 

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.