Messages in this thread | | | Date | Mon, 28 Jul 2003 09:01:50 +0200 | From | Jens Axboe <> | Subject | Re: blk_stop_queue/blk_start_queue confusion, problem, or bug??? |
| |
On Sun, Jul 27 2003, Lou Langholtz wrote: > I've been trying to use the blk_start_queue and blk_stop_queue functions > in the network block device driver branch I'm working on. The stop works > as expected, but the start doesn't. Processes that have tried to read or > write to the device (after the queue was stopped) stay blocked in > io_schedule instead of getting woken up (after blk_start_queue was > called). Do I need to follow the call to blk_start_queue() with a call > to wake_up() on the correct wait queues? Why not have that functionality > be part of blk_start_queue()? Or was this an oversight/bug?
blk_start_queue() should be enough. What kind of behaviour are you seeing? Is the request_fn() never called again?
> The reason I'm using blk_stop_queue and blk_start_queue is to stop the > request handling function (installed from blk_init_queue), from being > re-invoked and to return when the network block device server goes down. > That way, the driver doesn't need to block indefinately within the > request handling function - which seems like it'd likely block other > block drivers if it did this - and doesn't need to be handled by
It will, you should never block in your request function/
> yet-another seperate kernel thread. Anyways... the stop is called from > either the request handling function context or from an ioctl call > context. If then a process tries to read or write to the device it > blocks - just as I'd like (more like NFS behavior that way). When my > code detects that the server has come back up again from the ioctl call > context it calls blk_start_queue(). But the I/O blocked process stays > blocked.
aaaaand what happens? You are not giving a lot of info. What kernel? It's pretty trivial to put printks in stop/start_queue and start doing some tracking, since none of the core drivers use it yet.
> Am I using these calls incorrectly or is something else going on? > Insights, examples, very much appreciated.
Hard to say, as you didn't post the code. But it sounds correct.
> BTW: LKML has had a related thread on this some years ago in discussing > how the block layer system handles request functions that must drop the > spinlock and may block indefinately. That never seemed to get resolved > though and makes me believe that's why Steven Whitehouse opted to use a > multi-threaded approach to the NBD driver at one point.
That has never really been allowed, in that it is a Bad Thing to do something like that.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |