On Tue, 2009-01-06 at 18:35 -0500, Trond Myklebust wrote: > On Tue, 2009-01-06 at 18:32 -0500, J. Bruce Fields wrote: > > On Tue, Jan 06, 2009 at 06:15:34PM -0500, Trond Myklebust wrote: > > > On Tue, 2009-01-06 at 15:04 -0800, Eric W. Biederman wrote: > > > > That implies to me you want to capture the value at mount time, and to > > > > pass it in to the rpc_call creation, and only at very specific well > > > > defined points where we interact with user space should we examine > > > > current->utsname(). At which point there should be no question > > > > of current->utsname() is valid as the user space process is alive. > > > > > > Why pretend that the filesystem is owned by a particular namespace? It > > > can, and will be shared among many containers... > > > > If the only purpose of this is to fill in the auth_unix cred then > > shouldn't it be part of whatever cred structures are passed around? > > So how does tracking it in a shared structure like the rpc_client help? > If you consider it to be part of the cred, then it needs to be tracked > in the cred... > > Trond I originally discarded the idea of relating it to the credentials because it looked like the credential cache could be flushed at any time (according to the small portion of the RFC I read) so I was worried we'd have even worse lifetime issues to deal with. Cheers, -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
