From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: linux-nfs@vger.kernel.org, xemul@parallels.com, neilb@suse.de,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
jbottomley@parallels.com, bfields@fieldses.org,
davem@davemloft.net, devel@openvz.org
Subject: Re: [PATCH 6/6] NFS: idmap PipeFS notifier introduced
Date: Fri, 30 Dec 2011 17:54:03 -0500 [thread overview]
Message-ID: <1325285643.10984.3.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20111128133410.4251.656.stgit@localhost6.localdomain6>
On Mon, 2011-11-28 at 17:34 +0300, Stanislav Kinsbursky wrote:
> 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>
This patch gives me:
Kernel: arch/x86/boot/bzImage is ready (#3)
Building modules, stage 2.
MODPOST 921 modules
ERROR: "nfs_idmap_init" [fs/nfs/nfs.ko] undefined!
ERROR: "nfs_idmap_quit" [fs/nfs/nfs.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
if CONFIG_NFS_V4 is not defined.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2011-12-30 22:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 14:33 [PATCH 0/6] NFS: create clients and IDMAP pipes per network namespace Stanislav Kinsbursky
2011-11-28 14:33 ` [PATCH 1/6] SUNRPC: fix pipe->ops cleanup on pipe dentry unlink Stanislav Kinsbursky
2011-11-28 14:33 ` [PATCH 2/6] NFS: make NFS client allocated per network namespace context Stanislav Kinsbursky
2011-11-28 14:33 ` [PATCH 3/6] NFS: pass NFS client owner network namespace to RPC client creation routine Stanislav Kinsbursky
2011-11-28 14:33 ` [PATCH 4/6] NFS: create callback transports in parent transport network namespace Stanislav Kinsbursky
2011-11-28 14:34 ` [PATCH 5/6] NFS: handle NFS idmap pipe PipeFS dentries by network namespace aware routines Stanislav Kinsbursky
2011-11-28 14:34 ` [PATCH 6/6] NFS: idmap PipeFS notifier introduced Stanislav Kinsbursky
2011-12-30 22:54 ` Trond Myklebust [this message]
2012-01-10 10:27 ` Stanislav Kinsbursky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1325285643.10984.3.camel@lade.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=skinsbursky@parallels.com \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).