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

[Mohamed Khalfella <mkhalfella@purestorage.com>]

On Tue 2026-10-20 11:18:04 +0200, Daniel Wagner wrote:
> 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?

You already answered it below :)

> 
> 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.

If the remaining of the fencing window (deadline - now) is less than
kato then I am fine with this scenario wasting this time anyway. If we
hit the deadline then we consider fencing done anyway. If it consumes
kato from the deadline then we retry another path.

> 
> 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?

Failing pending CCR entries that we know we are not going to complete
will help in this case. The question is where to do that. A LIVE
controller might hit an error and transition to FENCING, or manually 
reset and move to RESETTING, or deleted and go to DELETING. Do we need
to consider all these places to fail the pending CCRs?


You might have also noticed that nvme_issue_wait_ccr() calling
__nvme_submit_sync_cmd() might consume the entire fencing window if the
CCR command gets held because the source controller hits an error. This
is another area be optimized. I am inclined to leave the code as it is
today. What is being described here is an optimization that can come
later on.