segfault when unloading module loop in 2.6.0-test3+ck patches

segfault when unloading module loop in 2.6.0-test3+ck patches

[Martin Sarsale]

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 
 

Re: segfault when unloading module loop in 2.6.0-test3+ck patches

[Peter Osterlund]

(I'm resending this because I previously had sendmail configuration
problems. Sorry if you receive this message twice.)

Martin Sarsale <lists@runa.sytes.net> 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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: segfault when unloading module loop in 2.6.0-test3+ck patches

[Andrew Morton]

Peter Osterlund <petero2@telia.com> 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?

Re: segfault when unloading module loop in 2.6.0-test3+ck patches

[Peter Osterlund]

Andrew Morton <akpm@osdl.org> writes:

> Peter Osterlund <petero2@telia.com> 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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: segfault when unloading module loop in 2.6.0-test3+ck patches

[Andrew Morton]

Peter Osterlund <petero2@telia.com> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
> > Peter Osterlund <petero2@telia.com> 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().