Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tyrel Datwyler" <tyreld@linux.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH v11 04/11] scsi: ibmvfc: add basic FPIN support
Date: Fri, 25 Sep 2026 05:03:04 +0000	[thread overview]
Message-ID: <20260925050305.6F20E1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260925044900.414340-5-tyreld@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] scsi: ibmvfc: missing scsi_host_put() in test success path
- [Medium] scsi: ibmvfc: missing host_lock around ibmvfc_handle_async() in KUnit test
--

commit 29ab8a9a78c94679b8187ae357d2978336830599
Author: Dave Marquardt <davemarq@linux.ibm.com>

scsi: ibmvfc: add basic FPIN support

Implement support for a basic level of Fabric Performance Impact
Notifications (FPIN) in the ibmvfc driver to enable monitoring of
fabric congestion and link integrity events. This includes async event
handling and KUnit test infrastructure.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc_kunit.c b/drivers/scsi/ibmvscsi/ibmvfc_kunit.c
> new file mode 100644
> index 0000000000000..ec52285b0aa22
> --- /dev/null
> +++ b/drivers/scsi/ibmvscsi/ibmvfc_kunit.c
> @@ -0,0 +1,149 @@
[ ... ]
> +static void ibmvfc_async_fpin_test(struct kunit *test)
> +{
[ ... ]
> +	vhost = ibmvfc_get_first_vhost();
> +	if (!vhost)
> +		kunit_skip(test, "No ibmvfc devices available");
[ ... ]
> +	for (fs = IBMVFC_AE_FPIN_LINK_CONGESTED; fs <= IBMVFC_AE_FPIN_CONGESTION_CLEARED; fs++) {
> +		ae[fs].valid = 0x80;
> +		ae[fs].link_state = IBMVFC_AE_LS_LINK_UP;
> +		ae[fs].fpin_status = fs;
> +		ae[fs].event = cpu_to_be64(IBMVFC_AE_FPIN);
> +		ae[fs].scsi_id = cpu_to_be64(tgt->scsi_id);
> +		ae[fs].wwpn = cpu_to_be64(tgt->wwpn);
> +		ae[fs].node_name = cpu_to_be64(tgt->ids.node_name);
> +		ibmvfc_handle_async(&ae[fs], vhost);

[Severity: Medium]
Does this invocation of ibmvfc_handle_async() need to be protected by
the host_lock?

If a concurrent device removal via ibmvfc_remove() sets vhost->state to
IBMVFC_HOST_OFFLINE and destroys fpin_workq just before this handles the
async event, could queue_work() be called on a freed workqueue?

> +		ae[fs].valid = 0;
> +		wmb(); /* ensure valid bit clear is visible before checking stats */
> +	}
> +	flush_workqueue(vhost->fpin_workq);
[ ... ]
> +	ae[0].valid = 0x80;
> +	ae[0].link_state = IBMVFC_AE_LS_LINK_UP;
> +	ae[0].fpin_status = 0; /* bad value */
> +	ae[0].event = cpu_to_be64(IBMVFC_AE_FPIN);
> +	ae[0].scsi_id = cpu_to_be64(tgt->scsi_id);
> +	ae[0].wwpn = cpu_to_be64(tgt->wwpn);
> +	ae[0].node_name = cpu_to_be64(tgt->ids.node_name);
> +	ibmvfc_handle_async(&ae[0], vhost);

[Severity: Medium]
Is the host_lock similarly required around this call to
ibmvfc_handle_async() to prevent a use-after-free if the device is
concurrently unbound?

> +	ae[0].valid = 0;
> +	wmb(); /* ensure valid bit clear is visible before checking stats */
> +	flush_workqueue(vhost->fpin_workq);
[ ... ]
> +	kref_put(&tgt->kref, ibmvfc_release_tgt);
> +	put_device(&rport->dev);
> +}

[Severity: Medium]
Does this successful exit path leak the Scsi_Host reference?

The call to ibmvfc_get_first_vhost() at the beginning of the test acquires
a reference via scsi_host_get(), but unlike the error return paths, there
doesn't appear to be a corresponding scsi_host_put() call here.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925044900.414340-1-tyreld@linux.ibm.com?part=4

  reply	other threads:[~2026-09-25  5:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-25  4:48 [PATCH v11 00/11] scsi: ibmvfc: make ibmvfc support FPIN messages Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 01/11] scsi: ibmvfc: fix IRQ leak and guard deregister on channel reg failure Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 02/11] scsi: ibmvfc: fix potential clobbering of rc after failed irq setup Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 03/11] scsi: ibmvfc: fix potential NULL pointer dereference on failed queue allocation Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 04/11] scsi: ibmvfc: add basic FPIN support Tyrel Datwyler
2026-09-25  5:03   ` sashiko-bot [this message]
2026-09-25 16:16     ` Dave Marquardt
2026-09-25 16:36       ` Dave Marquardt
2026-09-28 14:11         ` Dave Marquardt
2026-09-25  4:48 ` [PATCH v11 05/11] scsi: ibmvfc: add NOOP command support Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 06/11] scsi: ibmvfc: add FPIN extended flag and async sub-CRQ queue handle Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 07/11] scsi: ibmvfc: extend async event handlers for async sub-CRQ events Tyrel Datwyler
2026-09-25  5:00   ` sashiko-bot
2026-09-28 15:45     ` Dave Marquardt
2026-09-25  4:48 ` [PATCH v11 08/11] scsi: ibmvfc: add interrupt routine for asynchronous sub CRQ Tyrel Datwyler
2026-09-25  4:48 ` [PATCH v11 09/11] scsi: ibmvfc: extend channel reg/dereg helpers for async sub-CRQ Tyrel Datwyler
2026-09-25  5:05   ` sashiko-bot
2026-09-28 15:55     ` Dave Marquardt
2026-09-25  4:48 ` [PATCH v11 10/11] scsi: ibmvfc: register and use asynchronous sub CRQ for events Tyrel Datwyler
2026-09-25  5:09   ` sashiko-bot
2026-09-28 22:30     ` Dave Marquardt
2026-09-29 15:33       ` Tyrel Datwyler
2026-09-25  4:49 ` [PATCH v11 11/11] scsi: ibmvfc: handle extended FPIN events Tyrel Datwyler

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=20260925050305.6F20E1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tyreld@linux.ibm.com \
    /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