linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	Pavel Emelianov <xemul@parallels.com>,
	"neilb@suse.de" <neilb@suse.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	James Bottomley <jbottomley@parallels.com>,
	"bfields@fieldses.org" <bfields@fieldses.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"devel@openvz.org" <devel@openvz.org>
Subject: Re: [PATCH 6/6] NFS: idmap PipeFS notifier introduced
Date: Tue, 10 Jan 2012 14:27:17 +0400	[thread overview]
Message-ID: <4F0C1285.10002@parallels.com> (raw)
In-Reply-To: <1325285643.10984.3.camel@lade.trondhjem.org>

31.12.2011 02:54, Trond Myklebust пишет:
> 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.
>

Sorry.
Will resend soon.

> Cheers
>    Trond
>


-- 
Best regards,
Stanislav Kinsbursky

      reply	other threads:[~2012-01-10 10:28 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
2012-01-10 10:27     ` Stanislav Kinsbursky [this message]

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=4F0C1285.10002@parallels.com \
    --to=skinsbursky@parallels.com \
    --cc=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=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).