On Wed, 2007-10-24 at 19:41 +0100, David Howells wrote: > > 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. Huh? The RPC cred lookup function takes a pointer to an rpc_auth struct, which should already be tied to an rpc_client. Passing an nfs_client is completely unnecessary aside from being a massive layering violation. > 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. In the case where keyrings are enabled and a key changes, then we should revalidate the rpc_cred and either dump it (replacing it with a new cred) or reuse it. We can only cache so much garbage... > > 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. Possibly, but I'm not accepting any single patch that completely rewrites the basic security model of NFS in one fell swoop. If you want to change the cred->rpc_cred mapping, then that will be done in incremental patches. Your first step is therefore to get the generic cred working with the _existing_ RPC security model. Trond - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
