netdev - Re: [PATCH 6/6] NFS: idmap PipeFS notifier introduced

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 10 Jan 2012 14:27:17 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
CC:	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	Pavel Emelianov <xemul@...allels.com>,
	"neilb@...e.de" <neilb@...e.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	James Bottomley <jbottomley@...allels.com>,
	"bfields@...ldses.org" <bfields@...ldses.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"devel@...nvz.org" <devel@...nvz.org>
Subject: Re: [PATCH 6/6] NFS: idmap PipeFS notifier introduced

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@...allels.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html