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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel