From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: "kobject add failed" Date: Thu, 03 May 2007 18:26:41 +0100 Message-ID: References: <907625E08839C4409CE5768403633E0B018E1CC4@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0B018E1CC4@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 18:19, "Petersson, Mats" 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. 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). -- Keir