[PATCH 2/3] nvmet-tcp: Don't free SQ on authentication success
Alistair Francis
alistair23 at gmail.com
Sun Nov 2 17:40:59 PST 2025
On Sat, Nov 1, 2025 at 12:03 AM Christoph Hellwig <hch at lst.de> wrote:
>
> On Thu, Oct 30, 2025 at 01:51:13PM +1000, alistair23 at gmail.com wrote:
> > Curently after the host sends a REPLACETLSPSK we free the TLS keys as
> > part of calling nvmet_auth_sq_free() on success. This means when the
> > host sends a follow up REPLACETLSPSK we return CONCAT_MISMATCH as the
> > check for !nvmet_queue_tls_keyid(req->sq) fails.
> >
> > This patch ensures we don't free the TLS key on success as we might need
> > it again in the future.
>
> I initially though we'd now keep it around for the lifetime of the
> queue, but I think we'll still free it from nvmet_execute_auth_send,
> right?
Good point. In theory nvmet_execute_auth_send() can free it, I don't
see that actually happening as `req->sq->dhchap_step` is always
`NVME_AUTH_DHCHAP_MESSAGE_NEGOTIATE` for me.
I'll add another patch to remove the call to nvmet_auth_sq_free() on success.
Alistair
>
More information about the Linux-nvme
mailing list