Most recent kernel where this bug did *NOT* occur: - Distribution: gentoo Hardware Environment: Pentium III 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) 00:04.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10) 00:04.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:05.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 07) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1) Software Environment: Linux queen 2.6.20 #2 PREEMPT Mon Mar 5 01:06:30 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux ltp 20070228, ext3 partition Problem Description: [ 3985.659543] ============================================= [ 3985.659686] [ INFO: possible recursive locking detected ] [ 3985.659744] 2.6.20 #2 [ 3985.659797] --------------------------------------------- [ 3985.659922] 4-1.test/14354 is trying to acquire lock: [ 3985.659980] (&inode->i_mutex){--..}, at: [<c05db79c>] mutex_lock+0x1c/0x20 [ 3985.660182] [ 3985.660184] but task is already holding lock: [ 3985.660340] (&inode->i_mutex){--..}, at: [<c05db79c>] mutex_lock+0x1c/0x20 [ 3985.660525] [ 3985.660527] other info that might help us debug this: [ 3985.660630] 1 lock held by 4-1.test/14354: [ 3985.660743] #0: (&inode->i_mutex){--..}, at: [<c05db79c>] mutex_lock+0x1c/0x20 [ 3985.660969] [ 3985.660971] stack backtrace: [ 3985.661128] [<c01038ea>] show_trace_log_lvl+0x1a/0x30 [ 3985.661217] [<c0104092>] show_trace+0x12/0x20 [ 3985.661353] [<c0104186>] dump_stack+0x16/0x20 [ 3985.661432] [<c013369f>] __lock_acquire+0xb1f/0xe00 [ 3985.661584] [<c01339f0>] lock_acquire+0x70/0x90 [ 3985.661664] [<c05db51b>] __mutex_lock_slowpath+0x6b/0x2d0 [ 3985.661803] [<c05db79c>] mutex_lock+0x1c/0x20 [ 3985.661881] [<c01680c8>] vfs_unlink+0x58/0xb0 [ 3985.662031] [<c03afe58>] sys_mq_unlink+0x78/0xe0 [ 3985.662122] [<c0103200>] syscall_call+0x7/0xb [ 3985.662257] ======================= Steps to reproduce: running ltp 20070228
I was able to reproduce this with 2.6.21-rc2-git4 but not 2.6.21-rc3, so it seems fixed
I don't think there has been any patch to fix (or any VFS patch at all) this problem between -rc2-git4 and -rc3. Maybe it's very hard to reproduce. Could you try to reproduce it a bit harder?
Already ran ltp twice, but i'll let it run some more times to see what pops up
Created attachment 10643 [details] testcase Hmm, i searched the testcase from the ltp. It is part of the open posix testsuite, you can find it under ./testcases/open_posix_testsuite/conformance/interfaces/mq_getattr/4-1.c I can reproduce this with 2.6.20 and 2.6.20-rc2-git4 on the first run, not on 2.6.21-rc3, so it looks solved