mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mohamed Khalfella <mkhalfella@purestorage.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Justin Tee <justin.tee@broadcom.com>,
	Naresh Gottumukkala <nareshgottumukkala83@gmail.com>,
	Paul Ely <paul.ely@broadcom.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
	James Smart <jsmart833426@gmail.com>,
	Randy Jennings <randyj@purestorage.com>,
	Dhaval Giani <dgiani@purestorage.com>,
	Aaron Dailey <adailey@purestorage.com>,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 10/16] nvme-tcp: Use CCR to recover controller that hits an error
Date: Fri, 4 Sep 2026 16:01:10 -0700	[thread overview]
Message-ID: <20260904230110.GC5552-mkhalfella@purestorage.com> (raw)
In-Reply-To: <f27fdc8d-9aea-42d1-8f55-04d8355a50c4@suse.de>

On Mon 2026-07-13 09:17:33 +0200, Hannes Reinecke wrote:
> On 7/12/26 4:23 AM, Mohamed Khalfella wrote:
> > An alive nvme controller that hits an error now will move to FENCING
> > state instead of RESETTING state. ctrl->fencing_work attempts CCR to
> > terminate inflight IOs. Regardless of the success or failure of CCR
> > operation the controller is transitioned to RESETTING state to continue
> > error recovery process.
> > 
> > Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
> > ---
> >   drivers/nvme/host/tcp.c | 30 +++++++++++++++++++++++++++++-
> >   1 file changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
> > index ba5c7b3e2a7c..a1711dd1d3c2 100644
> > --- a/drivers/nvme/host/tcp.c
> > +++ b/drivers/nvme/host/tcp.c
> > @@ -161,6 +161,7 @@ struct nvme_tcp_ctrl {
> >   	struct sockaddr_storage src_addr;
> >   	struct nvme_ctrl	ctrl;
> >   
> > +	struct work_struct	fencing_work;
> >   	struct work_struct	err_work;
> >   	struct delayed_work	connect_work;
> >   	struct nvme_tcp_request async_req;
> > @@ -605,6 +606,12 @@ static void nvme_tcp_init_recv_ctx(struct nvme_tcp_queue *queue)
> >   
> >   static void nvme_tcp_error_recovery(struct nvme_ctrl *ctrl)
> >   {
> > +	if (nvme_change_ctrl_state(ctrl, NVME_CTRL_FENCING)) {
> > +		dev_warn(ctrl->device, "starting controller fencing\n");
> > +		queue_work(nvme_wq, &to_tcp_ctrl(ctrl)->fencing_work);
> > +		return;
> > +	}
> > +
> >   	if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
> >   		return;
> >   
> > @@ -2494,12 +2501,29 @@ static void nvme_tcp_reconnect_ctrl_work(struct work_struct *work)
> >   	nvme_tcp_reconnect_or_remove(ctrl, ret);
> >   }
> >   
> > +static void nvme_tcp_fencing_work(struct work_struct *work)
> > +{
> > +	struct nvme_tcp_ctrl *tcp_ctrl = container_of(work,
> > +			struct nvme_tcp_ctrl, fencing_work);
> > +	struct nvme_ctrl *ctrl = &tcp_ctrl->ctrl;
> > +	unsigned long rem;
> > +
> > +	rem = nvme_fence_ctrl(ctrl);
> > +	if (rem)
> > +		dev_info(ctrl->device, "CCR failed, starting error recovery\n");
> > +
> > +	nvme_change_ctrl_state(ctrl, NVME_CTRL_FENCED);
> 
> This needs to be before nvme_fence_ctrl(). Otherwise the state is 
> meaningless are we're moving to RESETTING directly afterwards.

The transition to FENCED signals that we are done with the fencing
process. Only then FENCED -> RESETTING can happen. Yes, we are switching
directly to RESETTING after that because we want to run error recovery
to teardown and bring the controller back.

The only reason FENCED exist is to prevent a controller in FENCING state
from being reset or deleted.
> 
> > +	if (nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
> > +		queue_work(nvme_reset_wq, &tcp_ctrl->err_work);
> > +}
> > +
> >   static void nvme_tcp_error_recovery_work(struct work_struct *work)
> >   {
> >   	struct nvme_tcp_ctrl *tcp_ctrl = container_of(work,
> >   				struct nvme_tcp_ctrl, err_work);
> >   	struct nvme_ctrl *ctrl = &tcp_ctrl->ctrl;
> >   
> > +	flush_work(&to_tcp_ctrl(ctrl)->fencing_work);
> 
> Not so happy with this one here.
> _If_ fencing is still running we really should not be entering here.
> And If fencing is not running we won't need to call it.
> I'd prefer some sort of WARN_ON() here if fencing is still running.

fencing_work should not be running. It should be exiting after it queued
err_work. However, it does that asynchronously. It means it could still
be running. flush_work() just makes sure it is 100% done because we are
not expecting it in the middle doing any useful work at this time.

> 
> >   	if (nvme_tcp_key_revoke_needed(ctrl))
> >   		nvme_auth_revoke_tls_key(ctrl);
> >   	nvme_stop_keep_alive(ctrl);
> > @@ -2542,6 +2566,7 @@ static void nvme_reset_ctrl_work(struct work_struct *work)
> >   		container_of(work, struct nvme_ctrl, reset_work);
> >   	int ret;
> >   
> > +	flush_work(&to_tcp_ctrl(ctrl)->fencing_work);
> 
> Same here.

This is needed in case nvme_tcp_fencing_work() loses the race as. Now
reset_work needs to flush fencing_work because it took over instead of
err_work.

> 
> >   	if (nvme_tcp_key_revoke_needed(ctrl))
> >   		nvme_auth_revoke_tls_key(ctrl);
> >   	nvme_stop_ctrl(ctrl);
> > @@ -2667,13 +2692,15 @@ static enum blk_eh_timer_return nvme_tcp_timeout(struct request *rq)
> >   	struct nvme_tcp_cmd_pdu *pdu = nvme_tcp_req_cmd_pdu(req);
> >   	struct nvme_command *cmd = &pdu->cmd;
> >   	int qid = nvme_tcp_queue_id(req->queue);
> > +	enum nvme_ctrl_state state;
> >   
> >   	dev_warn(ctrl->device,
> >   		 "I/O tag %d (%04x) type %d opcode %#x (%s) QID %d timeout\n",
> >   		 rq->tag, nvme_cid(rq), pdu->hdr.type, cmd->common.opcode,
> >   		 nvme_fabrics_opcode_str(qid, cmd), qid);
> >   
> > -	if (nvme_ctrl_state(ctrl) != NVME_CTRL_LIVE) {
> > +	state = nvme_ctrl_state(ctrl);
> > +	if (state != NVME_CTRL_LIVE && state != NVME_CTRL_FENCING) {
> >   		/*
> >   		 * If we are resetting, connecting or deleting we should
> >   		 * complete immediately because we may block controller
> > @@ -2928,6 +2955,7 @@ static struct nvme_tcp_ctrl *nvme_tcp_alloc_ctrl(struct device *dev,
> >   
> >   	INIT_DELAYED_WORK(&ctrl->connect_work,
> >   			nvme_tcp_reconnect_ctrl_work);
> > +	INIT_WORK(&ctrl->fencing_work, nvme_tcp_fencing_work);
> >   	INIT_WORK(&ctrl->err_work, nvme_tcp_error_recovery_work);
> >   	INIT_WORK(&ctrl->ctrl.reset_work, nvme_reset_ctrl_work);
> >   
> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke                  Kernel Storage Architect
> hare@suse.de                                +49 911 74053 688
> SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
> HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich

  reply	other threads:[~2026-09-04 23:01 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12  2:23 [PATCH v5 00/16] TP8028 Rapid Path Failure Recovery Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 01/16] nvmet: Rapid Path Failure Recovery set controller identify fields Mohamed Khalfella
2026-08-23  0:49   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 02/16] nvmet/debugfs: Export controller CIU and CIRN via debugfs Mohamed Khalfella
2026-08-23  0:50   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 03/16] nvmet: Implement CCR nvme command Mohamed Khalfella
2026-08-23  0:53   ` Sagi Grimberg
2026-09-04 23:17     ` Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 04/16] nvmet: Implement CCR logpage Mohamed Khalfella
2026-08-23  0:53   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 05/16] nvmet: Send an AEN on CCR completion Mohamed Khalfella
2026-08-23  0:54   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 06/16] nvme: Rapid Path Failure Recovery read controller identify fields Mohamed Khalfella
2026-08-23  0:55   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 07/16] nvme: Introduce FENCING and FENCED controller states Mohamed Khalfella
2026-08-23  0:55   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 08/16] nvme: Implement cross-controller reset recovery Mohamed Khalfella
2026-07-13  7:04   ` Hannes Reinecke
2026-09-04 23:04     ` Mohamed Khalfella
2026-08-23  0:59   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 09/16] nvme: Implement cross-controller reset completion Mohamed Khalfella
2026-07-13  7:11   ` Hannes Reinecke
2026-09-04 22:29     ` Mohamed Khalfella
2026-08-23  1:01   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 10/16] nvme-tcp: Use CCR to recover controller that hits an error Mohamed Khalfella
2026-07-13  7:17   ` Hannes Reinecke
2026-09-04 23:01     ` Mohamed Khalfella [this message]
2026-08-23  1:03   ` Sagi Grimberg
2026-09-04 22:52     ` Mohamed Khalfella
2026-09-05  2:09       ` Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 11/16] nvme-rdma: " Mohamed Khalfella
2026-07-13  7:18   ` Hannes Reinecke
2026-07-12  2:23 ` [PATCH v5 12/16] nvme-fc: Refactor IO error recovery Mohamed Khalfella
2026-07-13  7:29   ` Hannes Reinecke
2026-09-04 23:19     ` Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 13/16] nvme-fc: Use CCR to recover controller that hits an error Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 14/16] nvme-fc: Hold inflight requests while in FENCING state Mohamed Khalfella
2026-07-12  2:23 ` [PATCH v5 15/16] nvmet: Add support for CQT to nvme target Mohamed Khalfella
2026-07-13  7:35   ` Hannes Reinecke
2026-08-23  1:04   ` Sagi Grimberg
2026-07-12  2:23 ` [PATCH v5 16/16] nvme: Add support for CQT to nvme host Mohamed Khalfella
2026-07-13  7:36   ` Hannes Reinecke
2026-08-23  1:07   ` Sagi Grimberg

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=20260904230110.GC5552-mkhalfella@purestorage.com \
    --to=mkhalfella@purestorage.com \
    --cc=adailey@purestorage.com \
    --cc=axboe@kernel.dk \
    --cc=dgiani@purestorage.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jsmart833426@gmail.com \
    --cc=justin.tee@broadcom.com \
    --cc=kbusch@kernel.org \
    --cc=kch@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=nareshgottumukkala83@gmail.com \
    --cc=paul.ely@broadcom.com \
    --cc=randyj@purestorage.com \
    --cc=sagi@grimberg.me \
    /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

all inboxes | Powered by JetHome®