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