From: Benjamin Marzinski <bmarzins@redhat.com>
To: John Garry <john.g.garry@oracle.com>
Cc: hch@lst.de, kbusch@kernel.org, sagi@grimberg.me, axboe@fb.com,
martin.petersen@oracle.com,
james.bottomley@hansenpartnership.com, hare@suse.com,
jmeneghi@redhat.com, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, michael.christie@oracle.com,
snitzer@kernel.org, dm-devel@lists.linux.dev,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/24] scsi-multipath: failover handling
Date: Sun, 1 Mar 2026 22:57:57 -0500 [thread overview]
Message-ID: <aaUKxeoT69K435UE@redhat.com> (raw)
In-Reply-To: <20260225153627.1032500-10-john.g.garry@oracle.com>
On Wed, Feb 25, 2026 at 03:36:12PM +0000, John Garry wrote:
> For a scmd which suffers failover, requeue the master bio of each bio
> attached to its request.
>
> A handler is added in the scsi_driver structure to lookup a
> mpath_disk from a request. This is needed because the scsi_disk structure
> will manage the mpath_disk, and the code core has no method to look this
> up from the scsi_scmnd.
>
> Failover occurs when the scsi_cmnd has failed and it is discovered that the
> original scsi_device has transport down.
>
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> ---
> drivers/scsi/scsi_error.c | 12 ++++++
> drivers/scsi/scsi_lib.c | 9 +++-
> drivers/scsi/scsi_multipath.c | 80 +++++++++++++++++++++++++++++++++++
> include/scsi/scsi.h | 1 +
> include/scsi/scsi_driver.h | 3 ++
> include/scsi/scsi_multipath.h | 14 ++++++
> 6 files changed, 118 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index f869108fd9693..0fd1b46764c3f 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -40,6 +40,7 @@
> #include <scsi/scsi_ioctl.h>
> #include <scsi/scsi_dh.h>
> #include <scsi/scsi_devinfo.h>
> +#include <scsi/scsi_multipath.h>
> #include <scsi/sg.h>
>
> #include "scsi_priv.h"
> @@ -1901,12 +1902,16 @@ bool scsi_noretry_cmd(struct scsi_cmnd *scmd)
> enum scsi_disposition scsi_decide_disposition(struct scsi_cmnd *scmd)
> {
I'm no scsi expert, but the checks in scsi_decide_disposition() don't
look quite right to me. You only failover in cases were it the code
might want to retry (and when the device is offline), but there are
other cases, when you don't want to retry the same path, where it would
make sense to try another path, DID_TRANSPORT_FAILFAST for example.
As a more general issue, since you are already cloning the bios,
couldn't you just trigger the failovers in scsi_mpath_clone_end_io().
blk_path_error() can tell you which bios should be retried. That seems
like a much simpler approach than trying to intercept the request before
it completes the clones, and I don't see what you're losing by letting
the clones complete, and dealing requeueing there (again, I'm no scsi
expert).
> enum scsi_disposition rtn;
> + struct request *req = scsi_cmd_to_rq(scmd);
>
> /*
> * if the device is offline, then we clearly just pass the result back
> * up to the top level.
> */
> if (!scsi_device_online(scmd->device)) {
> + if (scsi_is_mpath_request(req))
> + return scsi_mpath_failover_disposition(scmd);
> +
> SCSI_LOG_ERROR_RECOVERY(5, scmd_printk(KERN_INFO, scmd,
> "%s: device offline - report as SUCCESS\n", __func__));
> return SUCCESS;
> diff --git a/drivers/scsi/scsi_multipath.c b/drivers/scsi/scsi_multipath.c
> index c3e0f792e921f..16b1f84fc552c 100644
> --- a/drivers/scsi/scsi_multipath.c
> +++ b/drivers/scsi/scsi_multipath.c
> @@ -518,6 +518,86 @@ void scsi_mpath_put_head(struct scsi_mpath_head *scsi_mpath_head)
> }
> EXPORT_SYMBOL_GPL(scsi_mpath_put_head);
>
> +bool scsi_is_mpath_request(struct request *req)
> +{
> + return is_mpath_request(req);
> +}
> +EXPORT_SYMBOL_GPL(scsi_is_mpath_request);
> +
> +static inline void bio_list_add_clone_master(struct bio_list *bl,
> + struct bio *clone)
> +{
> + struct scsi_mpath_clone_bio *scsi_mpath_clone_bio;
> + struct bio *master_bio;
> +
> + if (clone->bi_next)
> + bio_list_add_clone_master(bl, clone->bi_next);
This is a pretty minimal function, but a request could have a lot of
merged bios, so you probably want to hande them iteratively, instead of
recursing into the function, and eating up stack space unnecessarily.
Also, this reverses the bio's order when adding them to the requeue
list.
-Ben
> +
> + scsi_mpath_clone_bio = scsi_mpath_to_master_bio(clone);
> + master_bio = scsi_mpath_clone_bio->master_bio;
> +
> + if (bl->tail)
> + bl->tail->bi_next = master_bio;
> + else
> + bl->head = master_bio;
> +
> + bl->tail = master_bio;
> +
> + bio_put(clone);
> +}
next prev parent reply other threads:[~2026-03-02 3:58 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 15:36 [PATCH 00/24] Native SCSI multipath support John Garry
2026-02-25 15:36 ` [PATCH 01/24] scsi: core: add SCSI_MAX_QUEUE_DEPTH John Garry
2026-03-03 6:52 ` Hannes Reinecke
2026-03-03 7:45 ` John Garry
2026-02-25 15:36 ` [PATCH 02/24] scsi-multipath: introduce basic SCSI device support John Garry
2026-03-02 2:16 ` Benjamin Marzinski
2026-03-02 11:33 ` John Garry
2026-03-02 2:22 ` Benjamin Marzinski
2026-03-02 11:39 ` John Garry
2026-03-03 5:39 ` Benjamin Marzinski
2026-03-03 8:01 ` Hannes Reinecke
2026-03-03 14:20 ` Benjamin Marzinski
2026-03-05 15:59 ` John Garry
2026-03-03 6:57 ` Hannes Reinecke
2026-03-03 7:45 ` John Garry
2026-02-25 15:36 ` [PATCH 03/24] scsi-multipath: introduce scsi_device head structure John Garry
2026-03-02 2:50 ` Benjamin Marzinski
2026-03-02 12:00 ` John Garry
2026-03-03 7:13 ` Hannes Reinecke
2026-03-03 7:50 ` John Garry
2026-02-25 15:36 ` [PATCH 04/24] scsi-multipath: introduce scsi_mpath_device_class John Garry
2026-03-02 2:54 ` Benjamin Marzinski
2026-03-02 12:01 ` John Garry
2026-03-03 7:16 ` Hannes Reinecke
2026-03-03 10:53 ` John Garry
2026-02-25 15:36 ` [PATCH 05/24] scsi-multipath: provide sysfs link from to scsi_device John Garry
2026-03-03 7:19 ` Hannes Reinecke
2026-03-03 10:49 ` John Garry
2026-02-25 15:36 ` [PATCH 06/24] scsi-multipath: support iopolicy John Garry
2026-02-25 15:36 ` [PATCH 07/24] scsi-multipath: clone each bio John Garry
2026-03-02 3:21 ` Benjamin Marzinski
2026-03-02 12:12 ` John Garry
2026-03-02 16:27 ` Benjamin Marzinski
2026-03-02 17:16 ` John Garry
2026-02-25 15:36 ` [PATCH 08/24] scsi-multipath: clear path when decide is blocked John Garry
2026-02-25 15:36 ` [PATCH 09/24] scsi-multipath: failover handling John Garry
2026-03-02 3:57 ` Benjamin Marzinski [this message]
2026-03-02 12:20 ` John Garry
2026-03-04 5:46 ` Benjamin Marzinski
2026-03-04 11:11 ` John Garry
2026-02-25 15:36 ` [PATCH 10/24] scsi-multipath: add scsi_mpath_{start,end}_request() John Garry
2026-03-02 4:08 ` Benjamin Marzinski
2026-03-02 12:20 ` John Garry
2026-03-04 6:13 ` Benjamin Marzinski
2026-03-04 11:11 ` John Garry
2026-03-05 2:37 ` Benjamin Marzinski
2026-02-25 15:36 ` [PATCH 11/24] scsi-multipath: add scsi_mpath_ioctl() John Garry
2026-02-25 15:36 ` [PATCH 12/24] scsi-multipath: provide callbacks for path state John Garry
2026-03-03 5:31 ` Benjamin Marzinski
2026-02-25 15:36 ` [PATCH 13/24] scsi-multipath: set disk device_groups John Garry
2026-02-25 15:36 ` [PATCH 14/24] scsi-multipath: add PR support John Garry
2026-02-25 15:36 ` [PATCH 15/24] scsi: sd: refactor PR ops John Garry
2026-02-25 15:36 ` [PATCH 16/24] scsi: sd: add multipath disk class John Garry
2026-02-25 15:36 ` [PATCH 17/24] scsi: sd: add sd_mpath_{start,end}_command() John Garry
2026-02-25 15:36 ` [PATCH 18/24] scsi: sd: add sd_mpath_ioctl() John Garry
2026-02-25 15:36 ` [PATCH 19/24] scsi: sd: add multipath PR support John Garry
2026-02-25 15:36 ` [PATCH 20/24] scsi: sd: add sd_mpath_to_disk() John Garry
2026-02-25 15:36 ` [PATCH 21/24] scsi: sd: support multipath disk John Garry
2026-03-10 2:40 ` Benjamin Marzinski
2026-03-10 10:12 ` John Garry
2026-03-10 15:19 ` Benjamin Marzinski
2026-02-25 15:36 ` [PATCH 22/24] scsi: sd: add mpath_dev file John Garry
2026-02-25 15:36 ` [PATCH 23/24] scsi: sd: add mpath_numa_nodes dev attribute John Garry
2026-02-25 15:36 ` [PATCH 24/24] 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=aaUKxeoT69K435UE@redhat.com \
--to=bmarzins@redhat.com \
--cc=axboe@fb.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=james.bottomley@hansenpartnership.com \
--cc=jmeneghi@redhat.com \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.com \
--cc=sagi@grimberg.me \
--cc=snitzer@kernel.org \
/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