From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: "James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
linux-scsi@vger.kernel.org, dm-devel@lists.linux.dev
Subject: Re: [PATCH] scsi: scsi_dh: Return error pointer in scsi_dh_attached_handler_name
Date: Mon, 1 Dec 2025 20:00:02 -0500 [thread overview]
Message-ID: <aS46EpB6dijzABwA@redhat.com> (raw)
In-Reply-To: <94bce7593f2980cef43860044e5b662c3d3c0ec7.camel@suse.com>
On Thu, Nov 27, 2025 at 04:26:51PM +0100, Martin Wilck wrote:
> On Fri, 2025-11-21 at 18:48 -0500, Benjamin Marzinski wrote:
> > If scsi_dh_attached_handler_name() fails to allocate the handler
> > name,
> > dm-multipath (its only caller) assumes there is no attached device
> > handler, and sets the device up incorrectly. Return an error pointer
> > instead, so multipath can distinguish between failure and success
> > where
> > there is no attached device handler.
> >
> > Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
> > ---
> > drivers/md/dm-mpath.c | 8 ++++++++
> > drivers/scsi/scsi_dh.c | 8 +++++---
> > 2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
> > index c18358271618..063dc526fe04 100644
> > --- a/drivers/md/dm-mpath.c
> > +++ b/drivers/md/dm-mpath.c
> > @@ -950,6 +950,14 @@ static struct pgpath *parse_path(struct
> > dm_arg_set *as, struct path_selector *ps
> >
> > q = bdev_get_queue(p->path.dev->bdev);
> > attached_handler_name = scsi_dh_attached_handler_name(q,
> > GFP_KERNEL);
> > + if (IS_ERR(attached_handler_name)) {
> > + if (PTR_ERR(attached_handler_name) == -ENODEV)
> > + attached_handler_name = NULL;
>
> What's the point of continuing here if we know that the SCSI device
> doesn't exist?
we just know that it's not a SCSI device, so we clear
attached_handler_name. I suppose we could add another check to error
out here if m->hw_handler_name is set. But if it is, the setup_scsi_dh()
call just below will fail anyways, so there's not much difference.
But if you think adding that extra check makes things clearer, I'm fine
with that.
-Ben
> Thanks,
> Martin
>
> > + else {
> > + r = PTR_ERR(attached_handler_name);
> > + goto bad;
> > + }
> > + }
> > if (attached_handler_name || m->hw_handler_name) {
> > INIT_DELAYED_WORK(&p->activate_path,
> > activate_path_work);
> > r = setup_scsi_dh(p->path.dev->bdev, m,
> > &attached_handler_name, &ti->error);
> > diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
> > index 7b56e00c7df6..b9d805317814 100644
> > --- a/drivers/scsi/scsi_dh.c
> > +++ b/drivers/scsi/scsi_dh.c
> > @@ -353,7 +353,8 @@ EXPORT_SYMBOL_GPL(scsi_dh_attach);
> > * that may have a device handler attached
> > * @gfp - the GFP mask used in the kmalloc() call when allocating
> > memory
> > *
> > - * Returns name of attached handler, NULL if no handler is attached.
> > + * Returns name of attached handler, NULL if no handler is attached,
> > or
> > + * and error pointer if an error occurred.
> > * Caller must take care to free the returned string.
> > */
> > const char *scsi_dh_attached_handler_name(struct request_queue *q,
> > gfp_t gfp)
> > @@ -363,10 +364,11 @@ const char
> > *scsi_dh_attached_handler_name(struct request_queue *q, gfp_t gfp)
> >
> > sdev = scsi_device_from_queue(q);
> > if (!sdev)
> > - return NULL;
> > + return ERR_PTR(-ENODEV);
> >
> > if (sdev->handler)
> > - handler_name = kstrdup(sdev->handler->name, gfp);
> > + handler_name = kstrdup(sdev->handler->name, gfp) ? :
> > + ERR_PTR(-ENOMEM);
> > put_device(&sdev->sdev_gendev);
> > return handler_name;
> > }
next prev parent reply other threads:[~2025-12-02 1:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 23:48 [PATCH] scsi: scsi_dh: Return error pointer in scsi_dh_attached_handler_name Benjamin Marzinski
2025-11-27 15:26 ` Martin Wilck
2025-12-02 1:00 ` Benjamin Marzinski [this message]
2025-12-02 10:01 ` Martin Wilck
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=aS46EpB6dijzABwA@redhat.com \
--to=bmarzins@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mpatocka@redhat.com \
--cc=mwilck@suse.com \
--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 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.