Re: Q: Block drivers and the io_request_lock

From: Jens Axboe (axboe@suse.de)
Date: Tue Aug 08 2000 - 12:02:38 EST


On Tue, Aug 08 2000, Jonathan Corbet wrote:
> > The request fn will not be reinvoked until the queue has been plugged
> > again, and that requires that the queue has been emptied. In 2.4
> > devices use plugging by default.
>
> I think that is not true. __make_request will call the request function
> anytime a request is added and the queue is not plugged. Since plugging
> only happens when the queue is empty, a block driver with requests sitting
> on the queue can, in fact, see multiple calls to the request function. I
> was able to demonstrate this to myself in a test driver by introducing a
> suitably long delay before actually removing requests from the queue.

Hmm, that code must have been recently added -- (checking) yup, as per
2.4.0-test5. So yes you are right, if you drop io_request_lock you must
either a) do your own stuff to provide mutual exclusion, or b) be prepared
to handle reentrance.

> > If you exit before having processed all requests in
> > the queue, you need to replug -- but I would consider doing that from
> > the driver pretty hacky.
>
> Really? From ll_rw_blk.c:
>
> > @rfn is not required, or even expected, to remove all requests off the
> > queue, but only as many as it can handle at a time. If it does leave
> > requests on the queue, it is responsible for arranging that the requests
> > get dealt with eventually.

Same deal as above -- since test5, drivers can now get away with not
flushing the whole queue because __make_request calls the request fn
for non-plugged queues. This would have given you big problems in earlier
2.4 kernels.

> > You can get away with not holding io_request_lock when calling
> > end_request (or end_that_request_*) if it is the first request on the
> > queue.
>
> One may be able to "get away" with it now - but should I advise people to
> do things that way in the driver book? My inclination is to tell people to
> be a bit more careful.

The driver is free to fiddle with the first request in any way it wants
without holding the io_request_lock, _assuming_ that it has an active
queue head. For drivers that don't (scsi, for one) io_request_lock must
always be held when messing with the queue.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:15 EST