I believe that it won't cause a hang. The reason is that the done
routine that the low-level driver calls is merely sticking the request in a
bottom-half queue that is processed later after the low-level interrupt
routine has returned.
-Eric
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 9:06 PM
Subject: RE: scsi_unjam_host and scsi_try to abort_command
> 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]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
