From: John Garry <john.g.garry@oracle.com>
To: yebin <yebin@huaweicloud.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org
Cc: zhangxiaoxu5@huawei.com
Subject: Re: [PATCH v3] scsi: core: clear driver private data when retry request
Date: Tue, 18 Feb 2025 12:13:09 +0000 [thread overview]
Message-ID: <11a36fb5-2644-405f-b368-e9a23a6e92c7@oracle.com> (raw)
In-Reply-To: <67B46DBD.7060805@huaweicloud.com>
On 18/02/2025 11:23, yebin wrote:
>
>
> On 2025/2/17 17:44, John Garry wrote:
>> On 17/02/2025 02:16, Ye Bin wrote:
>>> From: Ye Bin <yebin10@huawei.com>
>>>
>>> After commit 1bad6c4a57ef
>>> ("scsi: zero per-cmd private driver data for each MQ I/O"),
>>> xen-scsifront/virtio_scsi/snic driver remove code that zeroes
>>> driver-private command data. If request do retry will lead to
>>> driver-private command data remains. Before commit 464a00c9e0ad
>>> ("scsi: core: Kill DRIVER_SENSE") if virtio_scsi do capacity
>>> expansion, first request may return UA then request will do retry,
>>> as driver-private command data remains, request will return UA
>>> again.
>>
>> So are there any drivers which expect this sort of behavior, i.e. keep
>> private data between retries?
>
> No driver that depends on the last state is found. If yes, the driver
> should provide the init_cmd_priv function to manage private data. In
> this way, the SCSI middle layer ignores the private data of the driver.
>
TBH, I am not sure on the history here. Maybe Bart or Christoph knows,
but my impression is still that the priv data is only cleared once in
the lifetime of the request (from 1bad6c4a) - at prep time - and some
drivers may rely on that (not be cleared again). Unlikely, though.
>>
>>> As a result, the request keeps retrying, and the request
>>> times out and fails.
>>> So zeroes driver-private command data when request do retry.
>>>
>>> Fixes: f7de50da1479 ("scsi: xen-scsifront: Remove code that zeroes
>>> driver-private command data")
>>> Fixes: c2bb87318baa ("scsi: virtio_scsi: Remove code that zeroes
>>> driver-private command data")
>>> Fixes: c3006a926468 ("scsi: snic: Remove code that zeroes
>>> driver-private command data")
>>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>>
>>> ---
>>
>> Ps: in future, please list the changes per version here
>>
> Thanks for the heads-up.
>>> drivers/scsi/scsi_lib.c | 14 +++++++-------
>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
>>> index be0890e4e706..f1cfe0bb89b2 100644
>>> --- a/drivers/scsi/scsi_lib.c
>>> +++ b/drivers/scsi/scsi_lib.c
>>> @@ -1669,13 +1669,6 @@ static blk_status_t scsi_prepare_cmd(struct
>>> request *req)
>>> if (in_flight)
>>> __set_bit(SCMD_STATE_INFLIGHT, &cmd->state);
>>> - /*
>>> - * Only clear the driver-private command data if the LLD does not
>>> supply
>>> - * a function to initialize that data.
>>> - */
>>> - if (!shost->hostt->init_cmd_priv)
>>> - memset(cmd + 1, 0, shost->hostt->cmd_size);
>>> -
>>> cmd->prot_op = SCSI_PROT_NORMAL;
>>> if (blk_rq_bytes(req))
>>> cmd->sc_data_direction = rq_dma_dir(req);
>>> @@ -1842,6 +1835,13 @@ static blk_status_t scsi_queue_rq(struct
>>> blk_mq_hw_ctx *hctx,
>>> if (!scsi_host_queue_ready(q, shost, sdev, cmd))
>>> goto out_dec_target_busy;
>>> + /*
>>> + * Only clear the driver-private command data if the LLD does not
>>> supply
>>> + * a function to initialize that data.
>>> + */
>>> + if (shost->hostt->cmd_size && !shost->hostt->init_cmd_priv)
>>> + memset(cmd + 1, 0, shost->hostt->cmd_size);
>>> +
>>> if (!(req->rq_flags & RQF_DONTPREP)) {
>>> ret = scsi_prepare_cmd(req);
>>> if (ret != BLK_STS_OK)
>>
>
>
next prev parent reply other threads:[~2025-02-18 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 2:16 [PATCH v3] scsi: core: clear driver private data when retry request Ye Bin
2025-02-17 9:44 ` John Garry
2025-02-18 11:23 ` yebin
2025-02-18 12:13 ` John Garry [this message]
2025-02-18 18:10 ` Bart Van Assche
2025-02-19 14:13 ` John Garry
2025-02-19 20:31 ` Bart Van Assche
2025-02-21 3:27 ` Martin K. Petersen
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=11a36fb5-2644-405f-b368-e9a23a6e92c7@oracle.com \
--to=john.g.garry@oracle.com \
--cc=jejb@linux.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=yebin@huaweicloud.com \
--cc=zhangxiaoxu5@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