All of lore.kernel.org
 help / color / mirror / Atom feed
From: Asias He <asias@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
	virtualization@lists.linux-foundation.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 1/5] block: Introduce q->abort_queue_fn()
Date: Tue, 22 May 2012 15:30:37 +0800	[thread overview]
Message-ID: <4FBB409D.4070201@redhat.com> (raw)
In-Reply-To: <20120521154213.GB6549@google.com>

On 05/21/2012 11:42 PM, Tejun Heo wrote:
> On Mon, May 21, 2012 at 05:08:29PM +0800, Asias He wrote:
>> When user hot-unplug a disk which is busy serving I/O, __blk_run_queue
>> might be unable to drain all the requests. As a result, the
>> blk_drain_queue() would loop forever and blk_cleanup_queue would not
>> return. So hot-unplug will fail.
>>
>> This patch adds a callback in blk_drain_queue() for low lever driver to
>> abort requests.
>>
>> Currently, this is useful for virtio-blk to do cleanup in hot-unplug.
>
> Why is this necessary?  virtio-blk should know that the device is gone
> and fail in-flight / new commands.  That's what other drivers do.
> What makes virtio-blk different?

blk_cleanup_queue() relies on __blk_run_queue() to finish all the 
requests before DEAD marking, right?

There are two problems:

1) if the queue is stopped, q->request_fn() will never call called. we 
will be stuck in the loop forever. This can happen if the remove method 
is called after the q->request_fn() calls blk_stop_queue() to stop the 
queue when the device is full, and before the device interrupt handler 
to start the queue. This can be fixed by calling blk_start_queue() 
before __blk_run_queue(q).

blk_drain_queue() {
    while(true) {
       ...
       if (!list_empty(&q->queue_head))
         __blk_run_queue(q);
       ...
    }
}

2) Since the device is gonna be removed, is it safe to rely on the 
device to finish the request before the DEAD marking? E.g, In 
vritio-blk, We reset the device and thus disable the interrupt before we 
call blk_cleanup_queue(). I also suspect that the real hardware can 
finish the pending requests when being hot-unplugged.

So I proposed the q->abort_queue_fn() callback in blk_drain_queue() for 
the driver to abort the queue explicitly no mater how the device behaves.

BTW, do we have any infrastructure in block layer to track the requests 
already dispatched to driver. This might be useful for driver if it want 
to abort all of them. Otherwise the driver has to do it on their own.

-- 
Asias

  reply	other threads:[~2012-05-22  7:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21  9:08 [RFC PATCH 1/5] block: Introduce q->abort_queue_fn() Asias He
2012-05-21  9:08 ` [RFC PATCH 2/5] block: Do not stop draining if waitqueue is not empty Asias He
2012-05-21 15:39   ` Tejun Heo
2012-05-22  6:48     ` Asias He
2012-05-22 15:07       ` Tejun Heo
2012-05-23 14:54         ` Asias He
2012-05-25  1:16           ` Asias He
2012-05-28  0:30             ` Tejun Heo
2012-05-28  3:39               ` Asias He
2012-05-21  9:08 ` [RFC PATCH 3/5] virtio-blk: Call del_gendisk() before disable guest kick Asias He
2012-05-21  9:08 ` [RFC PATCH 4/5] virtio-blk: Use q->abort_queue_fn() to abort requests Asias He
2012-05-21  9:08 ` [RFC PATCH 5/5] virtio-blk: Use block layer provided spinlock Asias He
2012-05-21 20:59   ` Michael S. Tsirkin
2012-05-22  8:22     ` Asias He
2012-05-21 15:42 ` [RFC PATCH 1/5] block: Introduce q->abort_queue_fn() Tejun Heo
2012-05-22  7:30   ` Asias He [this message]
2012-05-22 15:14     ` Tejun Heo
2012-05-23 15:04       ` Asias He

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=4FBB409D.4070201@redhat.com \
    --to=asias@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=tj@kernel.org \
    --cc=virtualization@lists.linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.