Most recent kernel where this bug did not occur: 2.6.17.11 Distribution: Gentoo Hardware Environment: ASUS L3C/S laptop Software Environment: Problem Description: The kernel has compiled in some bultin tests and so that's how I found the message in dmesg output Steps to reproduce:
Created attachment 9186 [details] dmesg
Created attachment 10234 [details] dmesg-2.6.19.2 Still present.
still there with 2.6.21-rc5, full dmesg & details here: http://nerdbynature.de/bits/2.6.21-rc5/ [93422.248250] [93422.248254] ============================================= [93422.248268] [ INFO: possible recursive locking detected ] [93422.248273] 2.6.21-rc5 #2 [93422.248276] --------------------------------------------- [93422.248280] rm/32198 is trying to acquire lock: [93422.248284] (&(&ip->i_lock)->mr_lock){----}, at: [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248299] [93422.248300] but task is already holding lock: [93422.248304] (&(&ip->i_lock)->mr_lock){----}, at: [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248314] [93422.248314] other info that might help us debug this: [93422.248320] 3 locks held by rm/32198: [93422.248323] #0: (&inode->i_mutex/1){--..}, at: [<c0167026>] do_unlinkat+0x96/0x160 [93422.248334] #1: (&inode->i_mutex){--..}, at: [<c0165305>] vfs_unlink+0x75/0xe0 [93422.248346] #2: (&(&ip->i_lock)->mr_lock){----}, at: [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248356] [93422.248357] stack backtrace: [93422.248362] [<c0134b19>] __lock_acquire+0xa99/0x1010 [93422.248373] [<c01350e7>] lock_acquire+0x57/0x70 [93422.248379] [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248385] [<c012e478>] down_write+0x38/0x50 [93422.248393] [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248399] [<c0246a31>] xfs_ilock+0x71/0xa0 [93422.248405] [<c026bdb6>] xfs_lock_dir_and_entry+0xf6/0x100 [93422.248413] [<c026c437>] xfs_remove+0x197/0x4e0 [93422.248419] [<c016db79>] d_instantiate+0x19/0x40 [93422.248426] [<c016d9e0>] d_rehash+0x20/0x50 [93422.248434] [<c0165305>] vfs_unlink+0x75/0xe0 [93422.248442] [<c0273e93>] xfs_vn_unlink+0x23/0x60 [93422.248449] [<c03ccbaf>] __mutex_lock_slowpath+0x13f/0x280 [93422.248459] [<c01339bb>] mark_held_locks+0x6b/0x90 [93422.248464] [<c03ccbaf>] __mutex_lock_slowpath+0x13f/0x280 [93422.248471] [<c03ccbaf>] __mutex_lock_slowpath+0x13f/0x280 [93422.248478] [<c0133b49>] trace_hardirqs_on+0xb9/0x160 [93422.248484] [<c0165305>] vfs_unlink+0x75/0xe0 [93422.248491] [<c03ccba2>] __mutex_lock_slowpath+0x132/0x280 [93422.248498] [<c0165305>] vfs_unlink+0x75/0xe0 [93422.248504] [<c01648e1>] permission+0x91/0xf0 [93422.248512] [<c0165319>] vfs_unlink+0x89/0xe0 [93422.248518] [<c0167062>] do_unlinkat+0xd2/0x160 [93422.248526] [<c0102894>] sysenter_past_esp+0x8d/0x99 [93422.248533] [<c0133b49>] trace_hardirqs_on+0xb9/0x160 [93422.248541] [<c0102864>] sysenter_past_esp+0x5d/0x99 [93422.248550] =======================
Last seen in 2.6.23-rc6 (09/2007), but I've not seen this in 2.6.23-rc7, 2.6.23-rc9, 2.6.23.1 and 2.6.24-rc2. So, I guess the lock annotations for XFS made it into the kernel? If so, I'd like to see this bug closed. Thanks to all involved, Christian. # zgrep -E 'DEBUG|LOCK' /proc/config.gz | grep -v ^\# [...] CONFIG_LOCKDEP_SUPPORT=y CONFIG_DETECT_SOFTLOCKUP=y CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y CONFIG_LOCKDEP=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_LIST=y CONFIG_DEBUG_STACKOVERFLOW=y
Too bad, I have stopped using XFS on my laptop, so I cannot comment on this anymore, sorry.
Fixed with this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0f1145cc18e970ebe37da114fc34c297f135e062 (reassigning so I can close the bug)