----- Original Message -----
From: "Justin T. Gibbs" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 10, 2001 5:11 PM
Subject: Re: scsi_unjam_host and scsi_try to abort_command


> >Note that the interrupt service routine should also be
> >grabbing io_request_lock when the interrupt arrives, and releasing it
before
> >the interrupt service routine returns.   Thus when the error handler
thread
> >wakes up from the sleep (as a result of either a timer firing or an
> >interrupt), the error handler function would need to grab io_request_lock
> >again.
>
> Please don't encourage this.  The only requirement is that the
io_request_lock
> be held during calls back into the mid-layer.  Holding the io_request_lock
> during the whole interrupt routine needlessly prevents multiple controller
> instances (not necessarily of the type serviced by your driver) from
running
> at the same time.

    Quite right.  Many of the orphaned low-level drivers are doing just
this, mainly because nobody has taken the trouble to figure out how to do it
correctly, and this was the picture that I sort of had in my mind when I was
writing that.  Yet another reason to clean this up for 2.5.

    Perhaps a better way of wording it would be that the interrupt service
routine *may* need to grab io_request_lock at some point and must obviously
release it before returning.

    I should add that technically the mid-layer completion callback has it's
own locking when it inserts the request into the bottom-half handler queue,
so there is no real requirement that the lock be held to call the completion
callback.

    For calls to other functions in the mid-layer, it is probably not the
case that the lock be held either.  As time has gone on I have tried to add
a line to the comment block regarding the SMP status and assumptions.  For
functions that have not yet been updated with such a comment, I guess the
best option is to simply ask at this point.

-Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]

Reply via email to