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/
Home Products Support Community News


[Xen-devel] Error handling in xen-blkfront.c

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Error handling in xen-blkfront.c
From: Andreas Florath <xen@xxxxxxxxxxxx>
Date: Wed, 29 Jul 2009 21:57:06 +0200
Delivery-date: Wed, 29 Jul 2009 12:57:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird (X11/20090103)

Just analyzed the kernel Oops reported in [1] issue 3).

Stumbled over the following lines:
(linux-2.6-pvops.git/drivers/block/xen-blkfront.c line 979ff)

        case XenbusStateClosing:
                if (info->gd == NULL)
                        xenbus_dev_fatal(dev, -ENODEV, "gd is NULL");
                bd = bdget_disk(info->gd, 0);

The error message is:

[   79.768028] vbd vbd-51713: 19 gd is NULL
[   79.772149] BUG: unable to handle kernel NULL pointer dereference at 0000002c
[   79.772204] IP: [] disk_get_part+0x8/0x2d
... Kernel Oops stack trace follows ...
[   79.772940] Call Trace:
[   79.772960]  [] ? bdget_disk+0xc/0x2d

There is checked, if the info->gd is null.  If so, some error handling
is done and IMHO then 'xenbus_dev_fatal()' returns and
'bdget_disk()' is called.  I think there should be something like a
'return;' or a 'goto out;' in between - maybe with some error handling.

Adding a 'return;' (because I think when info->gd is NULL there is
nothing more to do):

        case XenbusStateClosing:
                if (info->gd == NULL) {
                        xenbus_dev_fatal(dev, -ENODEV, "gd is NULL");
                bd = bdget_disk(info->gd, 0);

Results in the error message:

[   46.378565] vbd vbd-51713: 19 gd is NULL
[   46.409129] vbd vbd-51713: 19 gd is NULL

without any stack trace.

Ok, I know: this does not fix the problem, only the error handling.

AFAIK the xen-blkfront.c is not part of xen-unstable.  What to do with
this?   Where to report?  (Keir maybe you know - your one of the
authors of xen-blkfront.c ;-) )

Kind regards


[1] http://lists.xensource.com/archives/html/xen-devel/2009-07/msg01265.html

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Error handling in xen-blkfront.c, Andreas Florath <=