On Wed, Feb 29, 2012 at 02:45:12PM -0500, Jeff Layton wrote: > On Wed, 29 Feb 2012 22:39:01 +0400 > Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote: > > > Hi, Jeff. > > I'll try to explain, how all this namespaces-aware SUNRPC PipeFS works. > > The main idea is, that today we have 2 types of independently created and > > destroyed but linked objects: > > 1) pipe data itself. This object is created whenever kernel requires (on mount, > > module install, whatever) > > 2) dentry/inode for this pipe. This object is created on PipeFS superblock creation. > > This means, any kernel user of SUNRPC pipes have to provide two mechanisms: > > 1) Safe call (in per-net operations, if the object is global your case) for > > PipeFS dentry/inode pair. This is done this in nfsd4_init_cld_pipe(). > > > > 2) Notifier callback for PipeFS mount/umount operations. Note: this callback is > > done from SUNRPC module (i.e. you have to get nfsd module); this callback is > > safe - i.e you can be sure, that superblock is valid. > > > > This is the part I'm having a hard time with. IIUC, the existing > examples are fairly clear since you have a 1:1 ratio of objects: a > per-net object (the pipe data) that is hooked up to a dentry/inode in a > per-net sb. > > Here though, we don't really have that. We have a global pipe object > and I don't see how you can hook that up to multiple dentries/inodes. > > One possibility is to completely "namespacify" this code -- don't use a > global rpc_pipe object and make it per-net instead. If I do that though, > then I suppose I'll also need to make all of the > nfsd4_client_tracking_ops take a struct net arg as well? That does sound like what we'll want eventually. And callers will use pass svc_rqst->rq_xprt->xpt_net there, I assume. (Or actually we may need a pointer to the netns from the nfs4 client?) --b. -- 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
