Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp350494img; Wed, 20 Mar 2019 01:55:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqwmd7gaLFVOZb8EkenXx5mzR+hhzJvfOnUAck+42DuC8PA5WUV02Ds9/4RExmaK+fv/NPTZ X-Received: by 2002:a62:f587:: with SMTP id b7mr4460976pfm.214.1553072144992; Wed, 20 Mar 2019 01:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553072144; cv=none; d=google.com; s=arc-20160816; b=D4IUgeGy5+UwI/b4iNsFUKU4mgPJgwmcLnUUKJ3N3h958T2SDS1GUC3u8shMe4xUIz JQBlDFGOcNDf9vPrbAFIaHROcM/Fr1DYZxZTfKRHtx6XGUGZVMKWVSLz+PMLtJB3eGQY SrRGJd6noRFFW5hMAgugQLz7zRO2czLKi8SIelEdPNzc9QxEejwFO47nbplDKLYi9nQi tncCBcObO6Kr7MqMWSteiJTWOOpmXcEhTRwCAheNQKj9q4En4OXiNd2g++NF4/s4oCgx 1Lak6A+81tYLKFVCq1Sc/+GSBEE1GO6vzrqsx9PQlwMeLa44WRe6xiNTHJ1IWpop364z KtcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=3+EzNJurZS1AsEIaE+0BQu56pncsQrYL0ruJb1keHbs=; b=lc5GcHMftmQu5rXSKEiKlVbAKP3kNptllYco+G4N7c2SlR3CbzFNCcaZfc6WUJaZSS rD83GS3/Da4LzFwJJ30Gk8aBtkbN1JS7UkQZwzT7V8BDep6EkswEH9DGRZo13J2HBqya 48rXDsYCYTnu3TBjmQCKMu4b1fQ7ek0GfPSGCJTb09sdGjqgF8LHWN/Xe+1+x9joxIsr KPdgxuTA2noJcZ9h5PT8incP3KwhTMeiBxaLpeCH6MJ0xDeHJg951FhuTyxpGvoCGhJR HQsYg2r+tkHMCCNKagPdSXxLjPfsnIh77iyNmwTAr+k4dTR6A8lqQkgWR5pT9Ole9obF V/8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si1192171pgp.341.2019.03.20.01.55.29; Wed, 20 Mar 2019 01:55:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727140AbfCTIwy (ORCPT + 99 others); Wed, 20 Mar 2019 04:52:54 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:5712 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726093AbfCTIwy (ORCPT ); Wed, 20 Mar 2019 04:52:54 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id CC720486C8F936D0559D; Wed, 20 Mar 2019 16:52:51 +0800 (CST) Received: from [127.0.0.1] (10.184.213.217) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.408.0; Wed, 20 Mar 2019 16:52:43 +0800 Subject: Re: [PATCH] blk-mq: fix a hung issue when set device state to blocked and restore running To: Ming Lei CC: , , , , , , References: <1553068921-6605-1-git-send-email-zhengbin13@huawei.com> <20190320081110.GA8408@ming.t460p> From: "zhengbin (A)" Message-ID: Date: Wed, 20 Mar 2019 16:52:40 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20190320081110.GA8408@ming.t460p> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.184.213.217] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for your quick reply, I will study BLK_STS_DEV_RESOURCE in detail > BLK_STS_DEV_RESOURCE means that the driver will rerun hw queue, so > maybe you need to investigate why it is returned from scsi driver first. because we set the device state to blocked, scsi_queue_rq-->prep_to_mq(return BLK_STS_RESOURCE) -->out_put_budget transfer BLK_STS_RESOURCE to BLK_STS_DEV_RESOURCE In this situtation, the request does not send to the driver. If the device use sq, when we we set the device state to blocked and test dd, it will continue to call blk_delay_queue. If this test case really matters for you, we should try to run the hw queues after set state to 'running'. --->Maybe we should call blk_mq_run_hw_queue in scsi_device_set_state? On 2019/3/20 16:11, Ming Lei wrote: > On Wed, Mar 20, 2019 at 04:02:01PM +0800, zhengbin wrote: >> When I use dd test a SCSI device which use blk-mq in the following steps: >> 1.echo "blocked" >/sys/block/sda/device/state >> 2.dd if=/dev/sda of=/mnt/t.log bs=1M count=10 >> 3.echo "running" >/sys/block/sda/device/state >> dd should finish this work after step 3, unfortunately, still hung. >> >> After step2, the key code process is like this: >> blk_mq_dispatch_rq_list-->scsi_queue_rq-->prep_to_mq >> -->if ret is BLK_STS_RESOURCE, delay run hw queue >> >> prep_to_mq will return BLK_STS_RESOURCE, and scsi_queue_rq will transter >> it to BLK_STS_DEV_RESOURCE. In this situtation, we should delay run hw > > BLK_STS_DEV_RESOURCE means that the driver will rerun hw queue, so > maybe you need to investigate why it is returned from scsi driver first. > > BTW, I'd suggest you read the big comment on BLK_STS_DEV_RESOURCE first. > > Thanks, > Ming > > . >