From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dietmar Hahn Subject: Re: Wrong cpupool handling Date: Wed, 12 Nov 2014 10:53:24 +0100 Message-ID: <3016118.gIEEAtXxHA@amur> References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54621B4D.7000408@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: Juergen Gross List-Id: xen-devel@lists.xenproject.org Am Dienstag 11 November 2014, 15:21:01 schrieb Juergen Gross: > Hi again, > > On 11/11/2014 01:18 PM, Dietmar Hahn wrote: > > Hi list, > > > > When creating a cpupool, starting and destroying a guest within this pool, > > then removing this pool doesn't work because of EBUSY. > > > > It seems the cause of this behavior is the commit > > bac6334b51d9bcfe57ecf4a4cb5288348fcf044a. > > > > In domain_kill() the function sched_move_domain() gets called changing the > > d->cpupool pointer to the new cpupool without incrementing/decrementing the > > counters "n_dom" of the new/old cpupool. > > > > This leads to decrementing the wrong cpupool0->n_dom counter when > > cpupool_rm_domain() gets called at the end and my own cpupool can't be > > destroyed because n_dom = 1! > > > > I don't have a fast patch because I'am not enough familiar with the code > > this time but I think it should be fixed for 4.5. > > Please discard previous patch, try this one. Yes this patch works. But I think in general a better solution would be to have the changing of the cpupool pointer in sched_move_domain() together with the increment/decrement of the counters but I see the locking problem. Thanks. Dietmar. > > Juergen > -- Company details: http://ts.fujitsu.com/imprint.html