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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
