sym53c8xx driver tries to lock io_request_lock before calling done
routine. Also, scsi mid-layer routine scsi_done tries to acquire
the same lock. Won't the system hang at that point ?
-hiren
> -----Original Message-----
> From: Gérard Roudier [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, February 10, 2001 11:48 AM
> To: Jens Axboe
> Cc: Justin T. Gibbs; Alan Cox; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: scsi_unjam_host and scsi_try to abort_command
>
>
>
>
> On Sat, 10 Feb 2001, Jens Axboe wrote:
>
> > On Sat, Feb 10 2001, Justin T. Gibbs wrote:
> > > >Well the driver isnt allowed to hold interrupts off for
> > 1 tick because
> > > >that messes up the clock, and at 1 second the watchdog
> nmi will reboot
> > > >
> > > >scsi driver authors therefore need to adjust their drivers
> > >
> > > If you ask me, it is a bug that the io_request lock is
> forced on low
> > > level drivers at all. 90% of the aic7xxx driver pretends that the
> > > io_request_lock doesn't exist, relying instead on a
> per-controller instance
> > > lock. The interrupt handler only aquires the io_request
> lock for calls back
> > > into the mid-layer as it is expected to be held (although
> the mid-layer
> > > almost instantly releases it again). I also immediately
> release the
> > > io_request_lock in all of my error recovery entry points
> because I don't
> > > need the protection and, as you say, we can't lock up the
> system while we're
> > > waiting for recovery actions to complete.
> >
> > You are doing the Right Thing, the io_request_lock will die in the
> > next devel series. And no doubt the hardest part of that is not the
> > actual i/o layers, it's the SCSI low level drivers that do all sorts
> > of funnies with it.
>
> It is not the low level drivers that have invented the offending
> io_request_lock. They have been forced to live with it. For
> example, the
> ncr53c8xx and sym53c8xx have their instance lock since day
> one and as a
> result they have been for years uselessly doubly locked in
> some places.
> But I didn't want the drivers to rely on the io_request_lock.
> They just
> are forced to live with it and this was enough.
>
> Indeed the io_request_lock reaching low-level driver is ugly
> and nobody
> ever said it was different. _But_, if we consider the mess-up
> that existed
> notably the SCSI mid-layer when the SMP race in the block+scsi+drivers
> stack has been discovered, it probably has been a very quick
> and smart fix
> to use the io_request_lock this way.
>
> One can criticize everything if one just ignores history.
>
> Gérard.
>
> PS: This smart fix was from Linus, if I remember correctly.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
