Re: Caching semi-digested credentials in struct cred

[David Howells <dhowells@redhat.com>]

Trond Myklebust <Trond.Myklebust@netapp.com> wrote:

> What is a 'struct key'? Is that a credential?

It can represent one yes.

> NO! Keyrings are meant for communicating with userspace. They should not
> be used as a 'generic cache' in the kernel.

Erm, I'm pretty sure that keys are primarily for caching credentials that the
kernel needs to use a lot, so that it doesn't have to keep asking userspace for
them.  Keyrings are a defined method of retaining and searching for keys.

It happens that userspace can also make use of the cached keys, given
appropriate rights.

However, I don't particularly like the idea of a cache as I can see it raising
various problems.

> Why are you trying to replace the rpc_cred?

So that NFS doesn't have to pass both rpc_cred and cred pointers around.  I
can't just give struct cred an rpc_cred pointer as it may the former may hold
information on several of the latter (for different NFS domains).

I'm not objecting to the existence of rpc_cred per se, but if it's retained by
struct cred, then it needs to be in some generic mechanism, and rpc_cred's
fields can be mapped more or less onto a key struct.

> Use the credential struct as the unique lookup key for an rpc_cred.

That's not good enough.  A cred struct may map to several rpc_creds as I
mentioned above.  I suppose the nfs_client struct address could be added to the
lookup key.

Furthermore, a cred struct may end up referring to different rpc_creds for the
same domain if a key in the keyrings changes - unless I add something to make a
COW mirror of the keyring contents from the keyrings.

> If looking up rpc creds is a performance issue, then that needs to be
> addressed separately. It should have nothing to do with the design of a
> generic credential.

If there's a cred -> rpc_cred mapping, then it might make sense to root the
mapping in the cred struct and to make it generic.  NFS is just one of the
kernel services that might want to use this.

David