This has been opened as bug #74 (http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=74). I tried running ''xs_test'' with ''dir /'' and it worked fine. However, when I run xs_test --readonly and give it the ''dir /'' command, the system crashes and I get this: (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN) CPU: 0 (XEN) EIP: 0073:[<00000000>] (XEN) EFLAGS: 00010206 CONTEXT: guest (XEN) eax: 00000000 ebx: 4017efec ecx: 080562f4 edx: 080564c4 (XEN) esi: 400162e0 edi: bffff4b4 ebp: bffff228 esp: bffff1fc (XEN) cr0: 8005003b cr3: 18c80000 (XEN) ds: 007b es: 007b fs: 0000 gs: 0069 ss: 007b cs: 0073 (XEN) Guest stack trace from esp=bffff1fc: (XEN) 080495fa 080562f4 080564cc 00000008 0804c4f1 08056294 080562f4 08051090(XEN) 080564c4 080562f4 4017efec bffff248 0804b9cc 080562f4 400162e0 bffff4b4(XEN) 0804c28d 0000000c bffff350 bffff468 0804c3ea 080562f4 08056294 bffff468(XEN) 0804c421 00000000 00000000 00000000 00000000 00000000 00000000 0000004e(XEN) 080562f4 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 080562f4 00000000 00000001 400166e0 00000054 00000800 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000(XEN) 00000000 00000000 00000000 00000000 00000000 762f0001 722f7261 782f6e75(XEN) 74736e65 6465726f 636f732f 5f74656b 40006f72 40017498 00000000 400cffde(XEN) 4017efec 4017ef84 bffff414 400854e5 4017efec bffff4c0 bffff434 4003f41a(XEN) 400166e0 40017218 400166e0 00000001 40016938 00000000 08051340 bffff448(XEN) 08048f7d 00000001 00000001 0000000a 0000000b 00000009 080560f4 080560c4(XEN) ffffffff 400162e0 bffff4b4 bffff488 400856c2 00000002 bffff4b4 bffff4c0\uffff\uffffEN) Domain 0 shutdown: rebooting machine. -- Thanks, Paul Larson pl@us.ibm.com IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2005-06-09 at 15:12 -0500, Paul Larson wrote:> This has been opened as bug #74 > (http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=74). > > I tried running ''xs_test'' with ''dir /'' and it worked fine. However, > when I run xs_test --readonly and give it the ''dir /'' command, the > system crashes and I get this: > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:Wow. I''m not sure how reading the store can crash the domain! But I''ll look into it. Downloading the latest snapshot now. Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rusty Russell wrote:>On Thu, 2005-06-09 at 15:12 -0500, Paul Larson wrote: > > >>This has been opened as bug #74 >>(http://bugzilla.xensource.com/cgi-bin/bugzilla/show_bug.cgi?id=74). >> >>I tried running ''xs_test'' with ''dir /'' and it worked fine. However, >>when I run xs_test --readonly and give it the ''dir /'' command, the >>system crashes and I get this: >> >>(XEN) Domain 0 (vcpu#0) crashed on cpu#0: >> >> > >Wow. I''m not sure how reading the store can crash the domain! But I''ll >look into it. Downloading the latest snapshot now. > >Yeah, seemed odd to me too, but it was easily reproducible as long as I was using --readonly. Without the --readonly flag, the test passed with no crash. Thanks, Paul Larson _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, 2005-06-09 at 22:21 -0500, Paul Larson wrote:> Yeah, seemed odd to me too, but it was easily reproducible as long as I > was using --readonly. Without the --readonly flag, the test passed with > no crash.Untested code is buggy code. Here''s the patch (should apply with maybe some minor fixups). Rusty. Index: xs_test.c ==================================================================RCS file: /var/cvs/xeno-unstable/tools/xenstore/xs_test.c,v retrieving revision 1.7 diff -u -r1.7 xs_test.c --- xs_test.c 8 Jun 2005 09:06:12 -0000 1.7 +++ xs_test.c 10 Jun 2005 14:06:40 -0000 @@ -176,11 +176,11 @@ " watch <path> <token> <prio>\n" " waitwatch\n" " ackwatch <token>\n" - " unwatch <path>\n" + " unwatch <path> <token>\n" " close\n" " start <node>\n" " abort\n" - " introduce <domid> <mfn> <eventchn>\n" + " introduce <domid> <mfn> <eventchn> <path>\n" " commit\n" " sleep <seconds>\n" " dump\n"); Index: xsdaemon_core.c ==================================================================RCS file: /var/cvs/xeno-unstable/tools/xenstore/xsdaemon_core.c,v retrieving revision 1.25 diff -u -r1.25 xsdaemon_core.c --- xsdaemon_core.c 9 Jun 2005 04:52:01 -0000 1.25 +++ xsdaemon_core.c 10 Jun 2005 14:06:41 -0000 @@ -645,7 +645,7 @@ return false; } - if (!conn->write && (perm & XS_PERM_WRITE)) { + if (!conn->can_write && (perm & XS_PERM_WRITE)) { errno = EROFS; return false; } @@ -972,9 +972,12 @@ return do_set_perms(conn, in); case XS_SHUTDOWN: + /* FIXME: Implement gentle shutdown too. */ /* Only tools can do this. */ if (conn->id != 0) return send_error(conn, EACCES); + if (!conn->can_write) + return send_error(conn, EROFS); send_ack(conn, XS_SHUTDOWN); /* Everything hangs off auto-free context, freed at exit. */ exit(0); @@ -1173,6 +1176,7 @@ new->transaction = NULL; new->write = write; new->read = read; + new->can_write = true; talloc_set_fail_handler(out_of_mem, &talloc_fail); if (setjmp(talloc_fail)) { @@ -1206,10 +1210,11 @@ if (fd < 0) return; - conn = new_connection(canwrite ? writefd : NULL, readfd); - if (conn) + conn = new_connection(writefd, readfd); + if (conn) { conn->fd = fd; - else + conn->can_write = canwrite; + } else close(fd); } Index: xsdaemon_core.h ==================================================================RCS file: /var/cvs/xeno-unstable/tools/xenstore/xsdaemon_core.h,v retrieving revision 1.9 diff -u -r1.9 xsdaemon_core.h --- xsdaemon_core.h 8 Jun 2005 09:06:12 -0000 1.9 +++ xsdaemon_core.h 10 Jun 2005 14:06:42 -0000 @@ -56,6 +56,9 @@ /* Are we blocked waiting for a transaction to end? Contains node. */ char *blocked; + /* Is this a read-only connection? */ + bool can_write; + /* Are we waiting for a watch event ack? */ bool waiting_for_ack; Index: xsdaemon_domain.c ==================================================================RCS file: /var/cvs/xeno-unstable/tools/xenstore/xsdaemon_domain.c,v retrieving revision 1.16 diff -u -r1.16 xsdaemon_domain.c --- xsdaemon_domain.c 6 Jun 2005 01:30:55 -0000 1.16 +++ xsdaemon_domain.c 10 Jun 2005 14:06:42 -0000 @@ -271,6 +271,9 @@ if (conn->id != 0) return send_error(conn, EACCES); + if (!conn->can_write) + return send_error(conn, EROFS); + /* Hang domain off "in" until we''re finished. */ domain = talloc(in, struct domain); domain->domid = atoi(vec[0]); -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 10 Jun 2005, at 15:27, Rusty Russell wrote:> Untested code is buggy code. Here''s the patch (should apply with maybe > some minor fixups).Thanks, I''ve checked in the fix. Any idea how the bug could have taken out the whole domain? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2005-06-10 at 16:23 +0100, Keir Fraser wrote:> On 10 Jun 2005, at 15:27, Rusty Russell wrote: > > > Untested code is buggy code. Here''s the patch (should apply with maybe > > some minor fixups). > > Thanks, I''ve checked in the fix. > > Any idea how the bug could have taken out the whole domain?No, it was a straight call to NULL function in xsdaemon. Probably worth writing a test program and running it in domain 0 and checking there''s not some weirdness there? Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, Jun 12, 2005 at 04:57:09PM +1000, Rusty Russell wrote:> No, it was a straight call to NULL function in xsdaemon. Probably worth > writing a test program and running it in domain 0 and checking there''s > not some weirdness there?Hi, Jumping to NULL has been fixed on friday (on dom0 and domU). Cheers, -- Vincent Hanquez _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On Sun, Jun 12, 2005 at 04:57:09PM +1000, Rusty Russell wrote: > > No, it was a straight call to NULL function in xsdaemon. Probably > > worth writing a test program and running it in domain 0 and > checking > > there''s not some weirdness there? > > Jumping to NULL has been fixed on friday (on dom0 and domU).Yep, it was an amusing bug: A test had been added to try and make guest kernel developer''s lives easier by crashing the kernel earlier if they were causing a jump to an unitialised handler. However, the test was botched and was looking at the wrong register. The net result was that any user application jumping at zero would cause Xen to decide to terminate the whole domain :-) This only effected recent unstable builds. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel