From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: "kobject add failed" Date: Thu, 03 May 2007 18:03:23 +0100 Message-ID: References: <907625E08839C4409CE5768403633E0B018E1CBF@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0B018E1CBF@sefsexmb1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Petersson, Mats" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 3/5/07 17:45, "Petersson, Mats" 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! 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. -- 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).