linux-kernel - Re: NFS lockdep lock misordering mmap_sem<->i_mutex

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20091207211216.E95E.A69D9226@jp.fujitsu.com>
Date:	Mon,  7 Dec 2009 21:19:28 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
	Trond.Myklebust@...app.com
Subject: Re: NFS lockdep lock misordering mmap_sem<->i_mutex_key with 2.6.32-git1

> 
> While booting 2.6.32-git1 on a NFS root box I got the following
> lockdep warning early at boot. I haven't looked at details.

It seems typical ABBA deadlock.

 vfs_readdir				[grab i_mutex]
   nfs_readdir
     nfs_do_filldir
       filldir
         copy_to_user
           [page_fault]			[grab mmap_sem]

 sys_mmap				[grab mmap_sem]
   do_mmap_pgoff
     mmap_region
       nfs_file_mmap
         nfs_revalidate_mapping  
           nfs_invalidate_mapping	[grab i_mutex]

I guess recent lockdep improvement find old bug.



> 
> -Andi
> 
> VFS: Mounted root (nfs filesystem) on device 0:15.
> VFS: Mounted root (nfs filesystem) on device 0:15.
> Freeing unused kernel memory: 2376k freed
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> udevinfo/2551 is trying to acquire lock:
>  (&sb->s_type->i_mutex_key#5){+.+.+.}, at: [<ffffffff8118e0d3>] nfs_revalidate_mapping+0x7c/0xc5
> 
> but task is already holding lock:
>  (&mm->mmap_sem){++++++}, at: [<ffffffff8100fc83>] sys_mmap+0x76/0xc7
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&mm->mmap_sem){++++++}:
>        [<ffffffff81071d0b>] __lock_acquire+0x1435/0x1774
>        [<ffffffff81072106>] lock_acquire+0xbc/0xd9
>        [<ffffffff810baa14>] might_fault+0x84/0xa4
>        [<ffffffff810ec340>] filldir+0x6a/0xcb
>        [<ffffffff81189bad>] nfs_do_filldir+0x39d/0x4ac
>        [<ffffffff8118a4e9>] nfs_readdir+0x82d/0x8ce
>        [<ffffffff810ec4bf>] vfs_readdir+0x6c/0xa1
>        [<ffffffff810ec632>] sys_getdents+0x7d/0xc9
>        [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
> 
> -> #0 (&sb->s_type->i_mutex_key#5){+.+.+.}:
>        [<ffffffff81071a30>] __lock_acquire+0x115a/0x1774
>        [<ffffffff81072106>] lock_acquire+0xbc/0xd9
>        [<ffffffff8149210d>] mutex_lock_nested+0x68/0x2d2
>        [<ffffffff8118e0d3>] nfs_revalidate_mapping+0x7c/0xc5
>        [<ffffffff8118bad9>] nfs_file_mmap+0x68/0x71
>        [<ffffffff810c29c0>] mmap_region+0x311/0x50f
>        [<ffffffff810c2f13>] do_mmap_pgoff+0x355/0x3b8
>        [<ffffffff8100fca1>] sys_mmap+0x94/0xc7
>        [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
> 
> other info that might help us debug this:
> 
> 1 lock held by udevinfo/2551:
>  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8100fc83>] sys_mmap+0x76/0xc7
> 
> stack backtrace:
> Pid: 2551, comm: udevinfo Not tainted 2.6.32-git1 #31
> Call Trace:
>  [<ffffffff81070388>] print_circular_bug+0xb3/0xc2
>  [<ffffffff81071a30>] __lock_acquire+0x115a/0x1774
>  [<ffffffff810a401d>] ? find_get_pages_tag+0x0/0x12a
>  [<ffffffff81072106>] lock_acquire+0xbc/0xd9
>  [<ffffffff8118e0d3>] ? nfs_revalidate_mapping+0x7c/0xc5
>  [<ffffffff8149210d>] mutex_lock_nested+0x68/0x2d2
>  [<ffffffff8118e0d3>] ? nfs_revalidate_mapping+0x7c/0xc5
>  [<ffffffff8118e0d3>] ? nfs_revalidate_mapping+0x7c/0xc5
>  [<ffffffff810c291d>] ? mmap_region+0x26e/0x50f
>  [<ffffffff8118e0d3>] nfs_revalidate_mapping+0x7c/0xc5
>  [<ffffffff8118bad9>] nfs_file_mmap+0x68/0x71
>  [<ffffffff810c29c0>] mmap_region+0x311/0x50f
>  [<ffffffff810c2f13>] do_mmap_pgoff+0x355/0x3b8
>  [<ffffffff8100fca1>] sys_mmap+0x94/0xc7
>  [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
> 
> -Andi
> -- 
> ak@...ux.intel.com -- Speaking for myself only.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/