diff options
author | Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> | 2014-04-04 20:53:40 +0200 |
---|---|---|
committer | David Vrabel <david.vrabel@citrix.com> | 2014-04-15 18:41:28 +0200 |
commit | 027bd7e89906a076225b23d1ca4b6702c84e72dc (patch) | |
tree | 622c4232c082e9641024b6e2117c3bc5182362a9 /drivers/xen/manage.c | |
parent | xen/spinlock: Don't enable them unconditionally. (diff) | |
download | linux-027bd7e89906a076225b23d1ca4b6702c84e72dc.tar.xz linux-027bd7e89906a076225b23d1ca4b6702c84e72dc.zip |
xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.
The 'read_reply' works with 'process_msg' to read of a reply in XenBus.
'process_msg' is running from within the 'xenbus' thread. Whenever
a message shows up in XenBus it is put on a xs_state.reply_list list
and 'read_reply' picks it up.
The problem is if the backend domain or the xenstored process is killed.
In which case 'xenbus' is still awaiting - and 'read_reply' if called -
stuck forever waiting for the reply_list to have some contents.
This is normally not a problem - as the backend domain can come back
or the xenstored process can be restarted. However if the domain
is in process of being powered off/restarted/halted - there is no
point of waiting on it coming back - as we are effectively being
terminated and should not impede the progress.
This patch solves this problem by checking whether the guest is the
right domain. If it is an initial domain and hurtling towards death -
there is no point of continuing the wait. All other type of guests
continue with their behavior (as Xenstore is expected to still be
running in another domain).
Fixes-Bug: http://bugs.xenproject.org/xen/bug/8
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Diffstat (limited to 'drivers/xen/manage.c')
0 files changed, 0 insertions, 0 deletions