Re: [PATCH v2 6/8] blk-mq: don't stop queue for quiescing

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

Re: [PATCH v2 4/8] blk-mq: fix blk_mq_quiesce_queue

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

Re: [PATCH v2 0/8] blk-mq: fix & improve queue quiescing

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

[PATCH v2 5/8] blk-mq: update comments on blk_mq_quiesce_queue()

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

[PATCH v2 7/8] blk-mq: clarify dispatch may not be drained/blocked by stopping queue

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 ++

[PATCH v2 8/8] Revert "blk-mq: don't use sync workqueue flushing from drivers"

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:

[PATCH v2 6/8] blk-mq: don't stop queue for quiescing

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

[PATCH v2 4/8] blk-mq: fix blk_mq_quiesce_queue

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

[PATCH v2 3/8] blk-mq: use the introduced blk_mq_unquiesce_queue()

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 +-

[PATCH v2 2/8] block: introduce flag of QUEUE_FLAG_QUIESCED

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 ---

[PATCH v2 1/8] blk-mq: introduce blk_mq_unquiesce_queue

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.

[PATCH v2 0/8] blk-mq: fix & improve queue quiescing

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,