Re: 2.4.4-ac4 - oops on unload "cdrom" module

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Andrzej Krzysztofowicz]

> This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
> CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.
> 
> sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
> this oops the "cdrom" module remains in memory in the "deleted" state.

> Unable to handle kernel NULL pointer dereference at virtual address 00000008
[...]
> >>EIP; c0118051 <unregister_sysctl_table+5/2c>   <=====

The following patch fixes unloading of cdrom module when no cdrom driver
loaded (2.4.5-pre, 2.4.4-ac):

--- drivers/cdrom/cdrom.c.old	Fri May  4 22:44:31 2001
+++ drivers/cdrom/cdrom.c	Fri May  4 22:54:36 2001
@@ -2698,7 +2698,8 @@
 
 static void cdrom_sysctl_unregister(void)
 {
-	unregister_sysctl_table(cdrom_sysctl_header);
+	if (cdrom_sysctl_header)
+		unregister_sysctl_table(cdrom_sysctl_header);
 }
 
 #endif /* CONFIG_SYSCTL */


Andrzej


-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  tel.  (0-58) 347 14 61
Wydz.Fizyki Technicznej i Matematyki Stosowanej Politechniki Gdanskiej

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Pavel Roskin]

Hi, Andrzej!

> The following patch fixes unloading of cdrom module when no cdrom driver
> loaded (2.4.5-pre, 2.4.4-ac):

It works for me. Thank you! You have even managed to find out that I had
my CD-ROM disconnected :-)

By the way, shouldn't we register sysctl, /proc/sys/dev/cdrom/ and
/dev/cdrom/ always when the cdrom driver is loaded/initialized, not when a
cdrom unit is found?

I don't know what's the official "policy" is, but wouldn't it be logical
to have some control over the drivers that handle no devices in the
moment?

Actually, the scsi module behaves differently. Right now I have empty
/dev/scsi and /proc/scsi/scsi contains "Attached devices: none"

Anyway, the patch is small, straightforward and consistent with the
current behavior of the driver. And it works.

-- 
Regards,
Pavel Roskin

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Jens Axboe]

On Fri, May 04 2001, Pavel Roskin wrote:
> > The following patch fixes unloading of cdrom module when no cdrom driver
> > loaded (2.4.5-pre, 2.4.4-ac):
> 
> It works for me. Thank you! You have even managed to find out that I had
> my CD-ROM disconnected :-)
> 
> By the way, shouldn't we register sysctl, /proc/sys/dev/cdrom/ and
> /dev/cdrom/ always when the cdrom driver is loaded/initialized, not when a
> cdrom unit is found?
> 
> I don't know what's the official "policy" is, but wouldn't it be logical
> to have some control over the drivers that handle no devices in the
> moment?

We should, the -ac tree has the first cut of the cdrom updates and they
didn't have the linking right. The right init sequence fixes the issue
as well, not just initing after the first cdrom driver registers.

-- 
Jens Axboe

Re: 2.4.4-ac4 - oops on unload "cdrom" module

[Jens Axboe]

On Fri, May 04 2001, Andrzej Krzysztofowicz wrote:
> > This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
> > CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.
> > 
> > sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
> > this oops the "cdrom" module remains in memory in the "deleted" state.
> 
> > Unable to handle kernel NULL pointer dereference at virtual address 00000008
> [...]
> > >>EIP; c0118051 <unregister_sysctl_table+5/2c>   <=====
> 
> The following patch fixes unloading of cdrom module when no cdrom driver
> loaded (2.4.5-pre, 2.4.4-ac):
> 
> --- drivers/cdrom/cdrom.c.old	Fri May  4 22:44:31 2001
> +++ drivers/cdrom/cdrom.c	Fri May  4 22:54:36 2001
> @@ -2698,7 +2698,8 @@
>  
>  static void cdrom_sysctl_unregister(void)
>  {
> -	unregister_sysctl_table(cdrom_sysctl_header);
> +	if (cdrom_sysctl_header)
> +		unregister_sysctl_table(cdrom_sysctl_header);
>  }
>  
>  #endif /* CONFIG_SYSCTL */

Thanks applied.

-- 
Jens Axboe

