[3557] in linux-scsi channel archive
Re: spinlocks in SCSI code
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Wed Mar 18 15:31:24 1998
Date: Wed, 18 Mar 1998 21:30:20 +0100 (MET)
From: Gerard Roudier <groudier@club-internet.fr>
To: Kurt Garloff <garloff@kg1.ping.de>
cc: Doug Ledford <dledford@dialnet.net>, linux-scsi@vger.rutgers.edu,
"Leonard N. Zubkoff" <lnz@dandelion.com>
In-Reply-To: <19980317234943.A271@kg1.ping.de>
On Tue, 17 Mar 1998, Kurt Garloff wrote:
> On Tue, Mar 17, 1998 at 01:29:50PM +0100, Kurt Garloff wrote:
> > Well, as a first test, I implemented this for the ncr53c8xx driver, as I'm
> > able to test it directly. Of course it works very well, as I have a UP
> > machine and the spin_lock_irqsave (); does exactly the same as save_flags();
> > cli();
> >
> > Too bad I don't have a SMP machine to test.
>
> Well, I can compile a SMP kernel for my UP machine.
> There's one situation, I didn't think of:
> The driver could try to lock the kernel twice, which will result in a
> deadlock. With the save_flags(); cli(); syntax, this was not detected, but
> with the spin_lock(); this will cause a hang.
>
> There are at least two places in the ncr53c8xx driver where this occurs:
> 1) ncr_timeout(): requeue_waiting_list(); is called which will call
> ncr_queue_command() which tries to get the spinlock.
> 2) ncr_complete() is called from within ncr_exception(), the interrupt
> handler, which holds the lock. ncr_complete() calls
> requeue_waiting_list().
>
> As a workaround, I added two spin_unlock() [without the _irqrestore] insns
> at the places where requeue_ ... is called. This is no clean solution, though.
> Maybe we should move the lock from ncr_queue_command() outwards to
> ncr53c8xx_queue_command() and make sure, that we have the lock set at every
> place it can be called.
>
> Comments ?
These one are recursions inside the driver code. But the SCSI code may
recall driver entry points when the driver invoque the callback routine.
The only way to make things clean is in my opinion:
1) Have a handle to recursions inside the driver code (you did catch
that).
2) Unlock internal driver resources prior to calling SCSI call-backs.
3) Behave differently according to execution level (interrupt level or
not).
About 3) the current linux SMP stuff is too much optimized ;) IMO, and
make things not so easy ...
And to make things still less easy, the current driver version may reenter
driver routines from a timer handler. ;-)
Regards, Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
