From: sashiko-bot@kernel.org
To: "Wentao Liang" <vulab@iscas.ac.cn>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] scsi: mpt3sas: drop the sas_device reference on port add failure
Date: Wed, 04 Nov 2026 02:27:35 +0000 [thread overview]
Message-ID: <sashiko-outbox-196464@kernel.org> (raw)
In-Reply-To: <20261104021352.1467740-1-vulab@iscas.ac.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: mpt3sas: dangling sas_device->rphy in mpt3sas_transport_port_add()
--
commit 513fa7a846ccb03a4cae94cd2a076f29098310d8
Author: Wentao Liang <vulab@iscas.ac.cn>
scsi: mpt3sas: drop the sas_device reference on port add failure
This commit fixes a sas_device reference leak and clears pend_sas_rphy_add
in the out_fail error path of mpt3sas_transport_port_add() when adding a
SAS end device port fails.
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c
> index e74a526efa8db..38259dae91093 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
> @@ -866,6 +866,10 @@ mpt3sas_transport_port_add(struct MPT3SAS_ADAPTER *ioc, u16 handle,
> sas_port_delete(port);
>
> out_fail:
> + if (sas_device) {
> + sas_device->pend_sas_rphy_add = 0;
> + sas_device_put(sas_device);
> + }
[Severity: Medium]
Should this cleanup block in mpt3sas_transport_port_add() also reset
sas_device->rphy to NULL?
Earlier in mpt3sas_transport_port_add(), when adding a SAS_END_DEVICE,
sas_device->rphy is assigned before sas_rphy_add() is called:
if (mpt3sas_port->remote_identify.device_type == SAS_END_DEVICE) {
rphy = sas_end_device_alloc(port);
sas_device->rphy = rphy;
...
}
...
if ((sas_rphy_add(rphy))) {
ioc_err(ioc, "failure at %s:%d/%s()!\n",
__FILE__, __LINE__, __func__);
sas_rphy_free(rphy);
rphy = NULL;
goto out_delete_port;
}
If sas_rphy_add() fails, rphy is freed via sas_rphy_free(rphy), and only
the local rphy variable is cleared before jumping to out_delete_port and
out_fail.
Because sas_device remains on ioc->sas_device_list or
ioc->sas_device_init_list (and is also held by the caller),
sas_device_put(sas_device) in out_fail does not free sas_device, leaving
sas_device->rphy as a dangling pointer that __mpt3sas_get_sdev_by_rphy()
can match against a reallocated sas_rphy at the same address.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104021352.1467740-1-vulab@iscas.ac.cn?part=1
prev parent reply other threads:[~2026-11-04 2:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 2:13 [PATCH] scsi: mpt3sas: drop the sas_device reference on port add failure Wentao Liang
2026-11-04 2:27 ` sashiko-bot [this message]
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=sashiko-outbox-196464@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vulab@iscas.ac.cn \
/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