Am Mittwoch 12 November 2014, 11:25:14 schrieb Juergen Gross: > 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:"?
Sorry forgot it! Tested-by: Dietmar Hahn <dietmar.h...@ts.fujitsu.com> > > > 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 > -- Company details: http://ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
