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@lists.xensource.com
http://lists.xensource.com/xen-devel