From: sashiko-bot@kernel.org
To: "John Garry" <john.g.garry@oracle.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 09/17] scsi-multipath: add scsi_mpath_{start,end}_request()
Date: Fri, 03 Jul 2026 11:53:50 +0000 [thread overview]
Message-ID: <20260703115351.1C2E31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260703103402.3725011-10-john.g.garry@oracle.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Requeueing a command causes permanent leaks of `mpath_nr_active` and block device in-flight I/O statistics because `SCMD_MPATH_*` flags are not preserved.
- [High] Premature termination of I/O accounting and double-accounting on partial request completions because `scsi_mpath_end_request()` is called before `blk_update_request()`.
- [Low] Implicit function declarations of `is_mpath_request` and `mpath_qd_iopolicy` cause build failures.
--
commit 6d78b641877657fb26302d1c7965b47fd751383b
Author: John Garry <john.g.garry@oracle.com>
scsi-multipath: add scsi_mpath_{start,end}_request()
This patch adds scsi_mpath_start_request() and scsi_mpath_end_request() to
handle updating private multipath request data. It also introduces
mpath_nr_active to Scsi_Host to support queue depth multipath iopolicy.
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 3c493068adb98..72ba066235911 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -669,6 +669,9 @@ static bool scsi_end_request(struct request *req, blk_status_t error,
> struct scsi_device *sdev = cmd->device;
> struct request_queue *q = sdev->request_queue;
>
> + if (is_mpath_request(req))
> + scsi_mpath_end_request(req);
> +
[Severity: Low]
Are the functions is_mpath_request() and mpath_qd_iopolicy() defined anywhere?
It looks like they are used in this patch but not declared, which would cause
a build failure.
[Severity: High]
Does calling scsi_mpath_end_request() before blk_update_request() cause double
accounting on partial completions?
If blk_update_request() returns true for a partial completion, the request is
retried. Since scsi_mpath_end_request() has already decremented
mpath_nr_active and called bdev_end_io_acct() without clearing the state
flags, a later completion will decrement these again. Should this be called
after blk_update_request() finishes the entire request?
> if (blk_update_request(req, error, bytes))
> return true;
>
[ ... ]
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 8ecfb94049db5..c6571a36e577b 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -60,6 +60,8 @@ struct scsi_pointer {
> #define SCMD_FAIL_IF_RECOVERING (1 << 4)
> /* flags preserved across unprep / reprep */
> #define SCMD_PRESERVED_FLAGS (SCMD_INITIALIZED | SCMD_FAIL_IF_RECOVERING)
> +#define SCMD_MPATH_IO_STATS (1 << 5)
> +#define SCMD_MPATH_CNT_ACTIVE (1 << 6)
[Severity: High]
Can we leak mpath_nr_active and in-flight I/O statistics when a command is
requeued?
In scsi_queue_rq(), cmd->flags is masked with SCMD_PRESERVED_FLAGS. Because
SCMD_MPATH_IO_STATS and SCMD_MPATH_CNT_ACTIVE are not added to
SCMD_PRESERVED_FLAGS, they are cleared on every retry.
When scsi_mpath_start_request() runs again on a retry, it will see the flags
as unset, increment mpath_nr_active, and call bdev_start_io_acct() a second
time. Upon completion, scsi_mpath_end_request() only cleans up once, leaving a
permanent leak. Should these new flags be added to SCMD_PRESERVED_FLAGS?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703103402.3725011-1-john.g.garry@oracle.com?part=9
next prev parent reply other threads:[~2026-07-03 11:53 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 10:33 [PATCH v3 00/17] Native SCSI multipath support John Garry
2026-07-03 10:33 ` [PATCH v3 01/17] scsi-multipath: introduce basic SCSI device support John Garry
2026-07-03 10:53 ` sashiko-bot
2026-07-06 14:39 ` John Garry
2026-07-03 10:33 ` [PATCH v3 02/17] scsi-multipath: introduce scsi_device head structure John Garry
2026-07-03 10:49 ` sashiko-bot
2026-07-06 14:45 ` John Garry
2026-07-03 10:33 ` [PATCH v3 03/17] scsi-multipath: provide sysfs link from to scsi_device John Garry
2026-07-03 11:04 ` sashiko-bot
2026-07-03 10:33 ` [PATCH v3 04/17] scsi-multipath: support iopolicy John Garry
2026-07-03 11:10 ` sashiko-bot
2026-07-06 14:49 ` John Garry
2026-07-03 10:33 ` [PATCH v3 05/17] scsi-multipath: clone each bio John Garry
2026-07-03 11:26 ` sashiko-bot
2026-07-06 14:53 ` John Garry
2026-07-03 10:33 ` [PATCH v3 06/17] scsi-multipath: clear path when device is blocked John Garry
2026-07-03 11:32 ` sashiko-bot
2026-07-06 15:04 ` John Garry
2026-07-03 10:33 ` [PATCH v3 07/17] scsi-multipath: failover handling John Garry
2026-07-03 11:40 ` sashiko-bot
2026-07-06 15:32 ` John Garry
2026-07-03 10:33 ` [PATCH v3 08/17] scsi-multipath: provide callbacks for path state John Garry
2026-07-03 11:49 ` sashiko-bot
2026-07-06 15:38 ` John Garry
2026-07-03 10:33 ` [PATCH v3 09/17] scsi-multipath: add scsi_mpath_{start,end}_request() John Garry
2026-07-03 11:53 ` sashiko-bot [this message]
2026-07-06 15:44 ` John Garry
2026-07-03 10:33 ` [PATCH v3 10/17] scsi-multipath: block PR commands John Garry
2026-07-03 12:03 ` sashiko-bot
2026-07-03 10:33 ` [PATCH v3 11/17] scsi-multipath: add delayed disk removal support John Garry
2026-07-03 12:08 ` sashiko-bot
2026-07-06 15:49 ` John Garry
2026-07-03 10:33 ` [PATCH v3 12/17] scsi: sd: add multipath disk class John Garry
2026-07-03 10:33 ` [PATCH v3 13/17] scsi: sd: support multipath disk John Garry
2026-07-03 12:24 ` sashiko-bot
2026-07-03 10:33 ` [PATCH v3 14/17] scsi: sd: add multipath disk attr groups John Garry
2026-07-03 12:25 ` sashiko-bot
2026-07-03 10:34 ` [PATCH v3 15/17] scsi: sd: add mpath_dev file John Garry
2026-07-03 12:43 ` sashiko-bot
2026-07-06 15:56 ` John Garry
2026-07-03 10:34 ` [PATCH v3 16/17] scsi: sd: add mpath_numa_nodes dev attribute John Garry
2026-07-03 12:44 ` sashiko-bot
2026-07-06 15:57 ` John Garry
2026-07-03 10:34 ` [PATCH v3 17/17] scsi: sd: add mpath_queue_depth " John Garry
2026-07-03 12:57 ` sashiko-bot
2026-07-06 15:59 ` John Garry
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=20260703115351.1C2E31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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