lkml.org 
[lkml]   [2000]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: io_request_lock question (2.2)
Date
> 
> > I looked at the implementation of the nbd which just calls
> >
> > spin_unlock_irq(&io_request_lock);
> > ... do network io ...
> > spin_lock_irq(&io_request_lock);
> >
> > This seems to work but it looks very dangerous to me (and ugly, too). Isn't there a better way to do this?
>
> It is only dangerous if you unlock it in the wrong place, unlocking it as much
> as possible is good behaviour. You need it locked until you get the actual
> request off the queue, you need it locked when you complete the request. The
> rest of the time you can be polite
>
>

I'm sorry but I still have some doubts:

The add_request function calls
spin_lock_irqsave(&io_request_lock,flags);
and then calls our request_fn which does
spin_unlock_irq(&io_request_lock);

...do network I/O ...

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?

Thanks,

Reto
-
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/

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