From mboxrd@z Thu Jan  1 00:00:00 1970
From: Juergen Gross <jgross@suse.com>
Subject: Re: Wrong cpupool handling
Date: Wed, 12 Nov 2014 11:25:14 +0100
Message-ID: <5463358A.7000108@suse.com>
References: <19147765.FEreuxd8Ya@amur> <54621B4D.7000408@suse.com>
	<3016118.gIEEAtXxHA@amur>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <3016118.gIEEAtXxHA@amur>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 11/12/2014 10:53 AM, Dietmar Hahn wrote:
> 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.

Thanks. Can I add your "tested-by:"?

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

The scheduler should never change cpupool owned data. The cpupool
pointer is domain data, so changing this is okay.


Juergen