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

[Daniel Wagner]

On Tue, Oct 20, 2026 at 06:04:38PM -0700, Mohamed Khalfella wrote:
> > 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 :)

I tried to figure it out, but I'm still not sure if I really understand
all the conditions. So bear with me.

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

Okay, this might be something worth documenting? It seems like a case we
will get bug reports in the future.

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

I'd say yes. Anyway, I don't think this needs to be addressed right away
if the current code is functional correct and we are just not as fast as
possible. 

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

Yes, I was actually about to ask about __nvme_submit_sync_cmd in this
path next. Since my questions are about optimization, I don't think we
should make the current version any more complex than it already is. We
can handle optimization later, but please document those cases in the
meantime.