[PATCH v4 11/15] nvme-rdma: Use CCR to recover controller that hits an error

[Randy Jennings]

On Fri, Mar 27, 2026 at 5:46 PM Mohamed Khalfella
<mkhalfella at purestorage.com> 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 at purestorage.com>
> +static void nvme_rdma_fencing_work(struct work_struct *work)
> +{
> +       struct nvme_rdma_ctrl *rdma_ctrl = container_of(work,
> +                       struct nvme_rdma_ctrl, fencing_work);
> +       struct nvme_ctrl *ctrl = &rdma_ctrl->ctrl;
> +       int ret;
> +
> +       ret = nvme_fence_ctrl(ctrl);
> +       if (ret)
> +               dev_info(ctrl->device, "CCR failed with error %d\n", ret);
> +
> +       nvme_change_ctrl_state(ctrl, NVME_CTRL_FENCED);
> +       if (nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
> +               queue_work(nvme_reset_wq, &rdma_ctrl->err_work);
> +}
Same as tcp, I think we should
    dev_warn(ctrl->device, "starting error recovery\n");
before queuing the work.

> @@ -1957,13 +1981,15 @@ static enum blk_eh_timer_return nvme_rdma_timeout(struct request *rq)

> -       if (nvme_ctrl_state(&ctrl->ctrl) != NVME_CTRL_LIVE) {
> +       state = nvme_ctrl_state(&ctrl->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
If the change to tcp to not call nvme_tcp_error_recovery() happens,
a congruent change should happen here also.

Sincerely,
Randy Jennings