On Sat, 2017-05-27 at 22:21 +0800, Ming Lei wrote:
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 032045841856..84cce67caee3 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -168,8 +168,6 @@ void blk_mq_quiesce_queue(struct request_queue *q)
> unsigned int i;
> bool rcu
On Sat, 2017-05-27 at 22:21 +0800, Ming Lei wrote:
> It is required that no dispatch can happen any more once
> blk_mq_quiesce_queue() returns, and we don't have such requirement
> on APIs of stopping queue.
>
> But blk_mq_quiesce_queue() still may not block/drain dispatch in the
> following cases
On Sat, 2017-05-27 at 22:21 +0800, Ming Lei wrote:
> There are some issues in current blk_mq_quiesce_queue():
>
> - in case of direct issue or BLK_MQ_S_START_ON_RUN, dispatch won't
> be prevented after blk_mq_quiesce_queue() is returned.
> - in theory, new RCU read-side critical sectio
BLK_MQ_S_STOPPED may not be observed in other concurrent I/O paths,
we can't guarantee that dispatching won't happen after returning
from the APIs of stopping queue.
So clarify the fact and avoid potential misuse.
Signed-off-by: Ming Lei
---
block/blk-mq.c | 10 ++
1 file changed, 10 in
This patch reverts commit 2719aa217e0d02(blk-mq: don't use
sync workqueue flushing from drivers) because only
blk_mq_quiesce_queue() need the sync flush, and now
we don't need to stop queue any more, so revert it.
Also changes to cancel_delayed_work() in blk_mq_stop_hw_queue().
Signed-off-by: Min
Queue can be started by other blk-mq APIs and can be used in
different cases, this limits uses of blk_mq_quiesce_queue()
if it is based on stopping queue, and make its usage very
difficult, especially users have to use the stop queue APIs
carefully for avoiding to break blk_mq_quiesce_queue().
We
Actually what we want to get from blk_mq_quiesce_queue()
isn't only to wait for completion of all ongoing .queue_rq().
In the typical context of canceling requests, we need to
make sure that the following is done in the dispatch path
before starting to cancel requests:
- failed dispatched
It is required that no dispatch can happen any more once
blk_mq_quiesce_queue() returns, and we don't have such requirement
on APIs of stopping queue.
But blk_mq_quiesce_queue() still may not block/drain dispatch in the
following cases:
- direct issue or BLK_MQ_S_START_ON_RUN
- in theory, new RCU
blk_mq_unquiesce_queue() is used for unquiescing the
queue explicitly, so replace blk_mq_start_stopped_hw_queues()
with it.
Cc: linux-n...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: dm-de...@redhat.com
Signed-off-by: Ming Lei
---
drivers/md/dm-rq.c | 2 +-
drivers/nvme/host/cor
This flag is introduced for fixing & improving the quiescing code.
Signed-off-by: Ming Lei
---
include/linux/blkdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 41291be82ac4..60967797f4f6 100644
--- a/include/linux/blkdev.h
+++ b/i
We use blk_mq_start_stopped_hw_queues() implictely
as pair of blk_mq_quiesce_queue() for unquiescing the queue,
so we introduce blk_mq_unquiesce_queue() and make it
as pair of blk_mq_quiesce_queue() explicitely.
This function is for fixing current quiescing mechanism
in the following patches.
Sig
Hi,
There are some issues in current blk_mq_quiesce_queue():
- in case of direct issue or BLK_MQ_S_START_ON_RUN, dispatch won't
be prevented after blk_mq_quiesce_queue() is returned.
- in theory, new RCU read-side critical sections may begin while
synchronize_rcu() was waiting, an
12 matches
Mail list logo