On Wed, Nov 23, 2011 at 02:51:10PM +0300, Stanislav Kinsbursky wrote: > This patch set was created in context of clone of git > branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git. > tag: v3.1 > > This patch set depends on previous patch sets titled: > 1) "SUNRPC: initial part of making pipefs work in net ns" > 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users" > > This patch set is a first part of reworking SUNPRC PipeFS users. > It makes SUNRPC clients using PipeFS nofitications for directory and GSS pipes > dentries creation. With this patch set RPC clients and GSS auth creations > routines doesn't force SUNRPC PipeFS mount point creation which actually means, > that they now can work without PipeFS dentries. I'm not following very well. (My fault, I haven't been paying attention.) Could you summarize the itended behavior of pipefs after all this is done? So there's a separate superblock (and separate dentries) for each namespace? What decides which clients are visible in which network namespaces? --b. > > The following series consists of: > > --- > > Stanislav Kinsbursky (6): > SUNRPC: handle RPC client pipefs dentries by network namespace aware routines > SUNRPC: handle GSS AUTH pipes by network namespace aware routines > SUNRPC: subscribe RPC clients to pipefs notifications > SUNRPC: remove RPC client pipefs dentries after unregister > SUNRPC: remove RPC pipefs mount point manipulations from RPC clients code > SUNRPC: remove RPC PipeFS mount point reference from RPC client > > > fs/nfs/idmap.c | 4 + > fs/nfsd/nfs4callback.c | 2 - > include/linux/nfs.h | 2 - > include/linux/sunrpc/auth.h | 2 + > include/linux/sunrpc/clnt.h | 2 - > net/sunrpc/auth_gss/auth_gss.c | 101 +++++++++++++++++++++------ > net/sunrpc/clnt.c | 151 +++++++++++++++++++++++++++++++--------- > net/sunrpc/rpc_pipe.c | 19 +++-- > net/sunrpc/sunrpc.h | 2 + > 9 files changed, 218 insertions(+), 67 deletions(-) > > -- > Signature -- 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