> > spin_lock_irq(&io_request_lock);
> > we finish the request and return to the add_request function which calls
> > spin_unlock_irqrestore(&io_request_lock,flags);
> > and restores the flags.
> >
> > Isn't it possible now that the flags which we restore are out of date now?
> > Is this idiom the right one to use for 2.2?
>
> It is fine for 2.2 as well.
>
> The flags you restore are ok. It restores the interrupt state to the state it
> was in when you were called. Think of save_flags/restore_flags as bracketing
> regions of code (and being nestable in pairs). The only real bizarre rule is
> that you cannot save_flags in one function and restore_flags in another without
> upsetting DaveM - as it breaks on the sparc if you do that
Yes, and I believe that this is what's broken about the SCSI midlayer. The the
io_request_lock cannot be completely released in a SCSI HBA because the flags
for that save are way up the stack somewhere. This means that if you need to,
for example, sleep on something like loop coming up, you can spin_unlock_irq,
but you can't restore flags, so for the UP case, you just hang. To avoid this,
I'm having to build a kernel thread to handle all of this kind of stuff in a
separate context. What a PITA.
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 15 2000 - 21:00:15 EST