[PATCH v6 09/18] nvme: Implement cross-controller reset completion

[Daniel Wagner]

On Sun, Sep 20, 2026 at 11:28:07AM -0700, Mohamed Khalfella wrote:
>  static void nvme_fw_act_work(struct work_struct *work)
>  {
>  	struct nvme_ctrl *ctrl = container_of(work,
> @@ -5099,6 +5142,9 @@ static bool nvme_handle_aen_notice(struct nvme_ctrl *ctrl, u32 result)
>  	case NVME_AER_NOTICE_DISC_CHANGED:
>  		ctrl->aen_result = result;
>  		break;
> +	case NVME_AER_NOTICE_CCR_COMPLETED:
> +		queue_work(nvme_wq, &ctrl->ccr_work);

What happens to the waiters on sctrl->ccr_list when the source
controller enters error recovery while a CCR is pending?

As far as I can tell, ccr_work itself is fine. The reset path cancels
it via nvme_stop_ctrl(), and in the error recovery path the Get Log
Page just fails once the admin queue is torn down. But the target drops
all CCRs issued by the old association when it frees the controller,
so the CCR completed AEN for them will never arrive. Nothing on the
host side walks ccr_list when the controller leaves LIVE, so
nvme_issue_wait_ccr() sleeps until min(kato, deadline - now) runs out
before nvme_fence_ctrl() tries the next source controller. In the
worst case that eats the whole fencing window.

Would it make sense to fail all pending entries (set ccrs to a failure
status and complete them under ctrl->lock) when the source controller
goes into error recovery, so the fencing code can move on to another
path right away?