linux-kernel - Re: [GIT PULL] Please pull NFS client bugfixes....

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]

Date:	Fri, 08 Jan 2010 06:19:07 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Trond Myklebust <Trond.Myklebust@...app.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Please pull NFS client bugfixes....

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> I've not actually seen the lockdep chain, so I don't know 
> the deails. Pointers?


=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.33-rc1-git3-MCE6 #12
-------------------------------------------------------
udevinfo/2562 is trying to acquire lock:
 (&sb->s_type->i_mutex_key#5){+.+.+.}, at: [<ffffffff81185188>] nfs_revalidate_mapping+0x7c/0xc5

but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [<ffffffff810ae75b>] sys_mmap_pgoff+0xd3/0x1a0

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_sem){++++++}:
       [<ffffffff81068c48>] __lock_acquire+0x1432/0x1771
       [<ffffffff81069043>] lock_acquire+0xbc/0xd9
       [<ffffffff810b1a90>] might_fault+0x84/0xa4
       [<ffffffff810e3c78>] filldir+0x6a/0xcb
       [<ffffffff81180d58>] nfs_do_filldir+0x39d/0x4ac
       [<ffffffff8118167c>] nfs_readdir+0x815/0x8b6
       [<ffffffff810e3df7>] vfs_readdir+0x6c/0xa1
       [<ffffffff810e3f6a>] sys_getdents+0x7d/0xc9
       [<ffffffff810029eb>] system_call_fastpath+0x16/0x1b

-> #0 (&sb->s_type->i_mutex_key#5){+.+.+.}:
       [<ffffffff8106896d>] __lock_acquire+0x1157/0x1771
       [<ffffffff81069043>] lock_acquire+0xbc/0xd9
       [<ffffffff8149472c>] mutex_lock_nested+0x68/0x2d2
       [<ffffffff81185188>] nfs_revalidate_mapping+0x7c/0xc5
       [<ffffffff81182c0a>] nfs_file_mmap+0x68/0x71
       [<ffffffff810b99bf>] mmap_region+0x311/0x530
       [<ffffffff810b9e6e>] do_mmap_pgoff+0x290/0x2f3
       [<ffffffff810ae77c>] sys_mmap_pgoff+0xf4/0x1a0
       [<ffffffff81006ba2>] sys_mmap+0x1d/0x1f
       [<ffffffff810029eb>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

1 lock held by udevinfo/2562:
 #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff810ae75b>] sys_mmap_pgoff+0xd3/0x1a0

stack backtrace:
Pid: 2562, comm: udevinfo Not tainted 2.6.33-rc1-git3-MCE6 #12
Call Trace:
 [<ffffffff810672c8>] print_circular_bug+0xb3/0xc2
 [<ffffffff8106896d>] __lock_acquire+0x1157/0x1771
 [<ffffffff8105b031>] ? sched_clock_local+0x1c/0x80
 [<ffffffff81069043>] lock_acquire+0xbc/0xd9
 [<ffffffff81185188>] ? nfs_revalidate_mapping+0x7c/0xc5
 [<ffffffff8149472c>] mutex_lock_nested+0x68/0x2d2
 [<ffffffff81185188>] ? nfs_revalidate_mapping+0x7c/0xc5
 [<ffffffff8105b15e>] ? sched_clock_cpu+0xc9/0xce
 [<ffffffff81185188>] ? nfs_revalidate_mapping+0x7c/0xc5
 [<ffffffff810b991c>] ? mmap_region+0x26e/0x530
 [<ffffffff81185188>] nfs_revalidate_mapping+0x7c/0xc5
 [<ffffffff81182c0a>] nfs_file_mmap+0x68/0x71
 [<ffffffff810b99bf>] mmap_region+0x311/0x530
 [<ffffffff810b9e6e>] do_mmap_pgoff+0x290/0x2f3
 [<ffffffff810ae77c>] sys_mmap_pgoff+0xf4/0x1a0
 [<ffffffff81495c86>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff81006ba2>] sys_mmap+0x1d/0x1f
 [<ffffffff810029eb>] 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/