From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH 1/1] null_blk: fix handling of BLKPREP_DEFER case Date: Mon, 27 Apr 2015 11:25:14 -0600 Message-ID: <553E70FA.1080302@kernel.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: Dmitry Krivenok , linux-fsdevel@vger.kernel.org Return-path: Received: from mail-ig0-f176.google.com ([209.85.213.176]:34598 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932542AbbD0RZT (ORCPT ); Mon, 27 Apr 2015 13:25:19 -0400 Received: by iget9 with SMTP id t9so72859124ige.1 for ; Mon, 27 Apr 2015 10:25:17 -0700 (PDT) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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