public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: John Garry <john.g.garry@oracle.com>,
	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 10:10:07 -0800	[thread overview]
Message-ID: <3dd1baa8-e236-41f2-810b-e14a28b72ba5@acm.org> (raw)
In-Reply-To: <11a36fb5-2644-405f-b368-e9a23a6e92c7@oracle.com>

On 2/18/25 4:13 AM, John Garry wrote:
> 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.

I'm not aware of any such drivers.

Driver-private data was introduced together with the scsi-mq code. I'm
not aware of a similar concept in the legacy SCSI core.

Commit d285203cf647 ("scsi: add support for a blk-mq based I/O path")
introduced the following code in kernel v3.17-rc1:

+static int scsi_mq_prep_fn(struct request *req)
+{
[ ... ]
+       memset(cmd, 0, sizeof(struct scsi_cmnd));
[ ... ]
+static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
+{
[ ... ]
+       if (!(req->cmd_flags & REQ_DONTPREP)) {
+               ret = prep_to_mq(scsi_mq_prep_fn(req));
+               if (ret)
+                       goto out_dec_host_busy;
+               req->cmd_flags |= REQ_DONTPREP;
+       }

I think the above memset() call was introduced because of the following
code in the legacy SCSI core (from kernel v3.16):

struct scsi_cmnd *__scsi_get_command(struct Scsi_Host *shost, gfp_t 
gfp_mask)
{
	struct scsi_cmnd *cmd = scsi_host_alloc_command(shost, gfp_mask);

	if (unlikely(!cmd)) {
		unsigned long flags;

		spin_lock_irqsave(&shost->free_list_lock, flags);
		if (likely(!list_empty(&shost->free_list))) {
			cmd = list_entry(shost->free_list.next,
					 struct scsi_cmnd, list);
			list_del_init(&cmd->list);
		}
		spin_unlock_irqrestore(&shost->free_list_lock, flags);

		if (cmd) {
			void *buf, *prot;

			buf = cmd->sense_buffer;
			prot = cmd->prot_sdb;

			memset(cmd, 0, sizeof(*cmd));

			cmd->sense_buffer = buf;
			cmd->prot_sdb = prot;
		}
	}

	return cmd;
}
EXPORT_SYMBOL_GPL(__scsi_get_command);

If I'm reading the v3.16 block layer and SCSI code correctly,
__scsi_get_command() was called not only when a command was submitted
but also when it got resubmitted. See also the q->prep_rq_fn() call in
blk_peek_request().

Since the historic behavior involved clearing the entire struct
scsi_cmnd during requeuing, I'm fine with restoring this behavior.

Thanks,

Bart.

  reply	other threads:[~2025-02-18 18:10 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
2025-02-18 18:10       ` Bart Van Assche [this message]
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=3dd1baa8-e236-41f2-810b-e14a28b72ba5@acm.org \
    --to=bvanassche@acm.org \
    --cc=jejb@linux.ibm.com \
    --cc=john.g.garry@oracle.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