Re: [PATCH 15/18] nvme-fc: Hold inflight requests while in FENCING state

[Hannes Reinecke]

On 9/18/26 8:14 PM, Mohamed Khalfella wrote:
> With the association torn down at the start of nvme_fc_fencing_work(),
> canceling the held requests inside nvme_fc_delete_association() would
> complete them at fence START, letting them fail over to other paths
> before CCR/CQT guarantees the target can no longer execute the original
> commands - defeating the hold this patch introduces.
>
> Split nvme_fc_delete_association() into __nvme_fc_teardown_association()
> (LLDD-facing teardown, no request completion) and
> nvme_fc_flush_held_requests() (cancel tagsets + unquiesce queues).
> nvme_fc_fencing_work() now runs only the teardown half up front and
> flushes the held requests on the FENCING -> FENCED transition. The
> queues stay quiesced across the fence so nothing new reaches the dead
> association.
>
> Update nvme_fc_fcpio_done() to not complete aborted requests or requests
> with transport errors. Held requests cannot be forced out mid-fence by
> the block layer, nvme_fc_timeout() always returns BLK_EH_RESET_TIMER and
> nvme_fc_start_ioerr_recovery() is a no-op in FENCING state. Every held
> op is FCPOP_STATE_COMPLETE before the fence starts (aborts drained,
> synchronize_rcu() done), so the flush never touches the LLDD.
>
> Signed-off-by: Mohamed Khalfella <mkhalfella@xxxxxxxxxxxxxxx>
> ---
>   drivers/nvme/host/fc.c | 116 +++++++++++++++++++++++++++++++++--------
>   1 file changed, 94 insertions(+), 22 deletions(-)
Reviewed-by: Hannes Reinecke <hare@xxxxxxxxxx>

Cheers,

Hannes
--
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@xxxxxxx                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich