Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- From: Neil Brown <neilb@xxxxxxx>
- Date: Mon, 11 Dec 2006 13:11:40 +1100
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/
- Follow-Ups:
- Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- From: Jiri Kosina
- Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- References:
- oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- From: Jiri Slaby
- Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- From: Jiri Kosina
- oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- Prev by Date: Re: [2.6.19-rc1][AGP] Regression - amd_k7_agp no longer detected
- Next by Date: Re: new procfs memory analysis feature
- Previous by thread: Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- Next by thread: Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
- Index(es):
Relevant Pages
|
