linux-kernel - [2.6.20-rc3] INFO: possible recursive locking detected (was: Happy New Year (and v2.6.20-rc3 released))

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: <200701031906.l03J6Csc005559@lx1.pxnet.com>
Date:	Wed, 3 Jan 2007 20:06:12 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [2.6.20-rc3] INFO: possible recursive locking detected (was: Happy New Year (and v2.6.20-rc3 released))

On Sun, 31 Dec 2006 17:19:44 -0800 (PST), Linus Torvalds wrote:
> In order to not get in trouble with MADR ("Mothers Against Drunk 
> Releases") I decided to cut the 2.6.20-rc3 release early rather than wait 
[...]
> At which point the first thing on any self-respecting geek's mind should 
> obviously be: "is there a new kernel release for me to try?"

2.6.20-rc3 produces the following lockdep warning when hald is
started during system startup:

=============================================
[ INFO: possible recursive locking detected ]
2.6.20-rc3-noinitrd #0
---------------------------------------------
hald-subfs-moun/4608 is trying to acquire lock:
 (&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f

but task is already holding lock:
 (&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f

other info that might help us debug this:
3 locks held by hald-subfs-moun/4608:
 #0:  (&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f
 #1:  (&REISERFS_I(inode)->xattr_sem){----}, at: [<c01c0098>] reiserfs_setxattr+0x51/0xe9
 #2:  (&REISERFS_SB(s)->xattr_dir_sem){----}, at: [<c01c00be>] reiserfs_setxattr+0x77/0xe9

stack backtrace:
 [<c0103c72>] show_trace_log_lvl+0x19/0x2e
 [<c0103d6b>] show_trace+0x12/0x14
 [<c0103d81>] dump_stack+0x14/0x16
 [<c01303b3>] __lock_acquire+0x116/0xa5c
 [<c0130fe6>] lock_acquire+0x56/0x70
 [<c035b95c>] __mutex_lock_slowpath+0xdc/0x266
 [<c035bb02>] mutex_lock+0x1c/0x1f
 [<c01c07d0>] reiserfs_xattr_set+0xe4/0x2c0
 [<c01c0c21>] trusted_set+0x74/0x80
 [<c01c00e9>] reiserfs_setxattr+0xa2/0xe9
 [<c0177b45>] vfs_setxattr+0xa6/0x1ff
 [<c0177d57>] setxattr+0xb9/0xd1
 [<c0177e14>] sys_lsetxattr+0x3e/0x50
 [<c0102d9a>] sysenter_past_esp+0x5f/0x99
 =======================

I guess it's really the same ReiserFS issue I already reported for
the previous releases, just triggered at an earlier point in the
system's life.

Other than that, everything seems fine and dandy on this plain old P3.

HTH, and Happy New Year everyone
Tilman

-
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/