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

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe