On 18/12/15 15:42, Andrew Cooper wrote:
> On 18/12/15 13:14, Juergen Gross wrote:
>> When restarting or shutting down dom0 the xendomains script tries to
>> stop all other domains. Don't do this for the xenstore domain, as it
>> might survive a dom0 reboot in the future.
>>
>> The same applies to xl shutdown --all.
>>
>> Signed-off-by: Juergen Gross <jgr...@suse.com>
>> ---
>> tools/hotplug/Linux/xendomains.in | 17 +++++++++++++++++
>> tools/libxl/xl_cmdimpl.c | 19 +++++++++++++++----
>> 2 files changed, 32 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/hotplug/Linux/xendomains.in
>> b/tools/hotplug/Linux/xendomains.in
>> index dfe0b33..70b7f16 100644
>> --- a/tools/hotplug/Linux/xendomains.in
>> +++ b/tools/hotplug/Linux/xendomains.in
>> @@ -196,6 +196,17 @@ rdnames()
>> done
>> }
>>
>> +# set xenstore domain id (or 0 if no xenstore domain)
>> +get_xsdomid()
>
> A get/set mismatch.
Hmm, depends.
It is getting the domid of the xenstore domain and is setting
XS_DOMID accordingly. The main semantics are to get the correct
domid.
>
>> +{
>> + ${bindir}/xenstore-exists /tool/xenstored/domid
>> + if test $? -ne 0; then
>> + XS_DOMID=0
>> + else
>> + XS_DOMID=`${bindir}/xenstore-read /tool/xenstored/domid`
>> + fi
>
> This is racy. Can't you use a failure of xenstore-read as a signal that
> the key doesn't exist?
In theory it is racy. OTOH the race would require the xenstore domain to
be started between the call of xenstore-exists and xenstore-read, but
xenstore-exists will block in case no xenstore is available. And no, I
don't have to check that. the whole script will bail out early in this
case as in the beginning xl is tested to work which will be the case
with xenstore available only.
And using xenstore-read alone is ugly as it will barf in case the key
isn't existing.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
