On Tue, 2009-01-06 at 18:35 -0500, Trond Myklebust wrote: > 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... OK. If people really want to track this, then you could add a reference to the current->nsproxy to the struct rpc_cred and struct auth_cred, and ensure that the unx_marshal and unx_match routines do the right thing w.r.t. that reference (if it exists). However such a patch had better be accompanied with a _really_ convincing argument for why containers need this... As for the NFSv4 clientid, I can't see how you would ever want to use anything other than the init->utsname(), since the requirement is only that the clientid string be unique and preserved across reboots. The server isn't allowed to interpret the contents of the clientid string. Ditto for the RPCSEC_GSS machine creds that are used to establish the clientid. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
