diff options
author | Stanislav Kinsbursky <skinsbursky@parallels.com> | 2012-01-10 16:13:19 +0400 |
---|---|---|
committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2012-02-01 03:20:27 +0400 |
commit | eee17325f1dfbe004f1475743bab9e3d050d00f5 (patch) | |
tree | ca48905e04e88658cff7d1a745a12ac3c04cfd77 /fs/nfs/callback.c | |
parent | 4929d1d33fdbe8385cdd49ccd23563e9ff247ff8 (diff) | |
download | linux-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/nfs/callback.c')
0 files changed, 0 insertions, 0 deletions