Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jesse Taube" <jtaubepe@redhat.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 02/13] nvme: add NVME_CTRL_MARGINAL flag
Date: Wed, 12 Aug 2026 18:21:41 +0000	[thread overview]
Message-ID: <20260812182142.3207A1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260812181300.3712426-3-jtaubepe@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The NVME_CTRL_MARGINAL flag is cleared on the wrong structure's flags field in the Fibre Channel transport.
- [Medium] The NVME_CTRL_MARGINAL flag is not cleared universally on all controller resets, leaving non-FC transports and manual resets permanently in a marginal state.
--

--- Patch [2]: [PATCH 02/13] nvme: add NVME_CTRL_MARGINAL flag ---
commit f9c336bbdc7993d3daa484b869cd6845d7fce7a7
Author: Bryan Gurney <bgurney@redhat.com>

nvme: add NVME_CTRL_MARGINAL flag
    
Add a new controller flag, NVME_CTRL_MARGINAL, to help multipath I/O
policies to react to a path that is set to a "marginal" state.
The flag is cleared on controller reset, which is often the case when
faulty cabling or transceiver hardware is replaced.

[ ... ]

> diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
> index 04363b9c4489e..d2ca65f70a0c5 100644
> --- a/drivers/nvme/host/fc.c
> +++ b/drivers/nvme/host/fc.c
> @@ -788,6 +788,10 @@ nvme_fc_ctrl_connectivity_loss(struct nvme_fc_ctrl *ctrl)
>  		"Reconnect", ctrl->cnum);
>  
>  	set_bit(ASSOC_FAILED, &ctrl->flags);
> +
> +	/* clear 'marginal' flag as controller will be reset */
> +	clear_bit(NVME_CTRL_MARGINAL, &ctrl->flags);

[Severity: High]
Does this clear the flag on the wrong structure?

Here, ctrl is a pointer to struct nvme_fc_ctrl. Clearing the bit on
&ctrl->flags will affect the FC-specific flags field instead of the intended
core NVMe controller flags (&ctrl->ctrl.flags).

[Severity: Medium]
Will other transports remain in a marginal state indefinitely?

The commit message mentions the flag is cleared on controller reset, but the
clearing logic is only added here in the FC-specific connectivity loss handler.

Should this flag instead be cleared universally inside nvme_reset_ctrl() in
drivers/nvme/host/core.c to ensure PCIe, TCP, and RDMA paths also recover
after a reset?

drivers/nvme/host/core.c:nvme_reset_ctrl() {
    if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
        return -EBUSY;
    ...

> +
>  	nvme_reset_ctrl(&ctrl->ctrl);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812181300.3712426-1-jtaubepe@redhat.com?part=2

  reply	other threads:[~2026-08-12 18:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 18:12 [PATCH 00/13] nvme-fc: FPIN link integrity handling Jesse Taube
2026-08-12 18:12 ` [PATCH 01/13] fc_els: use 'union fc_tlv_desc' Jesse Taube
2026-08-12 18:26   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 02/13] nvme: add NVME_CTRL_MARGINAL flag Jesse Taube
2026-08-12 18:21   ` sashiko-bot [this message]
2026-08-12 18:12 ` [PATCH 03/13] nvme-multipath: numa support for marginal paths Jesse Taube
2026-08-12 18:29   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 04/13] nvme-multipath: queue-depth " Jesse Taube
2026-08-12 18:12 ` [PATCH 05/13] nvme-multipath: round-robin " Jesse Taube
2026-08-12 18:26   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 06/13] nvme: sysfs: emit the marginal path state in show_state() Jesse Taube
2026-08-12 18:21   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 07/13] scsi: scsi_transport_fc: Add set_rport_marginal to fc_function_template Jesse Taube
2026-08-12 18:28   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 08/13] scsi: scsi_transport_fc: user support for clearing NVME_CTRL_MARGINAL Jesse Taube
2026-08-12 18:24   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 09/13] nvme-fc: add nvme_fc_set_remoteport_fpin() Jesse Taube
2026-08-12 18:27   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 10/13] scsi: qla2xxx: enable FPIN notification for NVMe Jesse Taube
2026-08-12 18:34   ` sashiko-bot
2026-08-12 19:38     ` Jesse Taube
2026-08-12 18:12 ` [PATCH 11/13] scsi: lpfc: " Jesse Taube
2026-08-12 18:35   ` sashiko-bot
2026-08-12 18:12 ` [PATCH 12/13] nvme: fcloop: Add set_rport_marginal to sysfs Jesse Taube
2026-08-12 18:31   ` sashiko-bot
2026-08-12 18:34   ` Jesse Taube
2026-08-12 18:13 ` [PATCH 13/13] docs: nvme-multipath: Add FC-NVMe marginal state Jesse Taube
2026-08-12 18:26   ` sashiko-bot
2026-08-12 18:46   ` Randy Dunlap
2026-08-12 18:50     ` Randy Dunlap

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=20260812182142.3207A1F00A3E@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=jtaubepe@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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