[lkml]   [2000]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: io_request_lock question (2.2)

> > 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:51    [W:0.052 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site