[1988] in linux-scsi channel archive
Re: scsi.c module patch
daemon@ATHENA.MIT.EDU (Andrea Arcangeli)
Fri Jun 13 04:32:00 1997
Date: Fri, 13 Jun 1997 10:27:42 +0200 (CEST)
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
To: Eric Youngdale <eric@andante.jic.com>
cc: "Leonard N. Zubkoff" <lnz@dandelion.com>, linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.95.970612235133.12131D-100000@andante.jic.com>
On Thu, 12 Jun 1997, Eric Youngdale wrote:
>
>On Thu, 12 Jun 1997, Andrea Arcangeli wrote:
>
>> On Wed, 11 Jun 1997, Leonard N. Zubkoff wrote:
>>
>> > Date: Thu, 12 Jun 1997 00:53:52 +0200 (CEST)
>> > From: Andrea Arcangeli <arcangeli@mbox.queen.it>
>> > The crash was caused from the execution of the scsi_main_timeout function
>> > by the SCSI_TIMER when the module was just cleared from memory.
>> >
>> > So I have stopped the SCSI_TIMER before clear the module from memory.
>> >
>> >Can you look into *why* the timer is still active? There shouldn't be any
>> >active commands for the SCSI module when it is being unloaded, and hence the
>> >timer should already have been inactivated by update_timeout. If it hasn't
>>
>> Yes, but the problem cames when the SCSI_TIMER is programmed to run
>> update_timeout after insmod ppa and then I run rmmod scsi_mod before
>> update_timeout is run. rmmod set .fn = 0 and I get an Oops with
>> EIP=00000000.
>>
>> >been, then there's a deeper underlying problem and this patch is just masking
>> >the incorrect behavior.
>>
>> Please explain better.
>
> The problem is that there should never be the possibility of a
>timeout unless there are commands that are running, and that if there are
Is very simple. When I run insmod ppa. The SCSI_TIMER is activated from
an update_timeout that return from:
if (jiffies == time_start && timer_table[SCSI_TIMER].expires > 0) {
if(SCset){
oldto = SCset->timeout;
SCset->timeout = timeout;
if (timeout > 0 &&
jiffies + timeout < timer_table[SCSI_TIMER].expires)
timer_table[SCSI_TIMER].expires = jiffies + timeout;
}
restore_flags(flags);
return oldto;
^^^^^^^^^^^^
Then some seconds after "insmod ppa" the scsi_main_timeout function is
executed, so if I run "rmmod ppa; rmmod scsi_mod" before the execution the
SCSI_TIMER try to execute the NULL function.
The SCSI_TIMER must be stopped when the scsi_mod module is removed from
memory.
>commands that are running there should not be the possibility of unloading
>the module. Turning off the timer is merely a band-aid - the fact remains
With the SCSI_TIMER active you have the possibility of unload the module.
>that having an active timer implies that there is an active command.
Is very simple: add a printk("scsi_main_timeout\n"); at the top of
scsi_main_timeout(..) function. You must have scsi_mod and ppa
(ppa is the only device that need scsi_mod on my system) compiled as
module. Then run:
insmod parport #if you use parport compiled as module
insmod scsi_mod;insmod ppa
Then (after some seconds) you can read the printk output.
Only after the printk you can run:
rmmod ppa;rmmod scsi_mod
If you run
rmmod ppa;rmmod scsi_mod
before the printk your kernel try to execute the NULL function and you get
an Oops and the kernel crash.
>
> It is possible that there is a bug where the timer isn't canceled
>for some reason, or there is a bug whereby we allow the driver to be
>removed even though there are active commands.
I think my solution is secure, because the only SCSI_TIMER command can be
executed is scsi_main_timeout. If you unload scsi_mod it can't be executed
from the schedule timer. So you must stop the SCSI_TIMER when you unload
scsi_mod.
>
> It would be nice to know what command is timing out for you, and
>where it originated from.
Sure it' s generated sure from the initializing function.
Andrea Arcangeli
arcangeli@mbox.queen.it
HomePage: http://www.imola.queen.it/user/arcangeli/
Debian Mirror: ftp://dida43.deis.unibo.it/pub/debian/
Debian GNU
__ _ __
/ / (_)__ __ ____ __/ /
/ /__/ / _ \/ // /\ \ /_/
/____/_/_//_/\_,_//_\_(_)
