All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Marquardt <davemarq@linux.ibm.com>
To: sashiko-bot@kernel.org
Cc: "Tyrel Datwyler" <tyreld@linux.ibm.com>,
	sashiko-reviews@lists.linux.dev, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v11 04/11] scsi: ibmvfc: add basic FPIN support
Date: Fri, 25 Sep 2026 11:36:50 -0500	[thread overview]
Message-ID: <87o6dl1e59.fsf@linux.ibm.com> (raw)
In-Reply-To: <87tsnd1f2r.fsf@linux.ibm.com> (Dave Marquardt's message of "Fri, 25 Sep 2026 11:16:44 -0500")

Dave Marquardt <davemarq@linux.ibm.com> writes:

> sashiko-bot@kernel.org writes:
>
>> 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?
>
> Yes, this routine should acquire the host_lock before calling ibmvfc_handle_async.

So, the host_lock is taken early in the routine and held in this case.
I'm getting mixed messages in my research on whether return or something
like KUNIT_FAIL() is required after kunit_skip(). I will add return
statements.

>>> +		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?
>
> Yes.
>
>>> +	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);
>>> +}

-Dave

  reply	other threads:[~2026-09-25 16:36 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
2026-09-25 16:16     ` Dave Marquardt
2026-09-25 16:36       ` Dave Marquardt [this message]
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=87o6dl1e59.fsf@linux.ibm.com \
    --to=davemarq@linux.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-bot@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.