2.4.4-ac4 - oops on unload "cdrom" module

[Pavel Roskin]

Hello!

This oops happens when I run "rmmod cdrom" on a 2.4.4-ac4 kernel with
CONFIG_SYSCTL enabled. It doesn't happen if CONFIG_SYSCTL is disabled.

Full .config is here:
http://www.red-bean.com/~proski/linux/config

sr_mod isn't loaded at this point. Reference to sd_mod looks weird. After
this oops the "cdrom" module remains in memory in the "deleted" state.

$ /sbin/lsmod
Module                  Size  Used by
hid                    11760   0 (unused)
keybdev                 1632   0 (unused)
mga                    85312   1
agpgart                13136   3
mousedev                3936   1 (autoclean)
input                   3296   0 (autoclean) [hid keybdev mousedev]
nfsd                   67504   8 (autoclean)
lockd                  48752   1 (autoclean) [nfsd]
sunrpc                 56800   1 (autoclean) [nfsd lockd]
3c59x                  24320   1 (autoclean)
ipx                    14496   1 (autoclean)
ramfs                   3728   1 (autoclean)
cdrom                  28864   0 (deleted)

ksymoops 2.3.4 on i686 2.4.4-ac4.  Options used
     -v vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.4-ac4/ (default)
     -m System.map (specified)

Unable to handle kernel NULL pointer dereference at virtual address 00000008
c0118051
Oops: 0000
CPU:    0
EIP:    0010:[<c0118051>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: 00000000   ecx: d08c9000   edx: 00000000
esi: d08c9000   edi: 00000000   ebp: bfffe968   esp: c181bf80
ds: 0018   es: 0018   ss: 0018
Process rmmod (pid: 11303, stackpage=c181b000)
Stack: d08c9000 d08cd92f 00000000 d08cd97a 00000000 d08cf5c0 c01157eb d08c9000
       fffffff0 c62dc000 c0114c87 d08c9000 00000000 c181a000 bffffb47 00000001
       c0106af7 bffffb47 0805eee8 00000100 bffffb47 00000001 bfffe968 00000081
Call Trace: [<d08c9000>] [<d08cd92f>] [<d08cd97a>] [<d08cf5c0>] [<c01157eb>]
   [<d08c9000>] [<c0114c87>] [<d08c9000>] [<c0106af7>]
Code: 8b 53 08 8b 43 04 89 50 04 89 02 a1 a0 46 27 c0 50 8b 03 50

>>EIP; c0118051 <unregister_sysctl_table+5/2c>   <=====
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; d08cd92f <[cdrom]cdrom_sysctl_unregister+b/10>
Trace; d08cd97a <[cdrom]cdrom_exit+1a/28>
Trace; d08cf5c0 <[cdrom].rodata.start+1a00/1a22>
Trace; c01157eb <free_module+1b/a0>
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; c0114c87 <sys_delete_module+f3/1b0>
Trace; d08c9000 <[sd_mod]__module_using_checksums+18cb/192b>
Trace; c0106af7 <system_call+33/38>
Code;  c0118051 <unregister_sysctl_table+5/2c>
00000000 <_EIP>:
Code;  c0118051 <unregister_sysctl_table+5/2c>   <=====
   0:   8b 53 08                  mov    0x8(%ebx),%edx   <=====
Code;  c0118054 <unregister_sysctl_table+8/2c>
   3:   8b 43 04                  mov    0x4(%ebx),%eax
Code;  c0118057 <unregister_sysctl_table+b/2c>
   6:   89 50 04                  mov    %edx,0x4(%eax)
Code;  c011805a <unregister_sysctl_table+e/2c>
   9:   89 02                     mov    %eax,(%edx)
Code;  c011805c <unregister_sysctl_table+10/2c>
   b:   a1 a0 46 27 c0            mov    0xc02746a0,%eax
Code;  c0118061 <unregister_sysctl_table+15/2c>
  10:   50                        push   %eax
Code;  c0118062 <unregister_sysctl_table+16/2c>
  11:   8b 03                     mov    (%ebx),%eax
Code;  c0118064 <unregister_sysctl_table+18/2c>
  13:   50                        push   %eax


-- 
Regards,
Pavel Roskin