[PATCH 1/1] nvme-fabrics: add ENOKEY to no retry criteria for authentication failures

Daniel Wagner dwagner at suse.de
Tue Nov 25 02:34:40 PST 2025


Hi Justin,

On Mon, Nov 24, 2025 at 04:57:29PM -0800, Justin Tee wrote:
> Was under the impression that the issue with 041 is that there is a
> lingering reconnect attempt leftover from the “Test unauthenticated
> connection (should fail)” portion that interferes with the next “Test
> authenticated connection” portion of the blktest.

Yes, that was one part of the problem. FC keept continuing reconnecting
with an invalid key. The other transport would also try to reconnect
with an invalid key after the first initial connection. This is a long
standing problem and your patch fixes it for all transport.

As I said your fix is good and addresses the reconnect with an invalid
key problem. Though it doesn't address the issue that 'nvme connect'
will still return success.

> Through correcting the nvmf_should_reconnect routine, which stops
> retrying reconnect when -ENOKEY, there would be no interference in the
> second part of the test when nvme connect is with an actual key.  So,
> there will be a controller to nvme disconnect, as expected, for the
> “Test authenticated connection” portion of the test.

All the nvme tests which use 'nvme connect' do not check the return code
yet. Something I am going to add now. This should ensure that all the
transport behave from userpoint of view the same. There is no exception
for a transport to behave differently IMO. On the other hand we can't
break existing APIs, so we have to come up with an opt-in solution here.

Hope this makes it a bit more clearer.

Thanks a lot,
Daniel




More information about the Linux-nvme mailing list