From: Juergen Gross <jgross@suse.com>
To: Dario Faggioli <dario.faggioli@citrix.com>,
xen-devel@lists.xenproject.org
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy
Date: Fri, 15 Jul 2016 12:36:18 +0200 [thread overview]
Message-ID: <5788BCA2.4020404@suse.com> (raw)
In-Reply-To: <1468577660.13039.78.camel@citrix.com>
On 15/07/16 12:14, Dario Faggioli wrote:
> On Fri, 2016-07-15 at 11:38 +0200, Juergen Gross wrote:
>> Hmm, are you aware of commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a
>> which explicitly moved cpupool_rm_domain() at the place where you are
>> removing it again? Please verify that the scenario mentioned in the
>> description of that commit is still working with your patch.
>>
> Sorry, but I only partly see the problem.
>
> In particular, I'm probably not fully understanding, from that commit
> changelog, what is the set of operations/command that I should run to
> check whether or not I reintroduced the issue back.
You need to create a domain in a cpupool and destroy it again while
some dom0 process still is holding a reference to it (resulting in a
zombie domain). Then try to destroy the cpupool.
>
> What I did so far is as follows:
>
> root@Zhaman:~# xl cpupool-list
> Name CPUs Sched Active Domain count
> Pool-0 12 credit y 1
> Pool-credit 4 credit y 1
> root@Zhaman:~# xl list -c
> Name ID Mem VCPUs State Time(s) Cpupool
> Domain-0 0 1019 16 r----- 34.5 Pool-0
> vm1 1 4096 4 -b---- 9.7 Pool-credit
> root@Zhaman:~# xl cpupool-cpu-remove Pool-credit all
> libxl: error: libxl.c:6998:libxl_cpupool_cpuremove: Error removing cpu 9 from cpupool: Device or resource busy
> Some cpus may have not or only partially been removed from 'Pool-credit'.
> If a cpu can't be added to another cpupool, add it to 'Pool-credit' again and retry.
> root@Zhaman:~# xl cpupool-list -c
> Name CPU list
> Pool-0 0,1,2,3,4,5,10,11,12,13,14,15
> Pool-credit 9
> root@Zhaman:~# xl shutdown vm1
> Shutting down domain 1
> root@Zhaman:~# xl cpupool-cpu-remove Pool-credit all
> root@Zhaman:~# xl cpupool-list -c
> Name CPU list
> Pool-0 0,1,2,3,4,5,10,11,12,13,14,15
> Pool-credit
>
> If (with vm1 still in Pool-credit), I do this, it indeed fails:
>
> root@Zhaman:~# xl shutdown vm1 & xl cpupool-cpu-remove Pool-credit all
> [1] 3275
> Shutting down domain 2
> libxl: error: libxl.c:6998:libxl_cpupool_cpuremove: Error removing cpu 9 from cpupool: Device or resource busy
> Some cpus may have not or only partially been removed from 'Pool-credit'.
> If a cpu can't be added to another cpupool, add it to 'Pool-credit' again and retry.
> [1]+ Done xl shutdown vm1
> root@Zhaman:~# xl cpupool-list -c
> Name CPU list
> Pool-0 0,1,2,3,4,5,10,11,12,13,14,15
> Pool-credit 9
>
> But that does not look too strange to me, as it's entirely possible
> that the domain has not been moved yet, when we try to remove the last
> cpu. And in fact, after the domain has properly shutdown:
>
> root@Zhaman:~# xl cpupool-cpu-remove Pool-credit all
> root@Zhaman:~# xl cpupool-list
> Name CPUs Sched Active Domain count
> Pool-0 12 credit y 1
> Pool-credit 0 credit y 0
>
> And in fact, looking at the code introduced by that commit, the
> important part, to me, seems to be the moving of the domain to
> cpupool0, which is indeed the right thing to do. OTOH, what I am seeing
> and fixing, happens (well, could happen) all the times, even when the
> domain being shutdown is already in cpupool0, and (as you say yourself
> in your changelog) there not such issue as removing the last cpu of
> cpupool0.
>
> What am I missing?
The domain being a zombie domain might change the picture. Moving it to
cpupool0 was failing before my patch and it might do so again with your
patch applied.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-15 10:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 16:17 [PATCH v2 0/2] xen: cpupool (small) improvement and (latent) bug fix Dario Faggioli
2016-07-14 16:18 ` [PATCH v2 1/2] xen: fix a (latent) cpupool-related race during domain destroy Dario Faggioli
2016-07-14 17:08 ` Andrew Cooper
2016-07-15 9:38 ` Juergen Gross
2016-07-15 10:14 ` Dario Faggioli
2016-07-15 10:36 ` Juergen Gross [this message]
2016-07-15 11:52 ` Dario Faggioli
2016-07-15 12:52 ` Juergen Gross
2016-07-15 14:23 ` Dario Faggioli
2016-07-18 14:03 ` Dario Faggioli
2016-07-18 14:09 ` Juergen Gross
2016-07-28 17:29 ` Dario Faggioli
2016-08-03 11:54 ` George Dunlap
2016-08-03 12:27 ` George Dunlap
2016-07-14 16:18 ` [PATCH v2 2/2] xen: cpupool: small optimization when moving between pools Dario Faggioli
2016-07-15 9:39 ` Juergen Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5788BCA2.4020404@suse.com \
--to=jgross@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.