Connection reset in nvme-cli?

Connection reset in nvme-cli?

[Hannes Reinecke]

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?

Cheers,

Hannes

Re: Connection reset in nvme-cli?

[Sagi Grimberg]

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.