From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: DomU crash during migration when suspendingsource domain Date: Wed, 14 Feb 2007 15:43:02 +0000 Message-ID: References: <342BAC0A5467384983B586A6B0B3767104A6A878@EXNA.corp.stratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <342BAC0A5467384983B586A6B0B3767104A6A878@EXNA.corp.stratus.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: "Graham, Simon" , Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 14/2/07 15:08, "Graham, Simon" wrote: > Let me try that out here and get back to you -- I can submit a patch > with this specific fix in if it solves the problem. > > Since, as you say, this is just one aspect of dealing with hot plugging > completely different processors, I somehow feel that a point fix like > this wouldn't be accepted upstream and instead we'd need to think about > a more complete solution (If, indeed, this is feasible). Possibly true. In fact I think if you fix that function then you're going to die in kobject_unregister() instead. The loop cache_remove_dev() is simply bogus in your case since num_cache_leaves cannot be trusted. A broader set of fixes might get accepted upstream because cache_add_dev() can fail for other reasons too (at least out-of-memory) and any such failure will cause cache_remove_dev() to barf. But it's not such a simple thing to fix and it does not solve the general problem for us. -- Keir