lkml.org 
[lkml]   [2003]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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