[PATCH v6 10/18] nvme-tcp: Use CCR to recover controller that hits an error
Daniel Wagner
dwagner at suse.de
Tue Oct 20 02:36:19 PDT 2026
On Sun, Sep 20, 2026 at 11:28:08AM -0700, Mohamed Khalfella wrote:
> @@ -2731,13 +2755,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
The documentation should be updated, maybe something like:
state = nvme_ctrl_state(ctrl);
if (state != NVME_CTRL_LIVE && state != NVME_CTRL_FENCING) {
/*
* If fencing has finished or we are resetting, connecting or
* deleting we should complete immediately because we may
* block controller teardown or setup sequence
* - ctrl disable/shutdown fabrics requests
* - connect requests
* - initialization admin requests
* - I/O requests that entered after unquiescing and
* the controller stopped responding
*
* All other requests should be cancelled by the error
* recovery work, so it's fine that we fail it here.
*/
nvme_tcp_complete_timed_out(rq);
return BLK_EH_DONE;
}
/*
* LIVE state should trigger the normal error recovery which will
* handle completing this request. In FENCING state the request
* must not be completed before fencing has finished, so just
* rearm the timer and let the error recovery pick it up.
*/
nvme_tcp_error_recovery(ctrl);
return BLK_EH_RESET_TIMER;
More information about the Linux-nvme
mailing list