* 2.6.33-rc0: reiserfs: inconsistent lock state
@ 2009-12-11 22:06 Alexander Beregalov
2009-12-12 20:51 ` Alexander Beregalov
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Alexander Beregalov @ 2009-12-11 22:06 UTC (permalink / raw)
To: Linux Kernel Mailing List, Frederic Weisbecker
Hi Frederic
It is x86_32 UP
[ INFO: inconsistent lock state ]
2.6.32-05594-g3ef884b #2
---------------------------------
inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
kswapd0/312 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&REISERFS_SB(s)->lock){+.+.?.}, at: [<c11108a8>] reiserfs_write_lock+0x28/0x40
{RECLAIM_FS-ON-W} state was registered at:
[<c104e1c2>] mark_held_locks+0x62/0x90
[<c104e28a>] lockdep_trace_alloc+0x9a/0xc0
[<c108e396>] kmem_cache_alloc+0x26/0xf0
[<c10850ec>] __get_vm_area_node+0x6c/0xf0
[<c10857de>] __vmalloc_node+0x7e/0xa0
[<c108597b>] vmalloc+0x2b/0x30
[<c10e00b9>] reiserfs_init_bitmap_cache+0x39/0x70
[<c10f8178>] reiserfs_fill_super+0x2e8/0xb90
[<c1094345>] get_sb_bdev+0x145/0x180
[<c10f5a11>] get_super_block+0x21/0x30
[<c10931f0>] vfs_kern_mount+0x40/0xd0
[<c10932d9>] do_kern_mount+0x39/0xd0
[<c10a9857>] do_mount+0x2c7/0x6b0
[<c10a9ca6>] sys_mount+0x66/0xa0
[<c161589b>] mount_block_root+0xc4/0x245
[<c1615a75>] mount_root+0x59/0x5f
[<c1615b8c>] prepare_namespace+0x111/0x14b
[<c1615269>] kernel_init+0xcf/0xdb
[<c10031fb>] kernel_thread_helper+0x7/0x1c
irq event stamp: 48075
hardirqs last enabled at (48075): [<c134ad8a>]
__mutex_unlock_slowpath+0x9a/0x120
hardirqs last disabled at (48074): [<c134ad29>]
__mutex_unlock_slowpath+0x39/0x120
softirqs last enabled at (46832): [<c102f4e1>] __do_softirq+0xc1/0x110
softirqs last disabled at (46825): [<c102f57d>] do_softirq+0x4d/0x60
other info that might help us debug this:
2 locks held by kswapd0/312:
#0: (shrinker_rwsem){++++..}, at: [<c1073de4>] shrink_slab+0x24/0x170
#1: (&type->s_umount_key#19){++++..}, at: [<c10a1e0d>]
shrink_dcache_memory+0xfd/0x1a0
stack backtrace:
Pid: 312, comm: kswapd0 Not tainted 2.6.32-05594-g3ef884b #2
Call Trace:
[<c134a046>] ? printk+0x18/0x1a
[<c104db7f>] print_usage_bug+0x15f/0x1a0
[<c104df5f>] mark_lock+0x39f/0x5a0
[<c104c9fb>] ? trace_hardirqs_off+0xb/0x10
[<c1051fe0>] ? check_usage_forwards+0x0/0xf0
[<c104ffb4>] __lock_acquire+0x214/0xa70
[<c105088a>] lock_acquire+0x7a/0xa0
[<c11108a8>] ? reiserfs_write_lock+0x28/0x40
[<c134b5cf>] mutex_lock_nested+0x5f/0x2b0
[<c11108a8>] ? reiserfs_write_lock+0x28/0x40
[<c11108a8>] ? reiserfs_write_lock+0x28/0x40
[<c11108a8>] reiserfs_write_lock+0x28/0x40
[<c10ef6e0>] reiserfs_delete_inode+0x50/0x140
[<c10a52df>] ? generic_delete_inode+0x5f/0x150
[<c10ef690>] ? reiserfs_delete_inode+0x0/0x140
[<c10a531c>] generic_delete_inode+0x9c/0x150
[<c10a540d>] generic_drop_inode+0x3d/0x60
[<c10a4327>] iput+0x47/0x50
[<c10a190f>] dentry_iput+0x6f/0xf0
[<c10a1a34>] d_kill+0x24/0x50
[<c10a1a34>] d_kill+0x24/0x50
[<c10a1c7d>] __shrink_dcache_sb+0x21d/0x2b0
[<c10a1e3f>] shrink_dcache_memory+0x12f/0x1a0
[<c1073ec9>] shrink_slab+0x109/0x170
[<c10743a9>] kswapd+0x479/0x5c0
[<c10720d0>] ? isolate_pages_global+0x0/0x1b0
[<c103e080>] ? autoremove_wake_function+0x0/0x40
[<c1073f30>] ? kswapd+0x0/0x5c0
[<c103de6c>] kthread+0x6c/0x80
[<c103de00>] ? kthread+0x0/0x80
[<c10031fb>] kernel_thread_helper+0x7/0x1c
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-11 22:06 2.6.33-rc0: reiserfs: inconsistent lock state Alexander Beregalov @ 2009-12-12 20:51 ` Alexander Beregalov 2009-12-14 11:00 ` [PATCH 2/2] reiserfs: Fix reiserfs lock and journal lock inversion dependency Frederic Weisbecker 2009-12-14 10:53 ` [PATCH 1/2] reiserfs: Fix possible recursive lock Frederic Weisbecker 2009-12-14 11:09 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 2 siblings, 1 reply; 11+ messages in thread From: Alexander Beregalov @ 2009-12-12 20:51 UTC (permalink / raw) To: Linux Kernel Mailing List, Frederic Weisbecker One more warning. This is No space left situation. [ INFO: possible circular locking dependency detected ] 2.6.32-06486-g053fe57 #2 ------------------------------------------------------- vi/23454 is trying to acquire lock: (&journal->j_mutex){+.+...}, at: [<c110dac4>] do_journal_begin_r+0x64/0x2f0 but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c11106a8>] reiserfs_write_lock+0x28/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [<c104f8f3>] validate_chain+0xa23/0xf70 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c11106a8>] reiserfs_write_lock+0x28/0x40 [<c110dacb>] do_journal_begin_r+0x6b/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c10f76c2>] reiserfs_remount+0x212/0x4d0 [<c1093997>] do_remount_sb+0x67/0x140 [<c10a9ca6>] do_mount+0x436/0x6b0 [<c10a9f86>] sys_mount+0x66/0xa0 [<c1002c50>] sysenter_do_call+0x12/0x36 -> #0 (&journal->j_mutex){+.+...}: [<c104fe38>] validate_chain+0xf68/0xf70 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c110dac4>] do_journal_begin_r+0x64/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c10ef52f>] reiserfs_delete_inode+0x9f/0x140 [<c10a55fc>] generic_delete_inode+0x9c/0x150 [<c10a56ed>] generic_drop_inode+0x3d/0x60 [<c10a4607>] iput+0x47/0x50 [<c10e915c>] reiserfs_create+0x16c/0x1c0 [<c109a9c1>] vfs_create+0xc1/0x130 [<c109dbec>] do_filp_open+0x81c/0x920 [<c109004f>] do_sys_open+0x4f/0x110 [<c1090179>] sys_open+0x29/0x40 [<c1002c50>] sysenter_do_call+0x12/0x36 other info that might help us debug this: 2 locks held by vi/23454: #0: (&sb->s_type->i_mutex_key#5){+.+.+.}, at: [<c109d64e>] do_filp_open+0x27e/0x920 #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c11106a8>] reiserfs_write_lock+0x28/0x40 stack backtrace: Pid: 23454, comm: vi Not tainted 2.6.32-06486-g053fe57 #2 Call Trace: [<c134b202>] ? printk+0x18/0x1e [<c104e960>] print_circular_bug+0xc0/0xd0 [<c104fe38>] validate_chain+0xf68/0xf70 [<c104ca9b>] ? trace_hardirqs_off+0xb/0x10 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c110ff80>] ? delete_one_xattr+0x0/0x1c0 [<c110dac4>] do_journal_begin_r+0x64/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c11105b5>] ? reiserfs_delete_xattrs+0x15/0x50 [<c10ef52f>] reiserfs_delete_inode+0x9f/0x140 [<c10a55bf>] ? generic_delete_inode+0x5f/0x150 [<c10ef490>] ? reiserfs_delete_inode+0x0/0x140 [<c10a55fc>] generic_delete_inode+0x9c/0x150 [<c10a56ed>] generic_drop_inode+0x3d/0x60 [<c10a4607>] iput+0x47/0x50 [<c10e915c>] reiserfs_create+0x16c/0x1c0 [<c1099a5d>] ? inode_permission+0x7d/0xa0 [<c109a9c1>] vfs_create+0xc1/0x130 [<c10e8ff0>] ? reiserfs_create+0x0/0x1c0 [<c109dbec>] do_filp_open+0x81c/0x920 [<c104ca9b>] ? trace_hardirqs_off+0xb/0x10 [<c134dc0d>] ? _spin_unlock+0x1d/0x20 [<c10a6eea>] ? alloc_fd+0xba/0xf0 [<c109004f>] do_sys_open+0x4f/0x110 [<c1090179>] sys_open+0x29/0x40 [<c1002c50>] sysenter_do_call+0x12/0x36 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] reiserfs: Fix reiserfs lock and journal lock inversion dependency 2009-12-12 20:51 ` Alexander Beregalov @ 2009-12-14 11:00 ` Frederic Weisbecker 0 siblings, 0 replies; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-14 11:00 UTC (permalink / raw) To: Alexander Beregalov Cc: LKML, Frederic Weisbecker, Alexander Beregalov, Chris Mason, Thomas Gleixner, Ingo Molnar When we were using the bkl, we didn't care about dependencies against other locks, but the mutex conversion created new ones, which is why we have reiserfs_mutex_lock_safe(), which unlocks the reiserfs lock before acquiring another mutex. But this trick actually fails if we have acquired the reiserfs lock recursively, as we try to unlock it to acquire the new mutex without inverted dependency, but we eventually only decrease its depth. This happens in the case of a nested inode creation/deletion. Say we have no space left on the device, we create an inode and tak the lock but fail to create its entry, then we release the inode using iput(), which calls reiserfs_delete_inode() that takes the reiserfs lock recursively. The path eventually ends up in journal_begin() where we try to take the journal safely but we fail because of the reiserfs lock recursion: [ INFO: possible circular locking dependency detected ] 2.6.32-06486-g053fe57 #2 ------------------------------------------------------- vi/23454 is trying to acquire lock: (&journal->j_mutex){+.+...}, at: [<c110dac4>] do_journal_begin_r+0x64/0x2f0 but task is already holding lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c11106a8>] reiserfs_write_lock+0x28/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [<c104f8f3>] validate_chain+0xa23/0xf70 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c11106a8>] reiserfs_write_lock+0x28/0x40 [<c110dacb>] do_journal_begin_r+0x6b/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c10f76c2>] reiserfs_remount+0x212/0x4d0 [<c1093997>] do_remount_sb+0x67/0x140 [<c10a9ca6>] do_mount+0x436/0x6b0 [<c10a9f86>] sys_mount+0x66/0xa0 [<c1002c50>] sysenter_do_call+0x12/0x36 -> #0 (&journal->j_mutex){+.+...}: [<c104fe38>] validate_chain+0xf68/0xf70 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c110dac4>] do_journal_begin_r+0x64/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c10ef52f>] reiserfs_delete_inode+0x9f/0x140 [<c10a55fc>] generic_delete_inode+0x9c/0x150 [<c10a56ed>] generic_drop_inode+0x3d/0x60 [<c10a4607>] iput+0x47/0x50 [<c10e915c>] reiserfs_create+0x16c/0x1c0 [<c109a9c1>] vfs_create+0xc1/0x130 [<c109dbec>] do_filp_open+0x81c/0x920 [<c109004f>] do_sys_open+0x4f/0x110 [<c1090179>] sys_open+0x29/0x40 [<c1002c50>] sysenter_do_call+0x12/0x36 other info that might help us debug this: 2 locks held by vi/23454: #0: (&sb->s_type->i_mutex_key#5){+.+.+.}, at: [<c109d64e>] do_filp_open+0x27e/0x920 #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c11106a8>] reiserfs_write_lock+0x28/0x40 stack backtrace: Pid: 23454, comm: vi Not tainted 2.6.32-06486-g053fe57 #2 Call Trace: [<c134b202>] ? printk+0x18/0x1e [<c104e960>] print_circular_bug+0xc0/0xd0 [<c104fe38>] validate_chain+0xf68/0xf70 [<c104ca9b>] ? trace_hardirqs_off+0xb/0x10 [<c1050325>] __lock_acquire+0x4e5/0xa70 [<c105092a>] lock_acquire+0x7a/0xa0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c134c78f>] mutex_lock_nested+0x5f/0x2b0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c110dac4>] ? do_journal_begin_r+0x64/0x2f0 [<c110ff80>] ? delete_one_xattr+0x0/0x1c0 [<c110dac4>] do_journal_begin_r+0x64/0x2f0 [<c110ddcf>] journal_begin+0x7f/0x120 [<c11105b5>] ? reiserfs_delete_xattrs+0x15/0x50 [<c10ef52f>] reiserfs_delete_inode+0x9f/0x140 [<c10a55bf>] ? generic_delete_inode+0x5f/0x150 [<c10ef490>] ? reiserfs_delete_inode+0x0/0x140 [<c10a55fc>] generic_delete_inode+0x9c/0x150 [<c10a56ed>] generic_drop_inode+0x3d/0x60 [<c10a4607>] iput+0x47/0x50 [<c10e915c>] reiserfs_create+0x16c/0x1c0 [<c1099a5d>] ? inode_permission+0x7d/0xa0 [<c109a9c1>] vfs_create+0xc1/0x130 [<c10e8ff0>] ? reiserfs_create+0x0/0x1c0 [<c109dbec>] do_filp_open+0x81c/0x920 [<c104ca9b>] ? trace_hardirqs_off+0xb/0x10 [<c134dc0d>] ? _spin_unlock+0x1d/0x20 [<c10a6eea>] ? alloc_fd+0xba/0xf0 [<c109004f>] do_sys_open+0x4f/0x110 [<c1090179>] sys_open+0x29/0x40 [<c1002c50>] sysenter_do_call+0x12/0x36 To fix this, use reiserfs_lock_once() from reiserfs_delete_inode() which prevents from adding reiserfs lock recursion. Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> --- fs/reiserfs/inode.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c index 3a28e77..bd615df 100644 --- a/fs/reiserfs/inode.c +++ b/fs/reiserfs/inode.c @@ -31,11 +31,12 @@ void reiserfs_delete_inode(struct inode *inode) JOURNAL_PER_BALANCE_CNT * 2 + 2 * REISERFS_QUOTA_INIT_BLOCKS(inode->i_sb); struct reiserfs_transaction_handle th; + int depth; int err; truncate_inode_pages(&inode->i_data, 0); - reiserfs_write_lock(inode->i_sb); + depth = reiserfs_write_lock_once(inode->i_sb); /* The = 0 happens when we abort creating a new inode for some reason like lack of space.. */ if (!(inode->i_state & I_NEW) && INODE_PKEY(inode)->k_objectid != 0) { /* also handles bad_inode case */ @@ -74,7 +75,7 @@ void reiserfs_delete_inode(struct inode *inode) out: clear_inode(inode); /* note this must go after the journal_end to prevent deadlock */ inode->i_blocks = 0; - reiserfs_write_unlock(inode->i_sb); + reiserfs_write_unlock_once(inode->i_sb, depth); } static void _make_cpu_key(struct cpu_key *key, int version, __u32 dirid, -- 1.6.2.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 1/2] reiserfs: Fix possible recursive lock 2009-12-11 22:06 2.6.33-rc0: reiserfs: inconsistent lock state Alexander Beregalov 2009-12-12 20:51 ` Alexander Beregalov @ 2009-12-14 10:53 ` Frederic Weisbecker 2009-12-14 11:09 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 2 siblings, 0 replies; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-14 10:53 UTC (permalink / raw) To: Ingo Molnar Cc: LKML, Frederic Weisbecker, Alexander Beregalov, Chris Mason, Thomas Gleixner, Ingo Molnar While allocating the bitmap using vmalloc, we hold the reiserfs lock, which makes lockdep later reporting a possible deadlock as we may swap out pages to allocate memory and then take the reiserfs lock recursively: inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd0/312 [HC0[0]:SC0[0]:HE1:SE1] takes: (&REISERFS_SB(s)->lock){+.+.?.}, at: [<c11108a8>] reiserfs_write_lock+0x28/0x40 {RECLAIM_FS-ON-W} state was registered at: [<c104e1c2>] mark_held_locks+0x62/0x90 [<c104e28a>] lockdep_trace_alloc+0x9a/0xc0 [<c108e396>] kmem_cache_alloc+0x26/0xf0 [<c10850ec>] __get_vm_area_node+0x6c/0xf0 [<c10857de>] __vmalloc_node+0x7e/0xa0 [<c108597b>] vmalloc+0x2b/0x30 [<c10e00b9>] reiserfs_init_bitmap_cache+0x39/0x70 [<c10f8178>] reiserfs_fill_super+0x2e8/0xb90 [<c1094345>] get_sb_bdev+0x145/0x180 [<c10f5a11>] get_super_block+0x21/0x30 [<c10931f0>] vfs_kern_mount+0x40/0xd0 [<c10932d9>] do_kern_mount+0x39/0xd0 [<c10a9857>] do_mount+0x2c7/0x6b0 [<c10a9ca6>] sys_mount+0x66/0xa0 [<c161589b>] mount_block_root+0xc4/0x245 [<c1615a75>] mount_root+0x59/0x5f [<c1615b8c>] prepare_namespace+0x111/0x14b [<c1615269>] kernel_init+0xcf/0xdb [<c10031fb>] kernel_thread_helper+0x7/0x1c This is actually fine for two reasons: we call vmalloc at mount time then it's not in the swapping out path. Also the reiserfs lock can be acquired recursively, but since its implementation depends on a mutex, it's hard and not necessary worth it to teach that to lockdep. The lock is useless at mount time anyway, at least until we replay the journal. But let's remove it from this path later as this needs more thinking and is a sensible change. For now we can just relax the lock around vmalloc, Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> --- fs/reiserfs/bitmap.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/reiserfs/bitmap.c b/fs/reiserfs/bitmap.c index 6854957..65c8727 100644 --- a/fs/reiserfs/bitmap.c +++ b/fs/reiserfs/bitmap.c @@ -1277,7 +1277,10 @@ int reiserfs_init_bitmap_cache(struct super_block *sb) struct reiserfs_bitmap_info *bitmap; unsigned int bmap_nr = reiserfs_bmap_count(sb); + /* Avoid lock recursion in fault case */ + reiserfs_write_unlock(sb); bitmap = vmalloc(sizeof(*bitmap) * bmap_nr); + reiserfs_write_lock(sb); if (bitmap == NULL) return -ENOMEM; -- 1.6.2.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-11 22:06 2.6.33-rc0: reiserfs: inconsistent lock state Alexander Beregalov 2009-12-12 20:51 ` Alexander Beregalov 2009-12-14 10:53 ` [PATCH 1/2] reiserfs: Fix possible recursive lock Frederic Weisbecker @ 2009-12-14 11:09 ` Frederic Weisbecker 2009-12-14 20:11 ` Alexander Beregalov 2 siblings, 1 reply; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-14 11:09 UTC (permalink / raw) To: Alexander Beregalov; +Cc: Linux Kernel Mailing List On Sat, Dec 12, 2009 at 01:06:29AM +0300, Alexander Beregalov wrote: > Hi Frederic > > It is x86_32 UP > > > [ INFO: inconsistent lock state ] > 2.6.32-05594-g3ef884b #2 [...] Thanks! I've pushed two fixes in my tree. May be could you test them by merging it on latest upstream? As usual, it's on: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git reiserfs/kill-bkl Thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-14 11:09 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker @ 2009-12-14 20:11 ` Alexander Beregalov 2009-12-16 22:35 ` [PATCH] reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion Frederic Weisbecker 2009-12-16 22:41 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 0 siblings, 2 replies; 11+ messages in thread From: Alexander Beregalov @ 2009-12-14 20:11 UTC (permalink / raw) To: Frederic Weisbecker; +Cc: Linux Kernel Mailing List 2009/12/14 Frederic Weisbecker <fweisbec@gmail.com>: > On Sat, Dec 12, 2009 at 01:06:29AM +0300, Alexander Beregalov wrote: >> Hi Frederic >> >> It is x86_32 UP >> >> >> [ INFO: inconsistent lock state ] >> 2.6.32-05594-g3ef884b #2 > [...] > > > Thanks! I've pushed two fixes in my tree. May be could > you test them by merging it on latest upstream? > > As usual, it's on: > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git > reiserfs/kill-bkl Thanks, I'm going to test it. Another piece of work for you. You should hate me. [ INFO: possible circular locking dependency detected ] 2.6.32-06793-gf405425-dirty #2 ------------------------------------------------------- mv/18566 is trying to acquire lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c1110708>] reiserfs_write_lock+0x28/0x40 but task is already holding lock: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: [<c111033c>] reiserfs_for_each_xattr+0x10c/0x380 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#5/3){+.+.+.}: [<c104f723>] validate_chain+0xa23/0xf70 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c11102b4>] reiserfs_for_each_xattr+0x84/0x380 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c109cc0b>] do_unlinkat+0xdb/0x160 [<c109cca0>] sys_unlink+0x10/0x20 [<c1002c50>] sysenter_do_call+0x12/0x36 -> #0 (&REISERFS_SB(s)->lock){+.+.+.}: [<c104fc68>] validate_chain+0xf68/0xf70 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c1110708>] reiserfs_write_lock+0x28/0x40 [<c1103d6b>] search_by_key+0x1f7b/0x21b0 [<c10e73ef>] search_by_entry_key+0x1f/0x3b0 [<c10e77f7>] reiserfs_find_entry+0x77/0x400 [<c10e81e5>] reiserfs_lookup+0x85/0x130 [<c109a144>] __lookup_hash+0xb4/0x110 [<c109b763>] lookup_one_len+0xb3/0x100 [<c1110350>] reiserfs_for_each_xattr+0x120/0x380 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c10a1c4f>] dentry_iput+0x6f/0xf0 [<c10a1d74>] d_kill+0x24/0x50 [<c10a396b>] dput+0x5b/0x120 [<c109ca89>] sys_renameat+0x1b9/0x230 [<c109cb28>] sys_rename+0x28/0x30 [<c1002c50>] sysenter_do_call+0x12/0x36 other info that might help us debug this: 2 locks held by mv/18566: #0: (&sb->s_type->i_mutex_key#5/1){+.+.+.}, at: [<c109b6ac>] lock_rename+0xcc/0xd0 #1: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: [<c111033c>] reiserfs_for_each_xattr+0x10c/0x380 stack backtrace: Pid: 18566, comm: mv Tainted: G C 2.6.32-06793-gf405425-dirty #2 Call Trace: [<c134b252>] ? printk+0x18/0x1e [<c104e790>] print_circular_bug+0xc0/0xd0 [<c104fc68>] validate_chain+0xf68/0xf70 [<c104c8cb>] ? trace_hardirqs_off+0xb/0x10 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c134b60a>] ? schedule+0x27a/0x440 [<c1110708>] reiserfs_write_lock+0x28/0x40 [<c1103d6b>] search_by_key+0x1f7b/0x21b0 [<c1050176>] ? __lock_acquire+0x506/0xa70 [<c1051267>] ? lock_release_non_nested+0x1e7/0x340 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c104e354>] ? trace_hardirqs_on_caller+0x124/0x170 [<c104e3ab>] ? trace_hardirqs_on+0xb/0x10 [<c1042a55>] ? T.316+0x15/0x1a0 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c10e73ef>] search_by_entry_key+0x1f/0x3b0 [<c134bf2a>] ? __mutex_unlock_slowpath+0x9a/0x120 [<c104e354>] ? trace_hardirqs_on_caller+0x124/0x170 [<c10e77f7>] reiserfs_find_entry+0x77/0x400 [<c10e81e5>] reiserfs_lookup+0x85/0x130 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c109a144>] __lookup_hash+0xb4/0x110 [<c109b763>] lookup_one_len+0xb3/0x100 [<c1110350>] reiserfs_for_each_xattr+0x120/0x380 [<c110ffe0>] ? delete_one_xattr+0x0/0x1c0 [<c1003342>] ? math_error+0x22/0x150 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a561f>] ? generic_delete_inode+0x5f/0x150 [<c10ef4f0>] ? reiserfs_delete_inode+0x0/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c10a1c4f>] dentry_iput+0x6f/0xf0 [<c10a1d74>] d_kill+0x24/0x50 [<c10a396b>] dput+0x5b/0x120 [<c109ca89>] sys_renameat+0x1b9/0x230 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c104c8cb>] ? trace_hardirqs_off+0xb/0x10 [<c1042dde>] ? cpu_clock+0x4e/0x60 [<c1350825>] ? do_page_fault+0x155/0x370 [<c1041816>] ? up_read+0x16/0x30 [<c1350825>] ? do_page_fault+0x155/0x370 [<c109cb28>] sys_rename+0x28/0x30 [<c1002c50>] sysenter_do_call+0x12/0x36 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion 2009-12-14 20:11 ` Alexander Beregalov @ 2009-12-16 22:35 ` Frederic Weisbecker 2009-12-16 22:41 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 1 sibling, 0 replies; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-16 22:35 UTC (permalink / raw) To: Alexander Beregalov Cc: LKML, Frederic Weisbecker, Alexander Beregalov, Chris Mason, Thomas Gleixner, Ingo Molnar The reiserfs lock -> inode mutex dependency gets inverted when we relax the lock while walking to the tree. To fix this, use a specialized version of reiserfs_mutex_lock_safe that takes care of mutex subclasses. Then we can grab the inode mutex with I_MUTEX_XATTR subclass without any reiserfs lock dependency. This fixes the following report: [ INFO: possible circular locking dependency detected ] 2.6.32-06793-gf405425-dirty #2 ------------------------------------------------------- mv/18566 is trying to acquire lock: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<c1110708>] reiserfs_write_lock+0x28= /0x40 but task is already holding lock: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: [<c111033c>] reiserfs_for_each_xattr+0x10c/0x380 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#5/3){+.+.+.}: [<c104f723>] validate_chain+0xa23/0xf70 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c11102b4>] reiserfs_for_each_xattr+0x84/0x380 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c109cc0b>] do_unlinkat+0xdb/0x160 [<c109cca0>] sys_unlink+0x10/0x20 [<c1002c50>] sysenter_do_call+0x12/0x36 -> #0 (&REISERFS_SB(s)->lock){+.+.+.}: [<c104fc68>] validate_chain+0xf68/0xf70 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c1110708>] reiserfs_write_lock+0x28/0x40 [<c1103d6b>] search_by_key+0x1f7b/0x21b0 [<c10e73ef>] search_by_entry_key+0x1f/0x3b0 [<c10e77f7>] reiserfs_find_entry+0x77/0x400 [<c10e81e5>] reiserfs_lookup+0x85/0x130 [<c109a144>] __lookup_hash+0xb4/0x110 [<c109b763>] lookup_one_len+0xb3/0x100 [<c1110350>] reiserfs_for_each_xattr+0x120/0x380 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c10a1c4f>] dentry_iput+0x6f/0xf0 [<c10a1d74>] d_kill+0x24/0x50 [<c10a396b>] dput+0x5b/0x120 [<c109ca89>] sys_renameat+0x1b9/0x230 [<c109cb28>] sys_rename+0x28/0x30 [<c1002c50>] sysenter_do_call+0x12/0x36 other info that might help us debug this: 2 locks held by mv/18566: #0: (&sb->s_type->i_mutex_key#5/1){+.+.+.}, at: [<c109b6ac>] lock_rename+0xcc/0xd0 #1: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: [<c111033c>] reiserfs_for_each_xattr+0x10c/0x380 stack backtrace: Pid: 18566, comm: mv Tainted: G C 2.6.32-06793-gf405425-dirty #2 Call Trace: [<c134b252>] ? printk+0x18/0x1e [<c104e790>] print_circular_bug+0xc0/0xd0 [<c104fc68>] validate_chain+0xf68/0xf70 [<c104c8cb>] ? trace_hardirqs_off+0xb/0x10 [<c1050155>] __lock_acquire+0x4e5/0xa70 [<c105075a>] lock_acquire+0x7a/0xa0 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c134c76f>] mutex_lock_nested+0x5f/0x2b0 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c134b60a>] ? schedule+0x27a/0x440 [<c1110708>] reiserfs_write_lock+0x28/0x40 [<c1103d6b>] search_by_key+0x1f7b/0x21b0 [<c1050176>] ? __lock_acquire+0x506/0xa70 [<c1051267>] ? lock_release_non_nested+0x1e7/0x340 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c104e354>] ? trace_hardirqs_on_caller+0x124/0x170 [<c104e3ab>] ? trace_hardirqs_on+0xb/0x10 [<c1042a55>] ? T.316+0x15/0x1a0 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c10e73ef>] search_by_entry_key+0x1f/0x3b0 [<c134bf2a>] ? __mutex_unlock_slowpath+0x9a/0x120 [<c104e354>] ? trace_hardirqs_on_caller+0x124/0x170 [<c10e77f7>] reiserfs_find_entry+0x77/0x400 [<c10e81e5>] reiserfs_lookup+0x85/0x130 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c109a144>] __lookup_hash+0xb4/0x110 [<c109b763>] lookup_one_len+0xb3/0x100 [<c1110350>] reiserfs_for_each_xattr+0x120/0x380 [<c110ffe0>] ? delete_one_xattr+0x0/0x1c0 [<c1003342>] ? math_error+0x22/0x150 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c1110615>] reiserfs_delete_xattrs+0x15/0x50 [<c1110708>] ? reiserfs_write_lock+0x28/0x40 [<c10ef57f>] reiserfs_delete_inode+0x8f/0x140 [<c10a561f>] ? generic_delete_inode+0x5f/0x150 [<c10ef4f0>] ? reiserfs_delete_inode+0x0/0x140 [<c10a565c>] generic_delete_inode+0x9c/0x150 [<c10a574d>] generic_drop_inode+0x3d/0x60 [<c10a4667>] iput+0x47/0x50 [<c10a1c4f>] dentry_iput+0x6f/0xf0 [<c10a1d74>] d_kill+0x24/0x50 [<c10a396b>] dput+0x5b/0x120 [<c109ca89>] sys_renameat+0x1b9/0x230 [<c1042d2d>] ? sched_clock_cpu+0x9d/0x100 [<c104c8cb>] ? trace_hardirqs_off+0xb/0x10 [<c1042dde>] ? cpu_clock+0x4e/0x60 [<c1350825>] ? do_page_fault+0x155/0x370 [<c1041816>] ? up_read+0x16/0x30 [<c1350825>] ? do_page_fault+0x155/0x370 [<c109cb28>] sys_rename+0x28/0x30 [<c1002c50>] sysenter_do_call+0x12/0x36 Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> --- fs/reiserfs/xattr.c | 3 ++- include/linux/reiserfs_fs.h | 9 +++++++++ 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/fs/reiserfs/xattr.c b/fs/reiserfs/xattr.c index 58aa8e7..8891cd8 100644 --- a/fs/reiserfs/xattr.c +++ b/fs/reiserfs/xattr.c @@ -243,7 +243,8 @@ static int reiserfs_for_each_xattr(struct inode *inode, goto out_dir; } - mutex_lock_nested(&dir->d_inode->i_mutex, I_MUTEX_XATTR); + reiserfs_mutex_lock_nested_safe(&dir->d_inode->i_mutex, I_MUTEX_XATTR, + inode->i_sb); buf.xadir = dir; err = reiserfs_readdir_dentry(dir, &buf, fill_with_dentries, &pos); while ((err == 0 || err == -ENOSPC) && buf.count) { diff --git a/include/linux/reiserfs_fs.h b/include/linux/reiserfs_fs.h index a05b4a2..4351b49 100644 --- a/include/linux/reiserfs_fs.h +++ b/include/linux/reiserfs_fs.h @@ -97,6 +97,15 @@ static inline void reiserfs_mutex_lock_safe(struct mutex *m, reiserfs_write_lock(s); } +static inline void +reiserfs_mutex_lock_nested_safe(struct mutex *m, unsigned int subclass, + struct super_block *s) +{ + reiserfs_write_unlock(s); + mutex_lock_nested(m, subclass); + reiserfs_write_lock(s); +} + /* * When we schedule, we usually want to also release the write lock, * according to the previous bkl based locking scheme of reiserfs. -- 1.6.2.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-14 20:11 ` Alexander Beregalov 2009-12-16 22:35 ` [PATCH] reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion Frederic Weisbecker @ 2009-12-16 22:41 ` Frederic Weisbecker 2009-12-20 12:09 ` Alexander Beregalov 1 sibling, 1 reply; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-16 22:41 UTC (permalink / raw) To: Alexander Beregalov; +Cc: Linux Kernel Mailing List On Mon, Dec 14, 2009 at 11:11:35PM +0300, Alexander Beregalov wrote: > 2009/12/14 Frederic Weisbecker <fweisbec@gmail.com>: > > On Sat, Dec 12, 2009 at 01:06:29AM +0300, Alexander Beregalov wrote: > >> Hi Frederic > >> > >> It is x86_32 UP > >> > >> > >> [ INFO: inconsistent lock state ] > >> 2.6.32-05594-g3ef884b #2 > > [...] > > > > > > Thanks! I've pushed two fixes in my tree. May be could > > you test them by merging it on latest upstream? > > > > As usual, it's on: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git > > reiserfs/kill-bkl > > Thanks, I'm going to test it. > > Another piece of work for you. You should hate me. Not really, I much prefer to see your reports and fix them than later try to find sources of obscure soft lockups from users reports :) > > [ INFO: possible circular locking dependency detected ] > 2.6.32-06793-gf405425-dirty #2 I've sent a patch in another answer of this report, hopefully that fixes the issue. I've also pushed it out in my tree with the two others. Thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-16 22:41 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker @ 2009-12-20 12:09 ` Alexander Beregalov 2009-12-28 17:17 ` Frederic Weisbecker 2009-12-29 21:36 ` [PATCH] reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion Frederic Weisbecker 0 siblings, 2 replies; 11+ messages in thread From: Alexander Beregalov @ 2009-12-20 12:09 UTC (permalink / raw) To: Frederic Weisbecker; +Cc: Linux Kernel Mailing List Hi Frederic This is Linus's v2.6.33-rc1-96-gdd59f6c plus your 47376ceba5 "reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion" [ INFO: inconsistent lock state ] 2.6.33-rc1-00101-g476ef56 #1 --------------------------------- inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. kswapd0/313 [HC0[0]:SC0[0]:HE1:SE1] takes: (&REISERFS_SB(s)->lock){+.+.?.}, at: [<c1111048>] reiserfs_write_lock_once+0x28/0x50 {RECLAIM_FS-ON-W} state was registered at: [<c104e522>] mark_held_locks+0x62/0x90 [<c104e5ea>] lockdep_trace_alloc+0x9a/0xc0 [<c108efa6>] kmem_cache_alloc+0x26/0xf0 [<c1085a0c>] __get_vm_area_node+0x6c/0xf0 [<c10860fe>] __vmalloc_node+0x7e/0xa0 [<c108629b>] vmalloc+0x2b/0x30 [<c110d4ba>] journal_init+0x2a/0x9f0 [<c10f8a32>] reiserfs_fill_super+0x342/0xb80 [<c1094e85>] get_sb_bdev+0x145/0x180 [<c10f6271>] get_super_block+0x21/0x30 [<c1093d30>] vfs_kern_mount+0x40/0xd0 [<c1093e19>] do_kern_mount+0x39/0xd0 [<c10aa4f7>] do_mount+0x2c7/0x6b0 [<c10aa946>] sys_mount+0x66/0xa0 [<c16178a7>] mount_block_root+0xc4/0x245 [<c1617a81>] mount_root+0x59/0x5f [<c1617b98>] prepare_namespace+0x111/0x14b [<c1617269>] kernel_init+0xcf/0xdb [<c100303a>] kernel_thread_helper+0x6/0x1c irq event stamp: 2148275 hardirqs last enabled at (2148275): [<c134d4aa>] __mutex_unlock_slowpath+0x9a/0x120 hardirqs last disabled at (2148274): [<c134d449>] __mutex_unlock_slowpath+0x39/0x120 softirqs last enabled at (2147974): [<c102f591>] __do_softirq+0xc1/0x110 softirqs last disabled at (2147957): [<c102f62d>] do_softirq+0x4d/0x60 other info that might help us debug this: 2 locks held by kswapd0/313: #0: (shrinker_rwsem){++++..}, at: [<c10742f4>] shrink_slab+0x24/0x170 #1: (&type->s_umount_key#19){++++..}, at: [<c10a291d>] shrink_dcache_memory+0xfd/0x1a0 stack backtrace: Pid: 313, comm: kswapd0 Not tainted 2.6.33-rc1-00101-g476ef56 #1 Call Trace: [<c134c7dc>] ? printk+0x18/0x1c [<c104dedf>] print_usage_bug+0x15f/0x1a0 [<c104e2bf>] mark_lock+0x39f/0x5a0 [<c104cd5b>] ? trace_hardirqs_off+0xb/0x10 [<c1052340>] ? check_usage_forwards+0x0/0xf0 [<c1050314>] __lock_acquire+0x214/0xa70 [<c1042e75>] ? T.321+0x15/0x1a0 [<c1050bea>] lock_acquire+0x7a/0xa0 [<c1111048>] ? reiserfs_write_lock_once+0x28/0x50 [<c134dcef>] mutex_lock_nested+0x5f/0x2b0 [<c1111048>] ? reiserfs_write_lock_once+0x28/0x50 [<c1111048>] ? reiserfs_write_lock_once+0x28/0x50 [<c1111048>] reiserfs_write_lock_once+0x28/0x50 [<c10eff40>] reiserfs_delete_inode+0x50/0x140 [<c10a5f7f>] ? generic_delete_inode+0x5f/0x150 [<c10efef0>] ? reiserfs_delete_inode+0x0/0x140 [<c10a5fbc>] generic_delete_inode+0x9c/0x150 [<c10a60ad>] generic_drop_inode+0x3d/0x60 [<c10a4fd7>] iput+0x47/0x50 [<c10a248f>] dentry_iput+0x6f/0xf0 [<c10a2534>] d_kill+0x24/0x50 [<c10a277d>] __shrink_dcache_sb+0x21d/0x2b0 [<c10a294f>] shrink_dcache_memory+0x12f/0x1a0 [<c10743de>] shrink_slab+0x10e/0x170 [<c10748c7>] kswapd+0x487/0x740 [<c10724f0>] ? isolate_pages_global+0x0/0x1b0 [<c103e1c0>] ? autoremove_wake_function+0x0/0x40 [<c1074440>] ? kswapd+0x0/0x740 [<c103decc>] kthread+0x6c/0x80 [<c103de60>] ? kthread+0x0/0x80 [<c100303a>] kernel_thread_helper+0x6/0x1c ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.6.33-rc0: reiserfs: inconsistent lock state 2009-12-20 12:09 ` Alexander Beregalov @ 2009-12-28 17:17 ` Frederic Weisbecker 2009-12-29 21:36 ` [PATCH] reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion Frederic Weisbecker 1 sibling, 0 replies; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-28 17:17 UTC (permalink / raw) To: Alexander Beregalov; +Cc: Linux Kernel Mailing List On Sun, Dec 20, 2009 at 03:09:33PM +0300, Alexander Beregalov wrote: > Hi Frederic > > This is Linus's v2.6.33-rc1-96-gdd59f6c > plus your 47376ceba5 "reiserfs: Fix reiserfs lock <-> inode mutex > dependency inversion" > > [ INFO: inconsistent lock state ] > 2.6.33-rc1-00101-g476ef56 #1 > --------------------------------- > inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. > kswapd0/313 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&REISERFS_SB(s)->lock){+.+.?.}, at: [<c1111048>] > reiserfs_write_lock_once+0x28/0x50 > {RECLAIM_FS-ON-W} state was registered at: > [<c104e522>] mark_held_locks+0x62/0x90 > [<c104e5ea>] lockdep_trace_alloc+0x9a/0xc0 > [<c108efa6>] kmem_cache_alloc+0x26/0xf0 > [<c1085a0c>] __get_vm_area_node+0x6c/0xf0 > [<c10860fe>] __vmalloc_node+0x7e/0xa0 > [<c108629b>] vmalloc+0x2b/0x30 > [<c110d4ba>] journal_init+0x2a/0x9f0 Oh right, I fixed a vmalloc under reiserfs lock in the mount path but there are some others remaining. Will fix, thanks! ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion 2009-12-20 12:09 ` Alexander Beregalov 2009-12-28 17:17 ` Frederic Weisbecker @ 2009-12-29 21:36 ` Frederic Weisbecker 1 sibling, 0 replies; 11+ messages in thread From: Frederic Weisbecker @ 2009-12-29 21:36 UTC (permalink / raw) To: Alexander Beregalov; +Cc: LKML, Frederic Weisbecker, Chris Mason, Ingo Molnar Commit 500f5a0bf5f0624dae34307010e240ec090e4cde (reiserfs: Fix possible recursive lock) fixed a vmalloc under reiserfs lock that triggered a lockdep warning because of a IN-FS-RECLAIM <-> RECLAIM-FS-ON locking dependency inversion. But this patch has ommitted another vmalloc call in the same path that allocates the journal. Relax the lock for this one too. Reported-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chris Mason <chris.mason@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> --- fs/reiserfs/journal.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c index 2f8a7e7..a059879 100644 --- a/fs/reiserfs/journal.c +++ b/fs/reiserfs/journal.c @@ -2758,11 +2758,18 @@ int journal_init(struct super_block *sb, const char *j_dev_name, struct reiserfs_journal *journal; struct reiserfs_journal_list *jl; char b[BDEVNAME_SIZE]; + int ret; + /* + * Unlock here to avoid various RECLAIM-FS-ON <-> IN-RECLAIM-FS + * dependency inversion warnings. + */ + reiserfs_write_unlock(sb); journal = SB_JOURNAL(sb) = vmalloc(sizeof(struct reiserfs_journal)); if (!journal) { reiserfs_warning(sb, "journal-1256", "unable to get memory for journal structure"); + reiserfs_write_lock(sb); return 1; } memset(journal, 0, sizeof(struct reiserfs_journal)); @@ -2771,10 +2778,12 @@ int journal_init(struct super_block *sb, const char *j_dev_name, INIT_LIST_HEAD(&journal->j_working_list); INIT_LIST_HEAD(&journal->j_journal_list); journal->j_persistent_trans = 0; - if (reiserfs_allocate_list_bitmaps(sb, - journal->j_list_bitmap, - reiserfs_bmap_count(sb))) + ret = reiserfs_allocate_list_bitmaps(sb, journal->j_list_bitmap, + reiserfs_bmap_count(sb)); + reiserfs_write_lock(sb); + if (ret) goto free_and_return; + allocate_bitmap_nodes(sb); /* reserved for journal area support */ -- 1.6.2.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-12-29 21:36 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-11 22:06 2.6.33-rc0: reiserfs: inconsistent lock state Alexander Beregalov 2009-12-12 20:51 ` Alexander Beregalov 2009-12-14 11:00 ` [PATCH 2/2] reiserfs: Fix reiserfs lock and journal lock inversion dependency Frederic Weisbecker 2009-12-14 10:53 ` [PATCH 1/2] reiserfs: Fix possible recursive lock Frederic Weisbecker 2009-12-14 11:09 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 2009-12-14 20:11 ` Alexander Beregalov 2009-12-16 22:35 ` [PATCH] reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion Frederic Weisbecker 2009-12-16 22:41 ` 2.6.33-rc0: reiserfs: inconsistent lock state Frederic Weisbecker 2009-12-20 12:09 ` Alexander Beregalov 2009-12-28 17:17 ` Frederic Weisbecker 2009-12-29 21:36 ` [PATCH] reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion Frederic Weisbecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox