On Wed, Jun 04, 2025 at 07:42:52PM +0300, Jarkko Sakkinen wrote:
> OK, I put this in simple terms, so perhaps I learn something from
> nvme and nfs code:
>
> 1. The code change itself, if this keyring is needed, it looks
> reasonable.
> 2. However, I don't see any callers within the scope of patch set
> for this keyring.
>
> I could quite quickly grab the idea how NVME uses nvme_keyring in TLS
> handshake code from drivers/nvme/target/{configfs.c,tcp.c}. I guess
> similar idea will be used in nfs code but I don't see any use for it
> in the patch set.
>
> Thus, it is hard to grasp the idea of having this patch applied without
> any supplemental patch set.
Maybe I'm missing something. The reason I added the keyring was that
without it, tlshd is not the possesor of the keys and can't read them.
I guess you refer to the fact that nvme_tls_psk_lookup does a
keyring_search and nothing in the NFS code does? nvme_tls_psk_lookup is
only used for the default key based on the server side identification in
NVMe, a concept that doesn't exist in NFS. But the fact that the keys
aren't otherwise readable exists for both nvme and NFS.
