Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7

[Neil Brown]

On Sunday December 10, jikos@xxxxxxxx wrote:
> On Sat, 9 Dec 2006, Jiri Slaby wrote:
> 
> > I got this oops on 2.6.19-rc6-mm2 when starting the system. It happened 
> > only once -- when echo "raidautorun /dev/md0" | nash --quiet was 
> > executed. 
> 
> Hi,
> 
> this nash thing is exactly the command which triggers a bit different oops 
> in my case. On my side, the oops is fully reproducible. If you manage to 
> make your case also reproducible, could you please try to revert 
> md-change-lifetime-rules-for-md-devices.patch? This made the oops vanish 
> in my case. I think Neil is working on it.

Trying to work on it - not making a lot of progress.   I find it hard
to see how anything in md can cause the inode for a block-device file
to disappear...

It is a bit of a long-shot, but this patch might change things.  It
changes the order in which things are de-allocated.

Jiri and Jiri: would either of both of you see if you can reproduce
the bug with this patch on 2.6.19-rc6-mm2 ???

Thanks,
NeilBrown


### Diffstat output
 ./drivers/md/md.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff .prev/drivers/md/md.c ./drivers/md/md.c
--- .prev/drivers/md/md.c	2006-12-11 13:04:23.000000000 +1100
+++ ./drivers/md/md.c	2006-12-11 13:07:28.000000000 +1100
@@ -224,16 +224,20 @@ static inline mddev_t *mddev_get(mddev_t
 
 static void mddev_put(mddev_t *mddev)
 {
+	request_queue_t *q;
+	struct gendisk *disk;
 	if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
 		return;
 	list_del(&mddev->all_mddevs);
 	spin_unlock(&all_mddevs_lock);
 
-	del_gendisk(mddev->gendisk);
-	mddev->gendisk = NULL;
-	blk_cleanup_queue(mddev->queue);
-	mddev->queue = NULL;
+	disk = mddev->gendisk;
+	q = mddev->queue;
+
 	kobject_unregister(&mddev->kobj);
+	if (disk)
+		del_gendisk(disk);
+	blk_cleanup_queue(q);
 }
 
 static mddev_t * mddev_find(dev_t unit)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/