Re: When must the io_request_lock be held?

[Doug Ledford <dledford@redhat.com>]

On Wed, Aug 07, 2002 at 10:26:24AM -0500, James Bottomley wrote:
> dledford@redhat.com said:
> > You can use the spin_unlock() variant if you wish, but that will leave
> > interrupts disabled and therefore buy you exactly zero benefit on UP
> > systems.
> 
> This isn't necessarily true.  Some SCSI cards have a single mailbox for 
> outgoing and incoming transfer parameters and commands.  If you have one of 
> these, you need to keep interrupts disabled as you set up a command so that 
> your own interrupt routine doesn't overwrite the values if you get a reconnect 
> interrupt while you're programming the card.

Then you better not *ever* release the lock under those conditions.  
Leaving interrupts disabled may work on UP, but on SMP it only disables 
interrupts on that one CPU and if you aren't holding your lock then 
another CPU can run the interrupt routine and trash your data.  So, back 
to my point, if you aren't enabling interrupts, then there is no reason to 
release the lock because you obviously need some sort of lock type 
protection.

> dledford@redhat.com said:
> > You are, of course, responsible for doing sane locking in your driver
> > if you choose to unlock the locks the mid layer holds for you.
> 
> This is a very important point to bear in mind.  Since the io_request_lock 
> must be held when calling the done() routine,

Don't get too hung up on this point.  In 2.5 you don't need either the 
io_request_lock or host->host_lock when calling the done function.  In 
2.4.19 you don't need it if you are a new eh driver, only if you are old.  
And hopefully by 2.4.20 that won't be true either.  If Marcello takes the 
patch I've got for 2.4 that we shipped in our Red Hat 7.3 product, then 
both new and old eh drivers will no longer have to hold a lock when they 
call the done function because both of them will be using the new eh 
code's bottom half mechanism.

> you are asking to create a 
> deadlock if you use your own locks in the driver (it's not impossible to get 
> this correct, just very difficult).

Again, if Marcello takes my patch, this will become easier as well since 
it adds a host->lock lock that allows you to get your driver off the 
horrible io_request_lock once and for all.  (Note: I may have to change 
the name to host->host_lock to make it match 2.5, but that just annoys the 
hell out of me because I *detest* totally redundant names like that...)

> Basically, the io_request_lock is used to protect structures within the SCSI 
> and block layer.  Once you get into the LLD, you may extend it if you wish to 
> protect the individual data structures of your driver (which is why it's held 
> on entry to most of the LLD API) but if you don't want to, it is safe to drop 
> it (as long as your queuecommand is re-entrant and you re-acquire it before 
> exiting the API routines).
> 
> James
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606