From: Jens Axboe <axboe@suse.de>
To: Lou Langholtz <ldl@aros.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Andrea Arcangeli <andrea@suse.de>,
NeilBrown <neilb@cse.unsw.edu.au>,
Steven Whitehouse <steve@chygwyn.com>
Subject: Re: blk_stop_queue/blk_start_queue confusion, problem, or bug???
Date: Mon, 28 Jul 2003 09:01:50 +0200 [thread overview]
Message-ID: <20030728070150.GA25356@suse.de> (raw)
In-Reply-To: <3F2418D9.1020703@aros.net>
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
next prev parent reply other threads:[~2003-07-28 6:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-27 18:24 blk_stop_queue/blk_start_queue confusion, problem, or bug??? Lou Langholtz
2003-07-28 6:43 ` Lou Langholtz
2003-07-28 7:00 ` [PATCH 2.6.0-test2] fix broken blk_start_queue behavior Lou Langholtz
2003-07-28 7:12 ` Jens Axboe
2003-07-28 7:01 ` Jens Axboe [this message]
2003-07-28 7:51 ` blk_stop_queue/blk_start_queue confusion, problem, or bug??? Lou Langholtz
2003-08-07 10:51 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030728070150.GA25356@suse.de \
--to=axboe@suse.de \
--cc=andrea@suse.de \
--cc=ldl@aros.net \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=steve@chygwyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).