]> rtime.felk.cvut.cz Git - linux-imx.git/commit
NFS: idmap PipeFS notifier introduced
authorStanislav Kinsbursky <skinsbursky@parallels.com>
Tue, 10 Jan 2012 12:13:19 +0000 (16:13 +0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Tue, 31 Jan 2012 23:20:27 +0000 (18:20 -0500)
commiteee17325f1dfbe004f1475743bab9e3d050d00f5
treeca48905e04e88658cff7d1a745a12ac3c04cfd77
parent4929d1d33fdbe8385cdd49ccd23563e9ff247ff8
NFS: idmap PipeFS notifier introduced

v2:
1) Added "nfs_idmap_init" and "nfs_idmap_quit" definitions for kernels built
without CONFIG_NFS_V4 option set.

This patch subscribes NFS clients to RPC pipefs notifications. Idmap notifier
is registering on NFS module load. This notifier callback is responsible for
creation/destruction of PipeFS idmap pipe dentry for NFS4 clients.

Since ipdmap pipe is created in rpc client pipefs directory, we have make sure,
that this directory has been created already. IOW RPC client notifier callback
has been called already. To achive this, PipeFS notifier priorities has been
introduced (RPC clients notifier priority is greater than NFS idmap one).
But this approach gives another problem: unlink for RPC client directory will
be called before NFS idmap pipe unlink on UMOUNT event and will fail, because
directory is not empty.
The solution, introduced in this patch, is to try to remove client directory
once again after idmap pipe was unlinked. This looks like ugly hack, so
probably it should be replaced in some more elegant way.

Note that no locking required in notifier callback because PipeFS superblock
pointer is passed as an argument from it's creation or destruction routine and
thus we can be sure about it's validity.

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
fs/nfs/client.c
fs/nfs/idmap.c
fs/nfs/internal.h
include/linux/nfs_idmap.h
include/linux/sunrpc/rpc_pipe_fs.h
net/sunrpc/clnt.c
net/sunrpc/rpc_pipe.c