Re: [PATCH] NFSD: Avoid race of locking parent's mutex at cross mount

[Kinglong Mee <kinglongmee@gmail.com>]

Cc Neil Brown,

On 4/29/2015 5:36 AM, J. Bruce Fields wrote:
> On Wed, Apr 29, 2015 at 12:10:15AM +0800, Kinglong Mee wrote:
>> When testing pseudo root, there is a mutex race between
>> nfsd and rpc.mountd for locking parent inode.
> 
> Thanks for investigating this!

My tests,
# cat /etc/exports
/nfs/xfs        *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
/nfs/pnfs       *(rw,insecure,no_subtree_check,no_root_squash,crossmnt)
# df | grep nfs
/dev/sde                          999320    1284   929224    1% /nfs/test
/dev/sdc                        10475520   32948 10442572    1% /nfs/xfs
/dev/sdd                         1038336   34160  1004176    4% /nfs/pnfs
# ls /nfs/
aclocal.m4     config.sub     cscope.po.out  ltmain.sh    pnfs
autogen.sh     configure      depcomp        Makefile     README
compile        configure.ac   hello          Makefile.am  tags
config.guess   COPYING        INSTALL        Makefile.in  test
config.log     cscope.in.out  install-sh     missing      test-driver
config.status  cscope.out     libtool        NEWS         xfs

# mount -t nfs 127.0.0.1:/nfs /mnt
# ll /mnt/*/
 ------------ hang here ------

> 
>> nfs-utils commit 6091c0a4c4 
>> ("mountd: add support for case-insensitive file names")
>> adds using name_to_handle_at which will locking parent.
>>
> 
> My first impulse is to blame nfs-utils, if it was really that commit
> that introduced the problem....
> 
> But waiting on mountd while holding this i_mutex does seem a little
> scary.  All it takes is an uncached lookup on the same directory, and a
> stat could do that, right?

Stat operation will go though the lookup_slow the first time.

Apr 29 18:16:16 ntest kernel: rpc.mountd      D ffff8800454dfb98     0  3874   1004 0x00000000
Apr 29 18:16:16 ntest kernel: ffff8800454dfb98 ffff880069a512e0 ffff880056888000 ffff8800454dfb78
Apr 29 18:16:16 ntest kernel: ffff8800454e0000 ffff880035ee2874 ffff880056888000 00000000ffffffff
Apr 29 18:16:16 ntest kernel: ffff880035ee2878 ffff8800454dfbb8 ffffffff8177fda7 0000000000000000
Apr 29 18:16:16 ntest kernel: Call Trace:
Apr 29 18:16:16 ntest kernel: [<ffffffff8177fda7>] schedule+0x37/0x90
Apr 29 18:16:16 ntest kernel: [<ffffffff817800ee>] schedule_preempt_disabled+0xe/0x10
Apr 29 18:16:16 ntest kernel: [<ffffffff81781c62>] __mutex_lock_slowpath+0xb2/0x120
Apr 29 18:16:16 ntest kernel: [<ffffffff81781cf3>] mutex_lock+0x23/0x40
Apr 29 18:16:16 ntest kernel: [<ffffffff81230714>] lookup_slow+0x34/0xc0
Apr 29 18:16:16 ntest kernel: [<ffffffff812358ee>] path_lookupat+0x89e/0xc60
Apr 29 18:16:16 ntest kernel: [<ffffffff81205192>] ? kmem_cache_alloc+0x1e2/0x260
Apr 29 18:16:16 ntest kernel: [<ffffffff812367a6>] ? getname_flags+0x56/0x200
Apr 29 18:16:16 ntest kernel: [<ffffffff81235cd7>] filename_lookup+0x27/0xc0
Apr 29 18:16:16 ntest kernel: [<ffffffff81237b53>] user_path_at_empty+0x63/0xd0
Apr 29 18:16:16 ntest kernel: [<ffffffff8121d310>] ? memory_failure_work_func+0xc0/0xc0
Apr 29 18:16:16 ntest kernel: [<ffffffff81237bd1>] user_path_at+0x11/0x20
Apr 29 18:16:16 ntest kernel: [<ffffffff8122a47a>] vfs_fstatat+0x6a/0xd0
Apr 29 18:16:16 ntest kernel: [<ffffffff8122aa61>] SYSC_newlstat+0x31/0x60
Apr 29 18:16:16 ntest kernel: [<ffffffff8122f1b2>] ? path_put+0x22/0x30
Apr 29 18:16:16 ntest kernel: [<ffffffff812865a1>] ? SyS_name_to_handle_at+0x171/0x200
Apr 29 18:16:16 ntest kernel: [<ffffffff8122ab9e>] SyS_newlstat+0xe/0x10
Apr 29 18:16:16 ntest kernel: [<ffffffff81783d2e>] system_call_fastpath+0x12/0x71

Before the upcall to rpc.mountd, nfsd have call lookup_one_len() for the file,
but I don't known why rpc.mountd will go though lookup_slow again?

thanks,
Kinglong Mee