[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c7679208-c963-4fdd-a038-a91ccda0a075@suse.de>
Date: Wed, 12 Nov 2025 08:21:41 +0100
From: Hannes Reinecke <hare@...e.de>
To: Christoph Hellwig <hch@....de>, Alistair Francis <alistair23@...il.com>
Cc: kbusch@...nel.org, axboe@...nel.dk, sagi@...mberg.me, kch@...dia.com,
linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH 3/3] nvme: Allow reauth from sysfs
On 11/12/25 08:02, Christoph Hellwig wrote:
> On Wed, Nov 12, 2025 at 09:32:00AM +1000, Alistair Francis wrote:
>>> I would suggest just allow writes to the 'tls_key' attribute; any
>>> writes to that would trigger a replacepsk operation.
>>
>> I think the `tls_configured_key` is actually the better attribute to
>> write to as that is the one that updates after a REPLACETLSPSK
>> operation, see v2 patches which I'm sending now.
>
> Just saw Hannes reply here and saw why you did the current version
> the way I did. Hannes, please don't recommend weird ABIs that
> make error checking and future extensibility impossible.
>
Hmm.
'tls_configured_key' prints out the value of
ctrl->opts->tls_key, ie the key passed in from the 'connect'
string. Normally this value will be empty,
as the 'connect' command will pick up the TLS key from
the keyring automatically.
'tls_key' prints out the value of
ctrl->tls_pskid, ie the value of the _negotiated_ key.
So why is 'tls_configured_key' key the better option?
Personally I think that 'tls_key' is more 'natural',
as we want to replace the negotiated key, not the
configured key ...
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@...e.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
Powered by blists - more mailing lists