[1/1] null_blk: fix handling of BLKPREP_DEFER case

Commit Message

Dmitry Krivenok April 27, 2015, 9:47 p.m. UTC

I think we need to surround blk_start_queue() call with queue
lock/unlock as it expects that lock should be held.
Slightly modified patch is attached. I've tested it using the same
commands as before.

Thanks,
Dmitry

On Mon, Apr 27, 2015 at 8:36 PM, Jens Axboe <[e-mail]> wrote:
> On 04/27/2015 11:25 AM, Jens Axboe wrote:
>>
>> On 04/19/2015 12:19 PM, Dmitry Krivenok wrote:
>>>
>>> When we fail to allocate new cmd in null_rq_prep_fn we return
>>> BLKPREP_DEFER
>>> which is not handled properly. In single-queue mode of null_blk the
>>> following
>>> command hangs forever in io_schedule():
>>> $ dd if=/dev/nullb0 of=/dev/null bs=8M count=5000 iflag=direct
>>>
>>> The reason is that when 64 commands have been allocated, the 65th command
>>> allocation will fail due to missing free tag. The request, however,
>>> will be
>>> kept in the queue which will never be started again (unless you run
>>> another
>>> command that does I/O to /dev/nullb0).
>>>
>>> This small patch tries to solve the issue by stopping the queue when we
>>> detect that all tags were exhausted and starting it again when we free
>>> the tag.
>>>
>>> I've verified that the command mentioned above doesn't hang anymore
>>> and also
>>> made sure that null_blk with my change survives fio-based stress tests.
>>
>>
>> You are right, legacy request_fn mode has a bug there. I'd get rid of
>> the no_cmds bool, though. If we fail allocating a command in alloc_cmd()
>> and we're in NULL_Q_RQ mode, stop the queue. In free_cmd(), again if
>> we're in NULL_Q_RQ_MODE, check the stopped flag and start the queue if
>> it is set.
>
>
> Something like the attached, totally untested.
>
> --
> Jens Axboe
>

Patch

From c5dfcc7f3d3f79688dbf06aeb099f1a036f42bb9 Mon Sep 17 00:00:00 2001
From: "Dmitry V. Krivenok" <[e-mail]>
Date: Tue, 28 Apr 2015 00:39:21 +0300
Subject: [PATCH 1/1] null_blk: fix handling of BLKPREP_DEFER case

This is a fix for BLKPREP_DEFER case in single queue mode.
It's rework of original implementation based on feedback
from Jens (basically his version plus locking fix).

Signed-off-by: Dmitry V. Krivenok <[e-mail]>
---
 drivers/block/null_blk.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 65cd61a..a26b57f 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -24,6 +24,7 @@  struct nullb_queue {
 	wait_queue_head_t wait;
 	unsigned int queue_depth;
 
+	struct nullb *dev;
 	struct nullb_cmd *cmds;
 };
 
@@ -153,6 +154,16 @@  static void put_tag(struct nullb_queue *nq, unsigned int tag)
 
 	if (waitqueue_active(&nq->wait))
 		wake_up(&nq->wait);
+
+	if (queue_mode == NULL_Q_RQ) {
+		struct nullb *nullb = nq->dev;
+
+		if (blk_queue_stopped(nullb->q)) {
+			spin_lock_irq(nullb->q->queue_lock);
+			blk_start_queue(nullb->q);
+			spin_unlock_irq(nullb->q->queue_lock);
+		}
+	}
 }
 
 static unsigned int get_tag(struct nullb_queue *nq)
@@ -196,7 +207,7 @@  static struct nullb_cmd *alloc_cmd(struct nullb_queue *nq, int can_wait)
 
 	cmd = __alloc_cmd(nq);
 	if (cmd || !can_wait)
-		return cmd;
+		goto out;
 
 	do {
 		prepare_to_wait(&nq->wait, &wait, TASK_UNINTERRUPTIBLE);
@@ -208,6 +219,11 @@  static struct nullb_cmd *alloc_cmd(struct nullb_queue *nq, int can_wait)
 	} while (1);
 
 	finish_wait(&nq->wait, &wait);
+out:
+	if (!cmd) {
+		BUG_ON(queue_mode != NULL_Q_RQ);
+		blk_stop_queue(nq->dev->q);
+	}
 	return cmd;
 }
 
@@ -372,6 +388,7 @@  static void null_init_queue(struct nullb *nullb, struct nullb_queue *nq)
 
 	init_waitqueue_head(&nq->wait);
 	nq->queue_depth = nullb->queue_depth;
+	nq->dev = nullb;
 }
 
 static int null_init_hctx(struct blk_mq_hw_ctx *hctx, void *data,
-- 
2.3.6