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-devel

Re: [Xen-devel] xl create crash when using stub domains

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] xl create crash when using stub domains
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Wed, 21 Sep 2011 09:56:34 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 21 Sep 2011 01:57:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E793F42.7070803@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4E729960.2080101@xxxxxxxx> <4E793F42.7070803@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2011-09-21 at 02:34 +0100, Jeremy Fitzhardinge wrote:
> On 09/15/2011 05:33 PM, Jeremy Fitzhardinge wrote:
> > When I create an HVM domain with stubdom enabled, it crashes at:
> >
> > (gdb) run create  -c /etc/xen/f14hv64  vcpus=4 xen_platform_pci=0 'boot="d"'
> > Starting program: /usr/sbin/xl create  -c /etc/xen/f14hv64  vcpus=4 
> > xen_platform_pci=0 'boot="d"'
> > [Thread debugging using libthread_db enabled]
> > Parsing config file /etc/xen/f14hv64
> > xc: info: VIRTUAL MEMORY ARRANGEMENT:
> >   Loader:        0000000000100000->000000000017b9ec
> >   TOTAL:         0000000000000000->000000003f800000
> >   ENTRY ADDRESS: 0000000000100000
> > xc: info: PHYSICAL MEMORY ALLOCATION:
> >   4KB PAGES: 0x0000000000000200
> >   2MB PAGES: 0x00000000000001fb
> >   1GB PAGES: 0x0000000000000000
> > xc: error: panic: xc_dom_bzimageloader.c:588: xc_dom_probe_bzimage_kernel: 
> > kernel is not a bzImage: Invalid kernel

FWIW I don't get this message. It seems unrelated to the issue here but
makes me curious...

> > Detaching after fork from child process 26888.
> > [New Thread 0x7ffff7342700 (LWP 26889)]
> > [Thread 0x7ffff7342700 (LWP 26889) exited]
> > [New Thread 0x7ffff7342700 (LWP 26921)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00007ffff7bbbec5 in libxl__wait_for_device_model (gc=0x7fffffffdbb0, 
> >     domid=22, state=0x7ffff7bc1b8c "running", starting=0x623760, 
> >     check_callback=0, check_callback_userdata=0x0) at libxl_device.c:555
> > 555     if (starting && starting->for_spawn->fd > xs_fileno(xsh))
> > (gdb) bt
> 
> This patch seems to fix it, but I don't know if it is a real fix or just
> papering over something else.

I think this is correct because starting->for_spawn is only valid if the
device model was launched with libxl__spawn_spawn which is only the case
for process based stubdom.

libxl__create_device_model heads off into libxl__create_stubdom for this
case and explicitly sets for_spawn == NULL.

Hmm, actually this function never uses starting except to get at
for_spawn perhaps we should just pass in the for_spawn directly. Patch
to that effect follows.

Ian.

ps: can you add this to your ~/.hgrc please:
[diff]
showfunc = True

8<-----------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@xxxxxxxxxx>
# Date 1316595312 -3600
# Node ID eb9330c89fd3843ff0b1348b0ef21cfeb22d4a76
# Parent  21db7a7dd18483aab5c651f2364c09e8e492d7b1
libxl: make libxl__wait_for_device_model use libxl__spawn_starrting directly

Instead of indirecting via libxl_device_model_starting. This fixes a
segmentation fault using stubdomains where starting->for_spawn is
(validly) NULL because starting a stubdom doesn't need to spawn a
process.

Most callers of libxl__wait_for_device_model already pass NULL for
this variable (because they are not on the starting path) so on
libxl__confirm_device_model_startup needs to change.

Reported-by: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c        Tue Sep 20 16:50:44 2011 +0100
+++ b/tools/libxl/libxl_device.c        Wed Sep 21 09:55:12 2011 +0100
@@ -528,7 +528,7 @@ out:
 
 int libxl__wait_for_device_model(libxl__gc *gc,
                                  uint32_t domid, char *state,
-                                 libxl__device_model_starting *starting,
+                                 libxl__spawn_starting *spawning,
                                  int (*check_callback)(libxl__gc *gc,
                                                        uint32_t domid,
                                                        const char *state,
@@ -558,12 +558,12 @@ int libxl__wait_for_device_model(libxl__
     tv.tv_sec = LIBXL_DEVICE_MODEL_START_TIMEOUT;
     tv.tv_usec = 0;
     nfds = xs_fileno(xsh) + 1;
-    if (starting && starting->for_spawn->fd > xs_fileno(xsh))
-        nfds = starting->for_spawn->fd + 1;
+    if (spawning && spawning->fd > xs_fileno(xsh))
+        nfds = spawning->fd + 1;
 
     while (rc > 0 || (!rc && tv.tv_sec > 0)) {
-        if ( starting ) {
-            rc = libxl__spawn_check(gc, starting->for_spawn);
+        if ( spawning ) {
+            rc = libxl__spawn_check(gc, spawning);
             if ( rc ) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                            "Device Model died during startup");
@@ -592,8 +592,8 @@ again:
         free(p);
         FD_ZERO(&rfds);
         FD_SET(xs_fileno(xsh), &rfds);
-        if (starting)
-            FD_SET(starting->for_spawn->fd, &rfds);
+        if (spawning)
+            FD_SET(spawning->fd, &rfds);
         rc = select(nfds, &rfds, NULL, NULL, &tv);
         if (rc > 0) {
             if (FD_ISSET(xs_fileno(xsh), &rfds)) {
@@ -603,9 +603,9 @@ again:
                 else
                     goto again;
             }
-            if (starting && FD_ISSET(starting->for_spawn->fd, &rfds)) {
+            if (spawning && FD_ISSET(spawning->fd, &rfds)) {
                 unsigned char dummy;
-                if (read(starting->for_spawn->fd, &dummy, sizeof(dummy)) != 1)
+                if (read(spawning->fd, &dummy, sizeof(dummy)) != 1)
                     LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_DEBUG,
                                      "failed to read spawn status pipe");
             }
diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c    Tue Sep 20 16:50:44 2011 +0100
+++ b/tools/libxl/libxl_dm.c    Wed Sep 21 09:55:12 2011 +0100
@@ -934,7 +934,7 @@ int libxl__confirm_device_model_startup(
 {
     int detach;
     int problem = libxl__wait_for_device_model(gc, starting->domid, "running",
-                                               starting, NULL, NULL);
+                                               starting->for_spawn, NULL, 
NULL);
     detach = detach_device_model(gc, starting);
     return problem ? problem : detach;
 }
diff -r 21db7a7dd184 -r eb9330c89fd3 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h      Tue Sep 20 16:50:44 2011 +0100
+++ b/tools/libxl/libxl_internal.h      Wed Sep 21 09:55:12 2011 +0100
@@ -288,7 +288,7 @@ _hidden int libxl__confirm_device_model_
 _hidden int libxl__detach_device_model(libxl__gc *gc, 
libxl__device_model_starting *starting);
 _hidden int libxl__wait_for_device_model(libxl__gc *gc,
                                 uint32_t domid, char *state,
-                                libxl__device_model_starting *starting,
+                                libxl__spawn_starting *spawning,
                                 int (*check_callback)(libxl__gc *gc,
                                                       uint32_t domid,
                                                       const char *state,




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