summaryrefslogtreecommitdiff
path: root/fs/efs
diff options
context:
space:
mode:
authorStanislav Kinsbursky <skinsbursky@parallels.com>2012-01-10 16:13:19 +0400
committerTrond Myklebust <Trond.Myklebust@netapp.com>2012-02-01 03:20:27 +0400
commiteee17325f1dfbe004f1475743bab9e3d050d00f5 (patch)
treeca48905e04e88658cff7d1a745a12ac3c04cfd77 /fs/efs
parent4929d1d33fdbe8385cdd49ccd23563e9ff247ff8 (diff)
downloadlinux-eee17325f1dfbe004f1475743bab9e3d050d00f5.tar.xz
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>
Diffstat (limited to 'fs/efs')
0 files changed, 0 insertions, 0 deletions