From: John Garry <john.garry@huawei.com>
To: <lijinlin3@huawei.com>, <jejb@linux.ibm.com>,
<martin.petersen@oracle.com>, <linux-scsi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Cc: <bvanassche@acm.org>, <qiulaibin@huawei.com>,
<linfeilong@huawei.com>, <wubo40@huawei.com>
Subject: Re: [PATCH] scsi: core: Run queue first after running device.
Date: Fri, 6 Aug 2021 10:00:48 +0100 [thread overview]
Message-ID: <0d27db3f-4236-4a30-97a0-ad1dcbf4bcfa@huawei.com> (raw)
In-Reply-To: <908bb2bb-c511-06a4-e0b6-577d90bb9b57@huawei.com>
On 06/08/2021 09:58, John Garry wrote:
And the patch subject is ambiguous
> On 05/08/2021 15:32, lijinlin3@huawei.com wrote:
>> From: Li Jinlin<lijinlin3@huawei.com>
>>
>> We found a hang issue, the test steps are as follows:
>> 1. echo "blocked" >/sys/block/sda/device/state
>> 2. dd if=/dev/sda of=/mnt/t.log bs=1M count=10
>> 3. echo none > /sys/block/sda/queue/scheduler
>> 4. echo "running" >/sys/block/sda/device/state
>>
>> Step3 and Step4 should finish this work after Step4, but them hangs.
>>
>> CPU#0 CPU#1 CPU#2
>> --------------- ---------------- ----------------
>> Step1: blocking device
>>
>> Step2: dd xxxx
>> ^^^^^^ get request
>>
>> q_usage_counter++
>>
>> Step3: switching scheculer
>> elv_iosched_store
>> elevator_switch
>> blk_mq_freeze_queue
>> blk_freeze_queue
>> > blk_freeze_queue_start
>> ^^^^^^ mq_freeze_depth++
>>
>> > blk_mq_run_hw_queues
>> ^^^^^^ can't run queue when dev blocked
>>
>> > blk_mq_freeze_queue_wait
>> ^^^^^^ Hang here!!!
>> wait q_usage_counter==0
>>
>> Step4: running device
>> store_state_field
>> scsi_rescan_device
>> scsi_attach_vpd
>> scsi_vpd_inquiry
>> __scsi_execute
>> blk_get_request
>> blk_mq_alloc_request
>> blk_queue_enter
>> ^^^^^^ Hang here!!!
>> wait mq_freeze_depth==0
>>
>> blk_mq_run_hw_queues
>> ^^^^^^ dispatch IO, q_usage_counter will reduce to zero
>>
>> blk_mq_unfreeze_queue
>> ^^^^^ mq_freeze_depth--
>>
>> Step3 and Step4 wait for each other, caused hangs.
>>
>> This requires run queue frist to fix this issue when the device state
>
> frist ?
>
>> changes to SDEV_RUNNING.
>>
>> Fixes: f0f82e2476f6 ("scsi: core: Fix capacity set to zero after
>> offlinining device")
>> Signed-off-by: Li Jinlin<lijinlin3@huawei.com>
>> Signed-off-by: Qiu Laibin<qiulaibin@huawei.com>
>> Signed-off-by: Wu Bo<wubo40@huawei.com>
>
> what kind of SoB is this?
>
>> ---
>> drivers/scsi/scsi_sysfs.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>> index c3a710bceba0..aa701582c950 100644
>> --- a/drivers/scsi/scsi_sysfs.c
>> +++ b/drivers/scsi/scsi_sysfs.c
>> @@ -809,12 +809,12 @@ store_state_field(struct device *dev, struct
>> device_attribute *attr,
>> ret = scsi_device_set_state(sdev, state);
>> /*
>> * If the device state changes to SDEV_RUNNING, we need to
>> - * rescan the device to revalidate it, and run the queue to
>> - * avoid I/O hang.
>> + * run the queue to avoid I/O hang, and rescan the device
>> + * to revalidate it.
>
> A bit more description of the IO hang would be useful
>
>> */
>> if (ret == 0 && state == SDEV_RUNNING) {
>> - scsi_rescan_device(dev);
>> blk_mq_run_hw_queues(sdev->request_queue, true);
>> + scsi_rescan_device(dev);
>
> This would not have happened if scsi_rescan_device() was ran outside the
> mutex lock region, like I suggested originally.
>
> Indeed, I doubt blk_mq_run_hw_queues() needs to be run with the sdev
> state_mutex held either.
>
>> }
>> mutex_unlock(&sdev->state_mutex);
>> --
>
> .
next prev parent reply other threads:[~2021-08-06 9:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 14:32 [PATCH] scsi: core: Run queue first after running device lijinlin3
2021-08-06 8:58 ` John Garry
2021-08-06 9:00 ` John Garry [this message]
2021-08-06 12:21 ` lijinlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0d27db3f-4236-4a30-97a0-ad1dcbf4bcfa@huawei.com \
--to=john.garry@huawei.com \
--cc=bvanassche@acm.org \
--cc=jejb@linux.ibm.com \
--cc=lijinlin3@huawei.com \
--cc=linfeilong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=qiulaibin@huawei.com \
--cc=wubo40@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).