On Thu, Jun 05, 2025 at 06:28:02AM +0200, Christoph Hellwig wrote:
> 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.
Ah, ok this cleared it up, thanks! Just learning these subsystem,
appreciate the patience with this one :-)
BR, Jarkko
