Error handling in xen-blkfront.c

[Andreas Florath <xen@flonatel.org>]

Hello!

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)

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

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):

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

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

Andreas


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