All of lore.kernel.org
 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 v9 1/9] scsi: ibmvfc: add basic FPIN support
Date: Fri, 11 Sep 2026 02:42:37 +0000	[thread overview]
Message-ID: <20260911024238.355391F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260911020817.1033789-1-tyreld@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The target search function `ibmvfc_find_target` incorrectly uses a logical OR (`||`) when checking if a target has a remote port, causing it to return NULL for all valid single-protocol targets and dropping all FPIN events.
- [Medium] The `ibmvfc_async_fpin_test` KUnit test leaks references to the `rport` device and the SCSI host upon successful completion.
- [Low] The KUnit tests rely on undeclared structures (`ibmvfc_async_crq_event` and `ibmvfc_async_subq_fpin`), leading to immediate compilation failure. This regression is fixed later in the patch series.
- [Low] Missing address-of operator '&' when passing 'vhost->host->host_lock' to spinlock macros in `ibmvfc_process_async_work`, causing a compilation error.
--

commit b979f5e231a6dc184c5b0656442cb752c9aa4313
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.

> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-core.c b/drivers/scsi/ibmvscsi/ibmvfc-core.c
> --- a/drivers/scsi/ibmvscsi/ibmvfc-core.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-core.c
[ ... ]
> @@ -3522,6 +3526,23 @@ static struct fc_els_fpin *
>  static struct ibmvfc_target *ibmvfc_find_target(struct list_head *target_list,
>  						__be64 scsi_id, __be64 wwpn,
>  						__be64 node_name)
>  {
>  	struct ibmvfc_target *tgt;
>  
>  	list_for_each_entry(tgt, target_list, queue) {
>  		if (scsi_id && cpu_to_be64(tgt->scsi_id) != scsi_id)
>  			continue;
>  		if (wwpn && cpu_to_be64(tgt->ids.port_name) != wwpn)
>  			continue;
>  		if (node_name && cpu_to_be64(tgt->ids.node_name) != node_name)
>  			continue;
>  		if (!tgt->rport || !tgt->nvme_remote_port)
>  			continue;

[Severity: High]
Does this skip all valid targets? A target is typically either a SCSI or NVMe
target, but not both simultaneously. Checking with a logical OR means we
continue the loop whenever either one is NULL, causing ibmvfc_find_target()
to always return NULL and subsequently drop all FPIN events.

>  		return tgt;
>  	}
>  
>  	return NULL;
>  }
[ ... ]
> +static void ibmvfc_process_async_work(struct work_struct *work)
> +{
> +	struct ibmvfc_async_work *aw;
> +	struct ibmvfc_async_crq *crq;
> +	struct ibmvfc_target *tgt;
> +	struct ibmvfc_host *vhost;
> +	struct fc_els_fpin *fpin;
> +	unsigned long flags;
> +
> +	aw = container_of_const(work, struct ibmvfc_async_work, async_work_s);
> +	vhost = aw->vhost;
> +	crq = &aw->crq;
> +
> +	if (!crq->scsi_id && !crq->wwpn && !crq->node_name)
> +		goto free;
> +
> +	spin_lock_irqsave(vhost->host->host_lock, flags);

[Severity: Low]
Can this compile successfully? The spinlock macros expect a pointer, but
vhost->host->host_lock is passed by value here, which will result in an
incompatible type compilation error. Should this use the address-of operator
(&vhost->host->host_lock)?

> +	tgt = ibmvfc_find_target(&vhost->scsi_scrqs.targets, crq->scsi_id,
> +				 crq->wwpn, crq->node_name);
> +	if (!tgt) {
> +		/* Target not found in scsi_scrqs, search nvme_scrqs */
> +		tgt = ibmvfc_find_target(&vhost->nvme_scrqs.targets,
> +					 crq->scsi_id, crq->wwpn,
> +					 crq->node_name);
> +	}
> +
> +	if (tgt) {
> +		kref_get(&tgt->kref);
> +		spin_unlock_irqrestore(vhost->host->host_lock, flags);

[Severity: Low]
This is also missing the address-of operator and will cause a compilation
error.

> +	} else {
> +		spin_unlock_irqrestore(vhost->host->host_lock, flags);

[Severity: Low]
This is also missing the address-of operator.

> +		dev_err_ratelimited(vhost->dev, "Invalid target for FPIN\n");
> +		goto free;
> +	}
> +
[ ... ]
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc_kunit.c b/drivers/scsi/ibmvscsi/ibmvfc_kunit.c
> new file mode 100644
> index 0000000000000..80e7f8e0fd700
> --- /dev/null
> +++ b/drivers/scsi/ibmvscsi/ibmvfc_kunit.c
> @@ -0,0 +1,408 @@
[ ... ]
> +static void ibmvfc_async_fpin_test(struct kunit *test)
> +{
> +	u64 post[IBMVFC_AE_FPIN_CONGESTION_CLEARED + 1];
> +	u64 pre[IBMVFC_AE_FPIN_CONGESTION_CLEARED + 1];
> +	struct ibmvfc_async_crq_event ae[IBMVFC_AE_FPIN_CONGESTION_CLEARED + 1] = {
> +		[0 ... IBMVFC_AE_FPIN_CONGESTION_CLEARED] = { .type = IBMVFC_ASYNC_CRQ_MAIN },
> +	};

[Severity: Low]
Does this test rely on an undeclared structure? The struct
ibmvfc_async_crq_event doesn't appear to be declared yet in this patch,
which breaks the build if KUnit tests are enabled. I noticed this gets
resolved in a subsequent commit, but it breaks the build here.

> +	enum ibmvfc_ae_fpin_status fs;
> +	struct fc_host_attrs *fc_host;
> +	struct ibmvfc_target *tgt;
> +	struct ibmvfc_host *vhost;
> +	struct fc_rport *rport;
> +	unsigned long flags;
[ ... ]
> +	KUNIT_EXPECT_EQ(test, pre[IBMVFC_AE_FPIN_CONGESTION_CLEARED],
> +			post[IBMVFC_AE_FPIN_CONGESTION_CLEARED]);
> +
> +	kref_put(&tgt->kref, ibmvfc_release_tgt);
> +}

[Severity: Medium]
Does this test leak device references? Early in ibmvfc_async_fpin_test(),
scsi_host_get() and get_device(&rport->dev) are called to acquire references,
but they don't seem to have corresponding scsi_host_put(vhost->host) and
put_device(&rport->dev) cleanup calls at the end of the test function.

> +
> +/**
> + * ibmvfc_full_fpin_test - unit test for IBMVFC_AE_FPIN parts of ibmvfc_handle_async
[ ... ]
> +static void ibmvfc_extended_fpin_test(struct kunit *test)
> +{
> +	enum ibmvfc_ae_fpin_status fs;
> +	struct ibmvfc_async_subq_fpin crq[IBMVFC_AE_FPIN_CONGESTION_CLEARED+1] = {};

[Severity: Low]
Similar to the ibmvfc_async_crq_event array above, this instantiates an array
of struct ibmvfc_async_subq_fpin which is currently undeclared in this
patchset, causing a build failure.

> +	struct ibmvfc_async_subq_fpin
> +		crqcn[IBMVFC_AE_FPIN_PORT_CONGESTED][FPIN_CONGN_DEVICE_SPEC+1] = {};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-ibmvfc-fpin-support-v8-0-b27183b055af@linux.ibm.com?part=1

  reply	other threads:[~2026-09-11  2:42 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-09 19:07 [PATCH v8 0/9] scsi: ibmvfc: make ibmvfc support FPIN messages Dave Marquardt via B4 Relay
2026-09-11  2:08 ` Tyrel Datwyler
2026-09-09 19:07 ` Dave Marquardt
2026-09-09 19:07 ` [PATCH v8 1/9] scsi: ibmvfc: add basic FPIN support Dave Marquardt via B4 Relay
2026-09-09 19:07   ` Dave Marquardt
2026-09-09 19:29   ` sashiko-bot
2026-09-11  0:46     ` Tyrel Datwyler
2026-09-09 19:07 ` [PATCH v8 2/9] scsi: ibmvfc: add NOOP command support Dave Marquardt via B4 Relay
2026-09-09 19:07   ` Dave Marquardt
2026-09-09 19:19   ` sashiko-bot
2026-09-10 23:14   ` Tyrel Datwyler
2026-09-09 19:07 ` [PATCH v8 3/9] scsi: ibmvfc: add FPIN extended flag and async sub-CRQ queue handle Dave Marquardt via B4 Relay
2026-09-09 19:07   ` Dave Marquardt
2026-09-10 23:15   ` Tyrel Datwyler
2026-09-09 19:07 ` [PATCH v8 4/9] scsi: ibmvfc: extend async event handlers for async sub-CRQ events Dave Marquardt via B4 Relay
2026-09-09 19:07   ` Dave Marquardt
2026-09-09 19:23   ` sashiko-bot
2026-09-10 23:18   ` Tyrel Datwyler
2026-09-09 19:08 ` [PATCH v8 5/9] scsi: ibmvfc: add interrupt routine for asynchronous sub CRQ Dave Marquardt via B4 Relay
2026-09-09 19:08   ` Dave Marquardt
2026-09-10 23:19   ` Tyrel Datwyler
2026-09-09 19:08 ` [PATCH v8 6/9] scsi: ibmvfc: extend channel reg/dereg helpers for async sub-CRQ Dave Marquardt via B4 Relay
2026-09-09 19:08   ` Dave Marquardt
2026-09-10 23:19   ` Tyrel Datwyler
2026-09-09 19:08 ` [PATCH v8 7/9] scsi: ibmvfc: fix IRQ leak and guard deregister on channel reg failure Dave Marquardt via B4 Relay
2026-09-09 19:08   ` Dave Marquardt
2026-09-09 19:26   ` sashiko-bot
2026-09-10 23:22   ` Tyrel Datwyler
2026-09-09 19:08 ` [PATCH v8 8/9] scsi: ibmvfc: register and use asynchronous sub CRQ for events Dave Marquardt via B4 Relay
2026-09-09 19:08   ` Dave Marquardt
2026-09-09 19:26   ` sashiko-bot
2026-09-10 23:34   ` Tyrel Datwyler
2026-09-09 19:08 ` [PATCH v8 9/9] scsi: ibmvfc: handle extended FPIN events Dave Marquardt via B4 Relay
2026-09-09 19:08   ` Dave Marquardt
2026-09-09 19:28   ` sashiko-bot
2026-09-10 23:42   ` Tyrel Datwyler
2026-09-11  2:08 ` [PATCH v9 1/9] scsi: ibmvfc: add basic FPIN support Tyrel Datwyler
2026-09-11  2:42   ` sashiko-bot [this message]
2026-09-11  2:08 ` [PATCH v9 2/9] scsi: ibmvfc: add NOOP command support Tyrel Datwyler
2026-09-11  2:21   ` sashiko-bot
2026-09-11  2:08 ` [PATCH v9 3/9] scsi: ibmvfc: add FPIN extended flag and async sub-CRQ queue handle Tyrel Datwyler
2026-09-11  2:08 ` [PATCH v9 4/9] scsi: ibmvfc: extend async event handlers for async sub-CRQ events Tyrel Datwyler
2026-09-11  2:40   ` sashiko-bot
2026-09-11  2:08 ` [PATCH v9 5/9] scsi: ibmvfc: add interrupt routine for asynchronous sub CRQ Tyrel Datwyler
2026-09-11  2:31   ` sashiko-bot
2026-09-11  2:08 ` [PATCH v9 6/9] scsi: ibmvfc: extend channel reg/dereg helpers for async sub-CRQ Tyrel Datwyler
2026-09-11  2:08 ` [PATCH v9 7/9] scsi: ibmvfc: fix IRQ leak and guard deregister on channel reg failure Tyrel Datwyler
2026-09-11  2:27   ` sashiko-bot
2026-09-11  2:08 ` [PATCH v9 8/9] scsi: ibmvfc: register and use asynchronous sub CRQ for events Tyrel Datwyler
2026-09-11  2:23   ` sashiko-bot
2026-09-11  2:08 ` [PATCH v9 9/9] scsi: ibmvfc: handle extended FPIN events Tyrel Datwyler
2026-09-11  2:26   ` sashiko-bot
2026-09-11  2:12 ` [PATCH v8 0/9] scsi: ibmvfc: make ibmvfc support FPIN messages Tyrel Datwyler
  -- strict thread matches above, loose matches on Subject: below --
2026-09-11  2:19 [PATCH v9 " Tyrel Datwyler
2026-09-11  2:19 ` [PATCH v9 1/9] scsi: ibmvfc: add basic FPIN support Tyrel Datwyler
2026-09-11  2:38   ` sashiko-bot
2026-09-11  3:40     ` 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=20260911024238.355391F000FF@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 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.