[1996] in linux-scsi channel archive
Re: scsi.c module patch
daemon@ATHENA.MIT.EDU (Eric Youngdale)
Fri Jun 13 16:05:49 1997
Date: Fri, 13 Jun 1997 16:04:24 -0400 (EDT)
From: Eric Youngdale <eric@andante.jic.com>
To: Andrea Arcangeli <arcangeli@mbox.queen.it>
cc: "Leonard N. Zubkoff" <lnz@dandelion.com>, linux-scsi@vger.rutgers.edu
In-Reply-To: <Pine.LNX.3.96.970613093559.533A-100000@arca.queen.it>
On Fri, 13 Jun 1997, Andrea Arcangeli wrote:
> On Thu, 12 Jun 1997, Eric Youngdale wrote:
>
> >
> > 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;
Yes, I know all of this. The point is that the timer should only
be activated when there is a command on the bus. After insmod returns,
there should not be any commands on the bus, since we should be
automatically disabling the timer when the last command completes.
> 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 may be secure, but it is a band-aid. There is an underlying
bug that is really responsible for this problem.
-Eric
