On Wed, 2007-10-24 at 18:10 +0100, David Howells wrote: > Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> 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 - 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
