Re: [PATCH 18/18] nvme: let controller deletion wait out a fencing window

[Hannes Reinecke]

On 9/18/26 8:14 PM, Mohamed Khalfella wrote:
> DELETING is not reachable from FENCING or FENCED, so during a fencing
> window nvme_delete_ctrl() fails with -EBUSY. Its callers assume
> deleting a live controller cannot fail: a sysfs disconnect is silently
> dropped after the delete_controller node is already gone, rdma device
> removal returns with the controller still holding resources on the
> outgoing device, and module unload leaks live controllers.
>
> Fencing is time-bounded and always ends in a state that allows
> deletion. Add nvme_delete_ctrl_wait(), which waits on ctrl->state_wq
> for the fencing window to end and retries, and use it in the tcp/rdma
> module exit paths and rdma device removal. Make nvme_delete_ctrl_sync()
> wait the same way so a sysfs disconnect during fencing is delayed
> instead of dropped.
>
> nvme-fc's remoteport unregister with dev_loss_tmo == 0 keeps the
> non-waiting call since it runs under rport->lock; it does not need to
> wait, as dev_loss_end has already expired and the reconnect path
> deletes the controller once fencing completes.
>
> Signed-off-by: Mohamed Khalfella <mkhalfella@xxxxxxxxxxxxxxx>
> ---
>   drivers/nvme/host/core.c | 41 ++++++++++++++++++++++++++++++++++++++--
>   drivers/nvme/host/nvme.h |  1 +
>   drivers/nvme/host/rdma.c |  4 ++--
>   drivers/nvme/host/tcp.c  |  2 +-
>   4 files changed, 43 insertions(+), 5 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