Dear all: I was playing with the crypto support, and when I tried to unload the module "loop" I got a segfault and after that lsmod hung
runa:/usr/src/linux-2.5.75# lsmod
Module Size Used by
loop 13736 0
twofish 38272 0
snd_ens1371 16868 1
snd_rawmidi 20096 1 snd_ens1371
snd_ac97_codec 50724 1 snd_ens1371
nfsd 154272 8
exportfs 5024 1 nfsd
lockd 58480 2 nfsd
sunrpc 118856 2 nfsd,lockd
rtc 10260 1
runa:/usr/src/linux-2.5.75# rmmod twofish
runa:/usr/src/linux-2.5.75# rmmod loop
Segmentation fault
runa:/usr/src/linux-2.5.75# lsmod
Module Size Used by
(nothing)
dmesg says (I'll include the hda lines in case they've something to do):
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
blk: queue c15a8c00, I/O limit 4095Mb (mask 0xffffffff)
hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete DataRequest }
hda: CHECK for good STATUS
loop: loaded (max 8 devices)
Unable to handle kernel paging request at virtual address 010000bf
printing eip:
c01d5564
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c01d5564>] Not tainted
EFLAGS: 00210202
EIP is at kobject_del+0x34/0x80
eax: 0100007f ebx: d5c9f850 ecx: d5c9f850 edx: 0100007f
esi: d4f43960 edi: d4f43a24 ebp: 00000880 esp: cf401eec
ds: 007b es: 007b ss: 0068
Process rmmod (pid: 27599, threadinfo=cf400000 task=caac72b0)
Stack: dbfe7ab8 00200282 d654d200 d5c9f850 c01d55c3 d5c9f850 d5c9f800 c023bb8a
d5c9f850 d5c9f800 c023f5de d5c9f800 d4f43960 c037b018 c0240523 d4f43960
d4f43960 d4f43960 c017fc0d d4f43960 00000000 00000000 c037b018 00000000
Call Trace:
[<c01d55c3>] kobject_unregister+0x13/0x30
[<c023bb8a>] elv_unregister_queue+0x1a/0x40
[<c023f5de>] blk_unregister_queue+0x1e/0x60
[<c0240523>] unlink_gendisk+0x13/0x40
[<c017fc0d>] del_gendisk+0x6d/0xe0
[<dcb7a133>] cleanup_module+0x63/0x7e [loop]
[<c012f6f9>] sys_delete_module+0x119/0x1a0
[<c01427dc>] do_munmap+0x14c/0x190
[<c010929b>] syscall_call+0x7/0xb
Code: 8b 52 40 85 d2 74 25 89 5c 24 08 8b 41 24 c7 04 24 a1 71 34
(I'm resending this because I previously had sendmail configuration
problems. Sorry if you receive this message twice.)
Martin Sarsale <[email protected]> writes:
> Dear all: I was playing with the crypto support, and when I tried to
> unload the module "loop" I got a segfault and after that lsmod hung
>
> dmesg says (I'll include the hda lines in case they've something to do):
>
> Unable to handle kernel paging request at virtual address 010000bf
> printing eip:
> c01d5564
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c01d5564>] Not tainted
> EFLAGS: 00210202
> EIP is at kobject_del+0x34/0x80
> eax: 0100007f ebx: d5c9f850 ecx: d5c9f850 edx: 0100007f
> esi: d4f43960 edi: d4f43a24 ebp: 00000880 esp: cf401eec
> ds: 007b es: 007b ss: 0068
> Process rmmod (pid: 27599, threadinfo=cf400000 task=caac72b0)
> Stack: dbfe7ab8 00200282 d654d200 d5c9f850 c01d55c3 d5c9f850 d5c9f800 c023bb8a
> d5c9f850 d5c9f800 c023f5de d5c9f800 d4f43960 c037b018 c0240523 d4f43960
> d4f43960 d4f43960 c017fc0d d4f43960 00000000 00000000 c037b018 00000000
> Call Trace:
> [<c01d55c3>] kobject_unregister+0x13/0x30
> [<c023bb8a>] elv_unregister_queue+0x1a/0x40
> [<c023f5de>] blk_unregister_queue+0x1e/0x60
> [<c0240523>] unlink_gendisk+0x13/0x40
> [<c017fc0d>] del_gendisk+0x6d/0xe0
> [<dcb7a133>] cleanup_module+0x63/0x7e [loop]
> [<c012f6f9>] sys_delete_module+0x119/0x1a0
> [<c01427dc>] do_munmap+0x14c/0x190
> [<c010929b>] syscall_call+0x7/0xb
I have the same problem in 2.6.0-test3-bk5 when I unload the loop
module, even when not using any crypto stuff. The patch below fixes
it:
linux-petero/drivers/block/loop.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff -puN drivers/block/loop.c~loop-oops-fix drivers/block/loop.c
--- linux/drivers/block/loop.c~loop-oops-fix 2003-08-17 19:19:22.000000000 +0200
+++ linux-petero/drivers/block/loop.c 2003-08-17 20:33:03.000000000 +0200
@@ -1198,6 +1198,7 @@ int __init loop_init(void)
lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
if (!lo->lo_queue)
goto out_mem4;
+ init_timer(&lo->lo_queue->unplug_timer);
disks[i]->queue = lo->lo_queue;
init_MUTEX(&lo->lo_ctl_mutex);
init_MUTEX_LOCKED(&lo->lo_sem);
@@ -1237,8 +1238,8 @@ void loop_exit(void)
int i;
for (i = 0; i < max_loop; i++) {
- blk_put_queue(loop_dev[i].lo_queue);
del_gendisk(disks[i]);
+ blk_put_queue(loop_dev[i].lo_queue);
put_disk(disks[i]);
}
devfs_remove("loop");
_
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
Peter Osterlund <[email protected]> wrote:
>
> (I'm resending this because I previously had sendmail configuration
> problems. Sorry if you receive this message twice.)
I saw it (and the other) the first time, thanks.
> diff -puN drivers/block/loop.c~loop-oops-fix drivers/block/loop.c
> --- linux/drivers/block/loop.c~loop-oops-fix 2003-08-17 19:19:22.000000000 +0200
> +++ linux-petero/drivers/block/loop.c 2003-08-17 20:33:03.000000000 +0200
> @@ -1198,6 +1198,7 @@ int __init loop_init(void)
> lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
> if (!lo->lo_queue)
> goto out_mem4;
> + init_timer(&lo->lo_queue->unplug_timer);
> disks[i]->queue = lo->lo_queue;
> init_MUTEX(&lo->lo_ctl_mutex);
> init_MUTEX_LOCKED(&lo->lo_sem);
This bit should be done in ll_rw_blk.c somewhere. Are you sure it is
necessary for loop?
Andrew Morton <[email protected]> writes:
> Peter Osterlund <[email protected]> wrote:
> >
> > diff -puN drivers/block/loop.c~loop-oops-fix drivers/block/loop.c
> > --- linux/drivers/block/loop.c~loop-oops-fix 2003-08-17 19:19:22.000000000 +0200
> > +++ linux-petero/drivers/block/loop.c 2003-08-17 20:33:03.000000000 +0200
> > @@ -1198,6 +1198,7 @@ int __init loop_init(void)
> > lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
> > if (!lo->lo_queue)
> > goto out_mem4;
> > + init_timer(&lo->lo_queue->unplug_timer);
> > disks[i]->queue = lo->lo_queue;
> > init_MUTEX(&lo->lo_ctl_mutex);
> > init_MUTEX_LOCKED(&lo->lo_sem);
>
> This bit should be done in ll_rw_blk.c somewhere. Are you sure it is
> necessary for loop?
Without this, if I insmod loop and then immediately rmmod loop,
del_timer() calls check_timer_failed(), which generates warnings in
the kernel log.
In normal cases, the timer is initialized in blk_queue_make_request(),
but that function is not called if you don't use the loop device
before unloading the module. Maybe there is a better way to get rid of
this warning.
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
Peter Osterlund <[email protected]> wrote:
>
> Andrew Morton <[email protected]> writes:
>
> > Peter Osterlund <[email protected]> wrote:
> > >
> > > diff -puN drivers/block/loop.c~loop-oops-fix drivers/block/loop.c
> > > --- linux/drivers/block/loop.c~loop-oops-fix 2003-08-17 19:19:22.000000000 +0200
> > > +++ linux-petero/drivers/block/loop.c 2003-08-17 20:33:03.000000000 +0200
> > > @@ -1198,6 +1198,7 @@ int __init loop_init(void)
> > > lo->lo_queue = blk_alloc_queue(GFP_KERNEL);
> > > if (!lo->lo_queue)
> > > goto out_mem4;
> > > + init_timer(&lo->lo_queue->unplug_timer);
> > > disks[i]->queue = lo->lo_queue;
> > > init_MUTEX(&lo->lo_ctl_mutex);
> > > init_MUTEX_LOCKED(&lo->lo_sem);
> >
> > This bit should be done in ll_rw_blk.c somewhere. Are you sure it is
> > necessary for loop?
>
> Without this, if I insmod loop and then immediately rmmod loop,
> del_timer() calls check_timer_failed(), which generates warnings in
> the kernel log.
>
> In normal cases, the timer is initialized in blk_queue_make_request(),
> but that function is not called if you don't use the loop device
> before unloading the module. Maybe there is a better way to get rid of
> this warning.
Yup. I moved it to blk_alloc_queue() and removed the init_timer() from
blk_queue_make_request().