Re: Caching semi-digested credentials in struct cred

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Wed, 2007-10-24 at 18:10 +0100, David Howells wrote:
> Trond Myklebust <Trond.Myklebust@netapp.com> wrote:
> 
> > I thought you were passing a generic cred as an argument? It should be
> > possible to convert that into an rpc_cred.
> 
> Indeed I am, but I think I haven't gotten my questions across.
> 
> Take the rpc_cred struct as an example.  It contains some stuff that is
> obtained by taking the credentials open was supplied and munging them into
> other things perhaps by contacting a remote auth server.  Now, assuming that I
> can replace rpc_cred by, say, a key struct with dangly bits, most of the

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

> fields can be replaced by the key struct fields (cr_hash, cr_lru, cr_rcu,
> cr_expire, cr_flags, cr_count) or cred struct fields (cr_uid possibly).  But
> that still leaves cr_auth and cr_ops, which can be dangled from a key if
> that's okay, but how tied are these to a particular open?  That I'm not sure of.
> 
> However:
> 
>  (1) If I then attach such a key to the cred struct, NFS would have to perform
>      a search every time it wants to use the cred.  This might not be so bad,
>      as the keyring search algorithm uses RCU to do all its locking, and I
>      would guess there won't be that many keys.
> 
>      I could attach a cache to the cred struct so that any key that got used
>      gets added to it.  The cache could be in the form of a keyring.

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

>  (2) If I require that the keyrings pointed to by a cred struct be searched
>      each time an NFS op takes place, then the credentials being used by an
>      open file can change as the membership of the keyrings changes - which
>      I'm fairly sure is the wrong thing to do.
> 
>      The problem is that the cred struct wants itself and all its dangly bits
>      to be purely COW, but keyrings don't work like that because their
>      contents need to be alterable.
> 
>      I could work around this by duplicating the cred struct for each open
>      call, and allowing a fs to attach its own keys or whatever directly to
>      it, but if we do that, we may as well use struct file.

Why are you trying to replace the rpc_cred?

> > In the long run, we should get rid of the rpc_cred in the NFS layer, and
> > replace it with the generic creds, but for the short term, converting
> > one into the other in the NFS code should be acceptable.
> 
> Agreed, but I'm trying work out a way of avoiding a couple of problems (namely
> having the creds on an open file changing and having to perform a search), if
> indeed they are deemed to be problems.

Use the credential struct as the unique lookup key for an rpc_cred.
Where is the problem? 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.

Trond