From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Caching semi-digested credentials in struct cred Date: Wed, 24 Oct 2007 13:52:36 -0400 Message-ID: <1193248356.7515.7.camel@heimdal.trondhjem.org> References: <1193237038.7508.4.camel@heimdal.trondhjem.org> <1192634425.7573.5.camel@heimdal.trondhjem.org> <7004.1192630004@redhat.com> <1248.1193234419@redhat.com> <2219.1193245809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: viro@ftp.linux.org.uk, hch@infradead.org, kwc@citi.umich.edu, jlayton@redhat.com, nickpiggin@yahoo.com.au, linux-fsdevel@vger.kernel.org To: David Howells Return-path: Received: from mx2.netapp.com ([216.240.18.37]:6747 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752997AbXJXRwy (ORCPT ); Wed, 24 Oct 2007 13:52:54 -0400 In-Reply-To: <2219.1193245809@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2007-10-24 at 18:10 +0100, David Howells wrote: > Trond Myklebust 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