public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
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)
>>
> 
> 


  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