From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v1] virtio_blk: fix race between start and stop queue
Date: Fri, 16 May 2014 09:45:24 -0600 [thread overview]
Message-ID: <53763294.7020501@kernel.dk> (raw)
In-Reply-To: <CACVXFVNki7os1BAS-vARmiGXuWktr_-U5T_6N6f8u_COMp9CLw@mail.gmail.com>
On 2014-05-16 09:43, Ming Lei wrote:
> On Fri, May 16, 2014 at 11:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2014-05-16 09:31, Ming Lei wrote:
>>>
>>> When there isn't enough vring descriptor for adding to vq,
>>> blk-mq will be put as stopped state until some of pending
>>> descriptors are completed & freed.
>>>
>>> Unfortunately, the vq's interrupt may come just before
>>> blk-mq's BLK_MQ_S_STOPPED flag is set, so the blk-mq will
>>> still be kept as stopped even though lots of descriptors
>>> are completed and freed in the interrupt handler. The worst
>>> case is that all pending descriptors are freed in the
>>> interrupt handler, and the queue is kept as stopped forever.
>>>
>>> This patch fixes the problem by starting/stopping blk-mq
>>> with holding vq_lock.
>>
>>
>> Thanks, this looks good, I'll apply it for 3.16 (with a stable marker, even
>> if it is an unlikely event).
>
> Thanks.
>
> It shouldn't be very difficult to happen in case of
> non-indirect descriptor, and it is easy to reproduce
> when module parameter of 'virtblk_queue_depth'
> is bigger than vq->num_free for non-indirect case.
I agree, it can definitely be setup so that it would not be hard to
trigger. But I don't recall seeing any hang bugs since 3.13 was
released, which would seem to indicate that it doesn't happen a lot in
the wild with default settings.
--
Jens Axboe
prev parent reply other threads:[~2014-05-16 15:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-16 15:31 [PATCH v1] virtio_blk: fix race between start and stop queue Ming Lei
2014-05-16 15:32 ` Jens Axboe
2014-05-16 15:43 ` Ming Lei
2014-05-16 15:45 ` Jens Axboe [this message]
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=53763294.7020501@kernel.dk \
--to=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tom.leiming@gmail.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