Re: [PATCH v3] nvme-multipath: add fail_if_no_path sysfs attribute

[Keith Busch]

On Tue, Sep 22, 2026 at 05:49:59PM -0700, Krishna Iyer wrote:
> When no usable path exists, I/O on a multipath namespace is queued
> until a path returns. With ctrl_loss_tmo=-1 that can be forever:
> during a long fabric outage any process waiting on the I/O is stuck in
> D state. We hit this on virtualization hosts, where a SIGKILLed VM
> process cannot exit while draining I/O to an unreachable NVMe/TCP
> target.
> 
> Nothing can fail this I/O without tearing something down: controller
> deletion takes every namespace on the controller with it.

I agree with Hannes that we shouldn't need a new flag for this. The
current behavior is just broken in a few ways.

We just need to restrict queue_if_no_path to only if there really are no
paths so that we actually respect the failfast_tmo.

And the ANA inaccessible and persistent-loss handling you introduced
here should just be the default without requiring a flag. But I think
you need to add a requeue_list kick in nvme_update_ns_ana_state() too in
case the ANA transition leaves the namespace inaccessible.