|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] [PATCH 2 of 3] linux-2.6.18: xen/pv-on-hvm kexec: prevent cr
# HG changeset patch
# User Olaf Hering <olaf@xxxxxxxxx>
# Date 1314289811 -7200
# Node ID 94943cf143035aa7adbec2c39c45c16a5174e3c5
# Parent 86e85596d64b49a9a9c07e8817c33d046b078fd4
linux-2.6.18: xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when
stale watch events arrive
commit c4c303c7c5679b4b368e12f41124aee29c325b76
During repeated kexec boots xenwatch_thread() can crash because
xenbus_watch->callback is cleared by xenbus_watch_path() if a node/token
combo for a new watch happens to match an already registered watch from
an old kernel. In this case xs_watch returns -EEXISTS, then
register_xenbus_watch() does not remove the to-be-registered watch from
the list of active watches but returns the -EEXISTS to the caller
anyway.
Because the watch is still active in xenstored it will cause an event
which will arrive in the new kernel. process_msg() will find the
encapsulated struct xenbus_watch in its list of registered watches and
puts the "empty" watch handle in the queue for xenwatch_thread().
xenwatch_thread() then calls ->callback which was cleared earlier by
xenbus_watch_path().
To prevent that crash in a guest running on an old xen toolstack remove
the special -EEXIST handling.
v2:
- remove the EEXIST handing in register_xenbus_watch() instead of
checking for ->callback in process_msg()
Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
diff -r 86e85596d64b -r 94943cf14303 drivers/xen/xenbus/xenbus_xs.c
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -656,8 +656,7 @@ int register_xenbus_watch(struct xenbus_
err = xs_watch(watch->node, token);
- /* Ignore errors due to multiple registration. */
- if ((err != 0) && (err != -EEXIST)) {
+ if (err) {
spin_lock(&watches_lock);
list_del(&watch->list);
spin_unlock(&watches_lock);
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|