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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
