From: sashiko-bot@kernel.org
To: "John Garry" <john.g.garry@oracle.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v6 15/27] scsi-multipath: clone each bio
Date: Wed, 29 Jul 2026 14:23:20 +0000 [thread overview]
Message-ID: <20260729142321.5ADAB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260729105107.255712-16-john.g.garry@oracle.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `smpdt` structure fails to implement mandatory `mpath_head_template` callbacks, leading to a NULL pointer dereference.
- [High] The clone completion callback entirely lacks the failover resubmission logic claimed in the commit message, breaking failover handling.
- [High] The `bio_pool` mempool is destroyed before waiting for active users to drain, leading to a use-after-free when in-flight cloned bios complete.
--
--- Patch [15]: [PATCH v6 15/27] scsi-multipath: clone each bio ---
commit ea53159f3e5b8959582afd4b035267bb7a201a6d
Author: John Garry <john.garry@linux.dev>
scsi-multipath: clone each bio
For failover handling, we will take the approach to resubmit each
bio.
However, unlike NVMe, for SCSI there is no guarantee that any bio submitted
is either all or none completed.
As such, for SCSI, for failover handling we will take the approach to
just re-submit the original bio. For this, clone and submit each bio.
> diff --git a/drivers/scsi/scsi_multipath.c b/drivers/scsi/scsi_multipath.c
> index 593f94aac70e9..0d439cac6447a 100644
> --- a/drivers/scsi/scsi_multipath.c
> +++ b/drivers/scsi/scsi_multipath.c
> @@ -99,6 +99,7 @@ static void scsi_mpath_head_release(struct device *dev)
> container_of(dev, struct scsi_mpath_head, dev);
> struct mpath_head *mpath_head = &scsi_mpath_head->mpath_head;
>
> + bioset_exit(&scsi_mpath_head->bio_pool);
> ida_free(&scsi_multipath_dev_ida, scsi_mpath_head->index);
> ida_destroy(&scsi_mpath_head->ida);
> mpath_head_uninit(mpath_head);
[Severity: High]
Does this code destroy the mempool before all users have drained?
When the last SCSI path is removed, scsi_mpath_head_release() calls
bioset_exit() immediately. It then calls mpath_head_uninit(), which
synchronously waits for all users to release their references.
If there are in-flight cloned bios completing, or if the block device is
still open and receives new I/O while waiting, they could access the
already-freed bio_pool via bio_put() or bio_alloc_clone().
Can this result in a use-after-free on the destroyed mempool?
[ ... ]
> @@ -237,7 +238,34 @@ static int scsi_multipath_sdev_init(struct scsi_device *sdev)
> return 0;
> }
>
> +static void scsi_mpath_clone_end_io(struct bio *clone)
> +{
> + struct bio *master_bio = clone->bi_private;
> +
> + master_bio->bi_status = clone->bi_status;
> + bio_put(clone);
> + bio_endio(master_bio);
> +}
[Severity: High]
Does this callback omit the failover resubmission logic mentioned in the
commit message?
When an underlying SCSI path fails an I/O, this function unconditionally
copies the error to master_bio and calls bio_endio().
Since the commit message states the approach is to re-submit the original
bio for failover handling, shouldn't there be code here to intercept the
error and requeue it, rather than immediately returning the error to the
issuer?
[ ... ]
> static struct mpath_head_template smpdt = {
> + .clone_bio = scsi_mpath_clone_bio,
> };
[Severity: High]
Is this struct missing mandatory mpath_head_template callbacks?
Any I/O submission to the multipath block device invokes mpath_find_path(),
which unconditionally calls mpath_head->mpdt->is_disabled(mpath_device).
Because smpdt only initializes .clone_bio, functions like is_disabled,
is_optimized, and available_path will be NULL.
Will this cause an immediate kernel panic due to a NULL pointer dereference
when an I/O is issued?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260729105107.255712-1-john.g.garry@oracle.com?part=15
next prev parent reply other threads:[~2026-07-29 14:23 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 10:50 [PATCH v6 00/27] Native SCSI Multipath support John Garry
2026-07-29 10:50 ` [PATCH v6 01/27] libmultipath: Add initial framework John Garry
2026-07-29 10:50 ` [PATCH v6 02/27] libmultipath: Add basic gendisk support John Garry
2026-07-29 11:20 ` sashiko-bot
2026-07-29 11:36 ` John Garry
2026-07-29 10:50 ` [PATCH v6 03/27] libmultipath: Add path selection support John Garry
2026-07-29 11:33 ` sashiko-bot
2026-07-29 11:41 ` John Garry
2026-07-29 10:50 ` [PATCH v6 04/27] libmultipath: Add bio handling John Garry
2026-07-29 10:50 ` [PATCH v6 05/27] libmultipath: Add support for mpath_device management John Garry
2026-07-29 11:57 ` sashiko-bot
2026-07-29 12:11 ` John Garry
2026-07-29 10:50 ` [PATCH v6 06/27] libmultipath: Add delayed removal support John Garry
2026-07-29 12:08 ` sashiko-bot
2026-07-29 12:15 ` John Garry
2026-07-29 10:50 ` [PATCH v6 07/27] libmultipath: Add sysfs helpers John Garry
2026-07-29 12:28 ` sashiko-bot
2026-07-29 12:51 ` John Garry
2026-07-29 10:50 ` [PATCH v6 08/27] libmultipath: Add support for block device IOCTL John Garry
2026-07-29 12:39 ` sashiko-bot
2026-07-29 12:53 ` John Garry
2026-07-29 10:50 ` [PATCH v6 09/27] libmultipath: Add mpath_bdev_getgeo() John Garry
2026-07-29 10:50 ` [PATCH v6 10/27] libmultipath: Add mpath_bdev_get_unique_id() John Garry
2026-07-29 10:50 ` [PATCH v6 11/27] scsi-multipath: introduce basic SCSI device support John Garry
2026-07-29 10:50 ` [PATCH v6 12/27] scsi-multipath: introduce scsi_device head structure John Garry
2026-07-29 13:46 ` sashiko-bot
2026-07-29 14:06 ` John Garry
2026-07-29 10:50 ` [PATCH v6 13/27] scsi-multipath: provide sysfs link from to scsi_device John Garry
2026-07-29 10:50 ` [PATCH v6 14/27] scsi-multipath: support iopolicy John Garry
2026-07-29 14:07 ` sashiko-bot
2026-07-29 14:11 ` John Garry
2026-07-29 10:50 ` [PATCH v6 15/27] scsi-multipath: clone each bio John Garry
2026-07-29 14:23 ` sashiko-bot [this message]
2026-07-29 14:25 ` John Garry
2026-07-29 10:50 ` [PATCH v6 16/27] scsi-multipath: clear path when device is blocked John Garry
2026-07-29 14:42 ` sashiko-bot
2026-07-29 14:51 ` John Garry
2026-07-29 10:50 ` [PATCH v6 17/27] scsi-multipath: revalidate paths upon device unblock John Garry
2026-07-29 14:54 ` sashiko-bot
2026-07-29 15:27 ` John Garry
2026-07-29 10:50 ` [PATCH v6 18/27] scsi-multipath: failover handling John Garry
2026-07-29 15:14 ` sashiko-bot
2026-07-29 15:29 ` John Garry
2026-07-29 10:50 ` [PATCH v6 19/27] scsi-multipath: provide callbacks for path state John Garry
2026-07-29 15:43 ` sashiko-bot
2026-07-29 16:54 ` John Garry
2026-07-29 10:51 ` [PATCH v6 20/27] scsi-multipath: add scsi_mpath_{start,end}_request() John Garry
2026-07-29 16:12 ` sashiko-bot
2026-07-29 16:55 ` John Garry
2026-07-29 10:51 ` [PATCH v6 21/27] scsi-multipath: add delayed disk removal support John Garry
2026-07-29 16:26 ` sashiko-bot
2026-07-29 10:51 ` [PATCH v6 22/27] scsi: sd: add multipath disk class John Garry
2026-07-29 16:33 ` sashiko-bot
2026-07-29 10:51 ` [PATCH v6 23/27] scsi: sd: add multipath disk attr groups John Garry
2026-07-29 16:48 ` sashiko-bot
2026-07-29 10:51 ` [PATCH v6 24/27] scsi: sd: support multipath disk John Garry
2026-07-29 10:51 ` [PATCH v6 25/27] scsi: sd: add mpath_dev file John Garry
2026-07-29 10:51 ` [PATCH v6 26/27] scsi: sd: add mpath_numa_nodes dev attribute John Garry
2026-07-29 10:51 ` [PATCH v6 27/27] scsi: sd: add mpath_queue_depth " 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=20260729142321.5ADAB1F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.