From: Jens Axboe <jens.axboe@oracle.com>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: How to cleanly shut down a block device
Date: Tue, 14 Nov 2006 12:41:20 +0100 [thread overview]
Message-ID: <20061114114120.GC22178@kernel.dk> (raw)
In-Reply-To: <4559A99B.6070207@drzeus.cx>
On Tue, Nov 14 2006, Pierre Ossman wrote:
> Russell King wrote:
> > Just arrange for the mmc_queue_thread() to empty the queue when
> > MMC_QUEUE_EXIT is set, and then exit. I thought this was something
> > that the block layer looked after (Jens must have missed this in his
> > original review of the MMC code.)
> >
>
> mmc_queue_thread() will empty the thread when MMC_QUEUE_EXIT is set. The
> problem is that we do not set that bit until the last person closes the
> device. In order to avoid problems we need to empty the queue before
> mmc_blk_remove() exits (after which the card structure is no longer valid).
>
> > The handling of userspace keeping the device open despite the hardware
> > having been removed is already in place.
> >
> >
>
> Ok, that's one less problem for me to worry about. :)
>
> Jens Axboe wrote:
> > What do you mean by "killing off the queue"? As long as the queue can be
> > gotten at, it needs to remain valid. That is what the references are
> > for.
> >
>
> I do:
>
> del_gendisk();
> (wait for queue to become empty, i.e. elv_next_request() == NULL)
> blk_cleanup_queue();
elv_next_request() returning NULL means nothing wrt the queue being
empty.
> and then assume that the request function will no longer be called for
> this queue.
>
> Suggested patch:
I think you are making this way too complicated, it's actually pretty
simple: you call blk_put_queue() or blk_cleanup_queue() (same thing)
when _you_ drop your reference to the queue. That's just normal cleanup.
When a device goes away, you make sure that you know about this. I said
that SCSI clears q->queuedata, so it knows that when ->request_fn is
invoked with a NULL q->queuedata (where it stores the device pointer),
the device is not there and the request should just be flushed to
heaven.
Don't make any assumptions about when request_fn will be called or not.
That's bound to be racy anyway.
--
Jens Axboe
next prev parent reply other threads:[~2006-11-14 11:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-14 7:02 How to cleanly shut down a block device Pierre Ossman
2006-11-14 7:56 ` Jens Axboe
2006-11-14 8:15 ` Pierre Ossman
2006-11-14 8:45 ` Jens Axboe
2006-11-14 8:54 ` Pierre Ossman
2006-11-14 10:24 ` Jens Axboe
2006-11-14 10:48 ` Russell King
2006-11-14 11:33 ` Pierre Ossman
2006-11-14 11:41 ` Jens Axboe [this message]
2006-11-14 11:52 ` Pierre Ossman
2006-11-14 14:34 ` Pierre Ossman
2006-11-14 20:48 ` Pierre Ossman
2006-11-23 21:03 ` Russell King
2006-11-23 21:19 ` Pierre Ossman
2006-11-14 11:48 ` Russell King
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=20061114114120.GC22178@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
/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