WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-changelog

[Xen-changelog] Test and fix acknowedge_watch from returning EINVAL.

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] Test and fix acknowedge_watch from returning EINVAL.
From: Xen patchbot -unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 26 Jul 2005 20:26:11 -0400
Delivery-date: Wed, 27 Jul 2005 00:26:50 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User cl349@xxxxxxxxxxxxxxxxxxxx
# Node ID 99366b44c42107b04238fbc183385ddae4bb10d5
# Parent  f9a3f32a129bdbfed70273d333cbac9dd8c99b83
Test and fix acknowedge_watch from returning EINVAL.
Also ensure that daemon re-xmits event if they ack wrong thing
(otherwise confused clients get stuck, as we will send no more
data while awaiting ack).
Signed-off-by: Rusty Russel <rusty@xxxxxxxxxxxxxxx>
Signed-off-by: Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>

diff -r f9a3f32a129b -r 99366b44c421 tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c   Tue Jul 26 15:08:22 2005
+++ b/tools/xenstore/xenstored_core.c   Tue Jul 26 15:09:43 2005
@@ -1166,7 +1166,7 @@
        /* We might get a command while waiting for an ack: this means
         * the other end discarded it: we will re-transmit. */
        if (type != XS_WATCH_ACK)
-               conn->waiting_for_ack = false;
+               conn->waiting_for_ack = NULL;
 
        /* Careful: process_message may free connection.  We detach
         * "in" beforehand and allocate the new buffer to avoid
diff -r f9a3f32a129b -r 99366b44c421 tools/xenstore/xenstored_core.h
--- a/tools/xenstore/xenstored_core.h   Tue Jul 26 15:08:22 2005
+++ b/tools/xenstore/xenstored_core.h   Tue Jul 26 15:09:43 2005
@@ -64,7 +64,7 @@
        bool can_write;
 
        /* Are we waiting for a watch event ack? */
-       bool waiting_for_ack;
+       struct watch *waiting_for_ack;
 
        /* Buffered incoming data. */
        struct buffered_data *in;
diff -r f9a3f32a129b -r 99366b44c421 tools/xenstore/xenstored_watch.c
--- a/tools/xenstore/xenstored_watch.c  Tue Jul 26 15:08:22 2005
+++ b/tools/xenstore/xenstored_watch.c  Tue Jul 26 15:09:43 2005
@@ -102,7 +102,7 @@
        if (conn->waiting_reply) {
                conn->out = conn->waiting_reply;
                conn->waiting_reply = NULL;
-               conn->waiting_for_ack = false;
+               conn->waiting_for_ack = NULL;
                return;
        }
 
@@ -115,7 +115,7 @@
                return;
 
        /* If we decide to cancel, we will reset this. */
-       conn->waiting_for_ack = true;
+       conn->waiting_for_ack = event->watches[0];
 
        /* If we deleted /foo and they're watching /foo/bar, that's what we
         * tell them has changed. */
@@ -348,12 +348,17 @@
        if (!conn->waiting_for_ack)
                return send_error(conn, ENOENT);
 
-       event = get_first_event(conn);
-       if (!streq(event->watches[0]->token, token))
+       event = list_top(&conn->waiting_for_ack->events,
+                        struct watch_event, list);
+       assert(event->watches[0] == conn->waiting_for_ack);
+       if (!streq(conn->waiting_for_ack->token, token)) {
+               /* They're confused: this will cause us to send event again */
+               conn->waiting_for_ack = NULL;
                return send_error(conn, EINVAL);
+       }
 
        move_event_onwards(event);
-       conn->waiting_for_ack = false;
+       conn->waiting_for_ack = NULL;
        return send_ack(conn, XS_WATCH_ACK);
 }
 
diff -r f9a3f32a129b -r 99366b44c421 tools/xenstore/testsuite/13watch-ack.sh
--- /dev/null   Tue Jul 26 15:08:22 2005
+++ b/tools/xenstore/testsuite/13watch-ack.sh   Tue Jul 26 15:09:43 2005
@@ -0,0 +1,22 @@
+#! /bin/sh
+
+# This demonstrates a bug where an xs_acknowledge_watch returns
+# EINVAL, because the daemon doesn't track what watch event it sent
+# and relies on it being the "first" watch which has an event.
+# Watches firing after the first event is sent out will change this.
+
+# Create three things to watch.
+echo mkdir /test | ./xs_test
+echo mkdir /test/1 | ./xs_test
+echo mkdir /test/2 | ./xs_test
+echo mkdir /test/3 | ./xs_test
+
+# Watch all three, fire event on 2, read watch, fire event on 1 and 3, ack 2.
+[ "`echo '1 watch /test/1 token1 0
+1 watch /test/2 token2 0
+1 watch /test/3 token3 0
+2 write /test/2 create contents2
+1 waitwatch
+2 write /test/1 create contents1
+2 write /test/3 create contents3
+1 ackwatch token2' | ./xs_test 2>&1`" = "1:/test/2:token2" ]

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] Test and fix acknowedge_watch from returning EINVAL., Xen patchbot -unstable <=