Re: Connection reset in nvme-cli?

[Sagi Grimberg <sagi@grimberg.me>]

On 18/03/2024 15:40, Hannes Reinecke wrote:
> Hey Sagi,
>
> the secure-concatenation stuff is nearing completion, but there is just
> one snag: After DH-CHAP negotiation the connection has to be reset to
> start over with a TLS-encrypted connection.
>
> IE currently I have to do:
>
> nvme connect ...
> echo 1 > /sys/class/nvme/nvmeX/reset_controller
>
> which is clearly unsatisfactory.
>
> So now I have two options:
> 1) reset the controller after the call to ->create_ctrl()
>    in drivers/nvme/host/fabrics.c
> 2) reset the controller from nvme-cli after the connection
>    was established.
> The really awkward thing is that resetting the connection works
> when run from the error recovery; it's just the initial connect
> for which I need to do something 'special'.
>
> Personally, I'm not a big fan of option 2), as it means that we
> have to do a 'blind' reset, ie we have to assume that upon reset
> we'll pick up the correct key. If someone slips in a new key
> after the initial connect and the reset call the connection will
> fail as we won't be able to pick up the correct key.
> Option 1) doesn't have this problem (as the 'options' structure
> is carried over across resets, and the generated key is stored
> in there). But then the intention seems to be to move error handling
> / retries from the initial connect over to userspace.
>
> So, which way do you prefer?

Agree with you that we should handle this in the kernel. We shouldn't 
bother userspace with
the details of the initialization. However I'd like to treat the reset 
as part of the initial connect,
i.e. either it succeeds or fails, as a oneshot.