From: sashiko-bot@kernel.org
To: "Tyrel Datwyler" <tyreld@linux.ibm.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 18/29] ibmvfc: update state machine to process NVMe/FC targets
Date: Tue, 23 Jun 2026 01:55:09 +0000 [thread overview]
Message-ID: <20260623015510.545B11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260623013035.3436640-19-tyreld@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] NVMe targets leak memory and become permanently stranded because their cleanup logic is omitted from the target deletion phase in ibmvfc_do_work().
- [High] Asynchronous ELS events (LOGO, PRLO, PLOGI) from NVMe targets are ignored because the event handler only loops over the SCSI target list.
--
commit 2221ef8b59f01b903ca3e2cc56b9bd27be8a9dc1
Author: Tyrel Datwyler <tyreld@linux.ibm.com>
ibmvfc: update state machine to process NVMe/FC targets
Update the host work loop and target state-machine helpers to process
NVMe targets in addition to SCSI targets.
> diff --git a/drivers/scsi/ibmvscsi/ibmvfc-core.c b/drivers/scsi/ibmvscsi/ibmvfc-core.c
> index 13e513bfd0a86..9a6a885aa57ed 100644
> --- a/drivers/scsi/ibmvscsi/ibmvfc-core.c
> +++ b/drivers/scsi/ibmvscsi/ibmvfc-core.c
[ ... ]
> @@ -5962,6 +5992,12 @@ static void ibmvfc_do_work(struct ibmvfc_host *vhost)
> break;
> }
> }
> + list_for_each_entry(tgt, &vhost->nvme_scrqs.targets, queue) {
> + if (tgt->action == IBMVFC_TGT_ACTION_LOGOUT_RPORT) {
> + tgt->job_step(tgt);
> + break;
> + }
> + }
>
> if (ibmvfc_dev_logo_to_do(vhost)) {
> spin_unlock_irqrestore(vhost->host->host_lock, flags);
[Severity: High]
Does this code also need to loop over nvme_scrqs.targets for final target
deletion?
Looking further down in ibmvfc_do_work(), there is a loop handling
IBMVFC_TGT_ACTION_DEL_RPORT and IBMVFC_TGT_ACTION_DEL_AND_LOGOUT_RPORT:
list_for_each_entry(tgt, &vhost->scsi_scrqs.targets, queue) {
if (tgt->action == IBMVFC_TGT_ACTION_DEL_RPORT) {
tgt_dbg(tgt, "Deleting rport\n");
rport = tgt->rport;
tgt->rport = NULL;
list_del(&tgt->queue);
ibmvfc_set_tgt_action(tgt, IBMVFC_TGT_ACTION_DELETED_RPORT);
...
Since this loop only processes scsi_scrqs.targets, wouldn't NVMe targets in
the DEL_RPORT state be leaked and stranded?
[ ... ]
[Severity: High]
Are asynchronous ELS events from NVMe targets being ignored?
Looking at ibmvfc_handle_async(), which processes events like LOGO, PRLO,
and PLOGI, the loop only iterates over the SCSI targets:
case IBMVFC_AE_ELS_LOGO:
case IBMVFC_AE_ELS_PRLO:
case IBMVFC_AE_ELS_PLOGI:
list_for_each_entry(tgt, &vhost->scsi_scrqs.targets, queue) {
Since the NVMe targets are now in a separate nvme_scrqs.targets list,
wouldn't an explicit logout or state change from an NVMe target be dropped,
leaving the driver with stale state?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623013035.3436640-1-tyreld@linux.ibm.com?part=18
next prev parent reply other threads:[~2026-06-23 1:55 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 1:30 [PATCH 00/29] ibmvfc: Add NVMe-FC support Tyrel Datwyler
2026-06-23 1:30 ` [PATCH 01/29] ibmvfc: move target list from host to protocol specific channel groups Tyrel Datwyler
2026-06-23 1:49 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 02/29] ibmvfc: add NVMe/FC protocol interface definitions Tyrel Datwyler
2026-06-23 1:54 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 03/29] ibmvfc: split NVMe support into separate source file and add transport stubs Tyrel Datwyler
2026-06-23 1:50 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 04/29] ibmvfc: initialize NVMe channel configuration during driver probe Tyrel Datwyler
2026-06-23 1:51 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 05/29] ibmvfc: alloc/dealloc sub-queues for nvme channels Tyrel Datwyler
2026-06-23 1:55 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 06/29] ibmvfc: add logic for protocol specific fabric logins Tyrel Datwyler
2026-06-23 1:50 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 07/29] ibmvfc: add wrapper to get vhost associated with a channel struct Tyrel Datwyler
2026-06-23 1:30 ` [PATCH 08/29] ibmvfc: add helper for creating protocol specific discovery event Tyrel Datwyler
2026-06-23 1:30 ` [PATCH 09/29] ibmvfc: add helper to check NVMe/FC support with active channels Tyrel Datwyler
2026-06-23 1:30 ` [PATCH 10/29] ibmvfc: allocate and free NVMe channel group discover buffer Tyrel Datwyler
2026-06-23 1:30 ` [PATCH 11/29] ibmvfc: send NVMe target discovery MAD Tyrel Datwyler
2026-06-23 1:52 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 12/29] ibmvfc: add NVMe/FC Implicit Logout and Move Login support Tyrel Datwyler
2026-06-23 1:49 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 13/29] ibmvfc: add NVMe/FC Port " Tyrel Datwyler
2026-06-23 1:53 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 14/29] ibmvfc: add NVMe/FC Process " Tyrel Datwyler
2026-06-23 1:52 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 15/29] ibmvfc: add NVMe/FC Query Target support Tyrel Datwyler
2026-06-23 1:52 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 16/29] ibmvfc: allocate targets based on protocol Tyrel Datwyler
2026-06-23 1:56 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 17/29] ibmvfc: delete NVMe/FC targets as well as SCSI Tyrel Datwyler
2026-06-23 1:51 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 18/29] ibmvfc: update state machine to process NVMe/FC targets Tyrel Datwyler
2026-06-23 1:55 ` sashiko-bot [this message]
2026-06-23 1:30 ` [PATCH 19/29] ibmvfc: implement NVMe/FC stubs for local/remote port registration Tyrel Datwyler
2026-06-23 1:51 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 20/29] ibmvfc: register local nvme fc port after fabric login Tyrel Datwyler
2026-06-23 1:57 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 21/29] ibmvfc: process NVMe/FC rports in work thread Tyrel Datwyler
2026-06-23 2:00 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 22/29] ibmvfc: extend ibmvfc_debug visibility to ibmvfc-nvme.h Tyrel Datwyler
2026-06-23 1:51 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 23/29] ibmvfc: declare global function definitions Tyrel Datwyler
2026-06-23 2:04 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 24/29] ibmvfc: implement LLDD callbacks for mapping nvme-fc queues Tyrel Datwyler
2026-06-23 2:05 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 25/29] ibmvfc: implement nvme-fc LS submission transport callback Tyrel Datwyler
2026-06-23 2:08 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 26/29] ibmvfc: implement nvme-fc IO command submission callback Tyrel Datwyler
2026-06-23 2:09 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 27/29] ibmvfc: implement nvme-fc LS abort handling callback Tyrel Datwyler
2026-06-23 2:09 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 28/29] ibmvfc: implement nvme-fc FCP abort callback Tyrel Datwyler
2026-06-23 2:05 ` sashiko-bot
2026-06-23 1:30 ` [PATCH 29/29] ibmvfc: fail nvme-fc fcp-io and ls requests during transport reset Tyrel Datwyler
2026-06-23 2:04 ` sashiko-bot
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=20260623015510.545B11F000E9@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