* lockdep with reiserfs
@ 2009-12-23 4:50 Yinghai Lu
2009-12-23 6:06 ` Ingo Molnar
0 siblings, 1 reply; 4+ messages in thread
From: Yinghai Lu @ 2009-12-23 4:50 UTC (permalink / raw)
To: Ingo Molnar, Andrew Morton; +Cc: Linux Kernel Mailing List
x:~ # mount /dev/sda2 /xx
[ 277.586941] =======================================================
[ 277.594680] [ INFO: possible circular locking dependency detected ]
[ 277.601299] 2.6.33-rc1-tip-yh-00304-g97a015d-dirty #1007
[ 277.605492] -------------------------------------------------------
[ 277.622611] mount/19427 is trying to acquire lock:
[ 277.627353] (&journal->j_mutex){+.+...}, at: [<ffffffff811c6d40>]
do_journal_begin_r+0x9f/0x308
[ 277.645049]
[ 277.645050] but task is already holding lock:
[ 277.659112] (&REISERFS_SB(s)->lock){+.+.+.}, at:
[<ffffffff811cc0b0>] reiserfs_write_lock+0x30/0x42
[ 277.677168]
[ 277.677169] which lock already depends on the new lock.
[ 277.677170]
[ 277.685840]
[ 277.685841] the existing dependency chain (in reverse order) is:
[ 277.700845]
[ 277.700845] -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[ 277.707089] [<ffffffff810a8735>] check_prev_add+0x3ca/0x583
[ 277.723457] [<ffffffff810a8d4b>] validate_chain+0x45d/0x567
[ 277.738331] [<ffffffff810a9605>] __lock_acquire+0x7b0/0x838
[ 277.745738] [<ffffffff810a9751>] lock_acquire+0xc4/0xe1
[ 277.758903] [<ffffffff81d305bf>] mutex_lock_nested+0x68/0x2d2
[ 277.765408] [<ffffffff811cc0b0>] reiserfs_write_lock+0x30/0x42
[ 277.780623] [<ffffffff811c6d48>] do_journal_begin_r+0xa7/0x308
[ 277.788070] [<ffffffff811c717c>] journal_begin+0xcb/0x10f
[ 277.801530] [<ffffffff811b924f>] reiserfs_fill_super+0x6f6/0xa04
[ 277.818144] [<ffffffff81134094>] get_sb_bdev+0x134/0x17f
[ 277.824414] [<ffffffff811b67b7>] get_super_block+0x18/0x1a
[ 277.838452] [<ffffffff81132d81>] vfs_kern_mount+0x5b/0xce
[ 277.843123] [<ffffffff81132e5b>] do_kern_mount+0x4c/0xec
[ 277.858708] [<ffffffff8114aa43>] do_mount+0x1c7/0x228
[ 277.865063] [<ffffffff8114ab28>] sys_mount+0x84/0xc4
[ 277.879329] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b
[ 277.885762]
[ 277.885763] -> #0 (&journal->j_mutex){+.+...}:
[ 277.900836] [<ffffffff810a8464>] check_prev_add+0xf9/0x583
[ 277.905844] [<ffffffff810a8d4b>] validate_chain+0x45d/0x567
[ 277.921016] [<ffffffff810a9605>] __lock_acquire+0x7b0/0x838
[ 277.937549] [<ffffffff810a9751>] lock_acquire+0xc4/0xe1
[ 277.941772] [<ffffffff81d305bf>] mutex_lock_nested+0x68/0x2d2
[ 277.958127] [<ffffffff811c6d40>] do_journal_begin_r+0x9f/0x308
[ 277.964631] [<ffffffff811c717c>] journal_begin+0xcb/0x10f
[ 277.978818] [<ffffffff811b24cd>] reiserfs_delete_inode+0x96/0x141
[ 277.984215] [<ffffffff81145b40>] generic_delete_inode+0xe1/0x174
[ 278.002166] [<ffffffff81145bef>] generic_drop_inode+0x1c/0x67
[ 278.016829] [<ffffffff81144a31>] iput+0x66/0x6a
[ 278.022807] [<ffffffff811b8294>] finish_unfinished+0x47a/0x529
[ 278.037406] [<ffffffff811b93ef>] reiserfs_fill_super+0x896/0xa04
[ 278.042843] [<ffffffff81134094>] get_sb_bdev+0x134/0x17f
[ 278.058832] [<ffffffff811b67b7>] get_super_block+0x18/0x1a
[ 278.064476] [<ffffffff81132d81>] vfs_kern_mount+0x5b/0xce
[ 278.079763] [<ffffffff81132e5b>] do_kern_mount+0x4c/0xec
[ 278.085409] [<ffffffff8114aa43>] do_mount+0x1c7/0x228
[ 278.099487] [<ffffffff8114ab28>] sys_mount+0x84/0xc4
[ 278.104554] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b
[ 278.120594]
[ 278.120594] other info that might help us debug this:
[ 278.120595]
[ 278.137861] 2 locks held by mount/19427:
[ 278.142048] #0: (&type->s_umount_key#17/1){+.+.+.}, at:
[<ffffffff8113398d>] alloc_super+0x153/0x227
[ 278.161051] #1: (&REISERFS_SB(s)->lock){+.+.+.}, at:
[<ffffffff811cc0b0>] reiserfs_write_lock+0x30/0x42
[ 278.178694]
[ 278.178694] stack backtrace:
[ 278.183421] Pid: 19427, comm: mount Not tainted
2.6.33-rc1-tip-yh-00304-g97a015d-dirty #1007
[ 278.200418] Call Trace:
[ 278.203357] [<ffffffff810a7dcc>] print_circular_bug+0xb3/0xc2
[ 278.218174] [<ffffffff810a8464>] check_prev_add+0xf9/0x583
[ 278.223784] [<ffffffff810a8d4b>] validate_chain+0x45d/0x567
[ 278.238230] [<ffffffff810a9605>] __lock_acquire+0x7b0/0x838
[ 278.244997] [<ffffffff81d303de>] ? __mutex_unlock_slowpath+0x112/0x11e
[ 278.259664] [<ffffffff810a9751>] lock_acquire+0xc4/0xe1
[ 278.264989] [<ffffffff811c6d40>] ? do_journal_begin_r+0x9f/0x308
[ 278.278800] [<ffffffff81d305bf>] mutex_lock_nested+0x68/0x2d2
[ 278.284152] [<ffffffff811c6d40>] ? do_journal_begin_r+0x9f/0x308
[ 278.299640] [<ffffffff811c6d40>] ? do_journal_begin_r+0x9f/0x308
[ 278.305289] [<ffffffff811cb418>] ? reiserfs_for_each_xattr+0x72/0x2ad
[ 278.322801] [<ffffffff8109b2c8>] ? cpu_clock+0x2d/0x3f
[ 278.336165] [<ffffffff811c6d40>] do_journal_begin_r+0x9f/0x308
[ 278.341890] [<ffffffff810a5c2e>] ? trace_hardirqs_off_caller+0x1f/0xa9
[ 278.357094] [<ffffffff811c717c>] journal_begin+0xcb/0x10f
[ 278.362825] [<ffffffff811b24cd>] reiserfs_delete_inode+0x96/0x141
[ 278.377094] [<ffffffff811b2437>] ? reiserfs_delete_inode+0x0/0x141
[ 278.383601] [<ffffffff81145b40>] generic_delete_inode+0xe1/0x174
[ 278.398309] [<ffffffff81145bef>] generic_drop_inode+0x1c/0x67
[ 278.403863] [<ffffffff81144a31>] iput+0x66/0x6a
[ 278.418387] [<ffffffff811b8294>] finish_unfinished+0x47a/0x529
[ 278.422333] [<ffffffff811cc0b0>] ? reiserfs_write_lock+0x30/0x42
[ 278.438673] [<ffffffff810a6f29>] ? trace_hardirqs_on+0xd/0xf
[ 278.444584] [<ffffffff811b93ef>] reiserfs_fill_super+0x896/0xa04
[ 278.459330] [<ffffffff81134094>] get_sb_bdev+0x134/0x17f
[ 278.464098] [<ffffffff811b8b59>] ? reiserfs_fill_super+0x0/0xa04
[ 278.479768] [<ffffffff811b67b7>] get_super_block+0x18/0x1a
[ 278.484545] [<ffffffff81132d81>] vfs_kern_mount+0x5b/0xce
[ 278.500296] [<ffffffff81132e5b>] do_kern_mount+0x4c/0xec
[ 278.506534] [<ffffffff8114aa43>] do_mount+0x1c7/0x228
[ 278.518910] [<ffffffff8114ab28>] sys_mount+0x84/0xc4
[ 278.522530] [<ffffffff81d31bfe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 278.541059] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b
[ 278.555566] done
[ 278.557459] REISERFS (device sda2): There were 1 uncompleted
unlinks/truncates. Completed
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: lockdep with reiserfs 2009-12-23 4:50 lockdep with reiserfs Yinghai Lu @ 2009-12-23 6:06 ` Ingo Molnar 2009-12-24 0:30 ` Yinghai Lu 0 siblings, 1 reply; 4+ messages in thread From: Ingo Molnar @ 2009-12-23 6:06 UTC (permalink / raw) To: Yinghai Lu, =?unknown-8bit?B?RnLDqWTDqXJpYw==?= Weisbecker, Linus Torvalds Cc: Andrew Morton, Linux Kernel Mailing List * Yinghai Lu <yinghai@kernel.org> wrote: > x:~ # mount /dev/sda2 /xx > > [ 277.586941] ======================================================= > [ 277.594680] [ INFO: possible circular locking dependency detected ] > [ 277.601299] 2.6.33-rc1-tip-yh-00304-g97a015d-dirty #1007 > [ 277.605492] ------------------------------------------------------- > [ 277.622611] mount/19427 is trying to acquire lock: > [ 277.627353] (&journal->j_mutex){+.+...}, at: [<ffffffff811c6d40>] > do_journal_begin_r+0x9f/0x308 Frederic has posted the patch below to lkml - does it do the trick for you? Ingo ----- Forwarded message from Frederic Weisbecker <fweisbec@gmail.com> ----- Date: Wed, 16 Dec 2009 23:35:24 +0100 From: Frederic Weisbecker <fweisbec@gmail.com> To: Alexander Beregalov <a.beregalov@gmail.com> Cc: LKML <linux-kernel@vger.kernel.org>, Frederic Weisbecker <fweisbec@gmail.com>, Alexander Beregalov <a.beregalov@gmail.com>, Chris Mason <chris.mason@oracle.com>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu> Subject: [PATCH] reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion 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 ----- End forwarded message ----- ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: lockdep with reiserfs 2009-12-23 6:06 ` Ingo Molnar @ 2009-12-24 0:30 ` Yinghai Lu 2009-12-30 1:05 ` Frederic Weisbecker 0 siblings, 1 reply; 4+ messages in thread From: Yinghai Lu @ 2009-12-24 0:30 UTC (permalink / raw) To: Ingo Molnar Cc: Frédéric Weisbecker, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List 2009/12/22 Ingo Molnar <mingo@elte.hu>: > > * Yinghai Lu <yinghai@kernel.org> wrote: > >> x:~ # mount /dev/sda2 /xx >> >> [ 277.586941] ======================================================= >> [ 277.594680] [ INFO: possible circular locking dependency detected ] >> [ 277.601299] 2.6.33-rc1-tip-yh-00304-g97a015d-dirty #1007 >> [ 277.605492] ------------------------------------------------------- >> [ 277.622611] mount/19427 is trying to acquire lock: >> [ 277.627353] (&journal->j_mutex){+.+...}, at: [<ffffffff811c6d40>] >> do_journal_begin_r+0x9f/0x308 > > Frederic has posted the patch below to lkml - does it do the trick for you? > with that patch, the problem still happen... how to duplicate it: 1. boot sles 11 to user mode 2. hard reset the system 3. boot from network, current kernel with ramdisk as / 4. mount the root fs of sles11, will get this warning. YH x:/ # mount /dev/sda2 /xx l [ 2645.186516] ======================================================= [ 2645.194297] [ INFO: possible circular locking dependency detected ] [ 2645.205945] 2.6.33-rc1-tip-yh-00306-gae7a88c-dirty #1009 [ 2645.210995] ------------------------------------------------------- [ 2645.225078] mount/23498 is trying to acquire lock: [ 2645.228448] (&journal->j_mutex){+.+...}, at: [<ffffffff811c6d3c>] do_journal_begin_r+0x9f/0x308 [ 2645.s247950] [ 2645.247951] but task is already holding lock: [ 2645.254794] (&REISERFS_SB(s)->lock){+.+.+.}, at: [<ffffffff811cc0f0>] reiserfs_write_lock+0x30/0x42 [ 2645.269575] [ 2645.269576] which lock already depends on the new lock. [ 2645.269577] [ 2645.287630] [ 2645.287631] the existing dependency chain (in reverse order) is: [ 2645.304305] [ 2645.304305] -> #1 (&REISERFS_SB(s)->lock){+.+.+.}: [ 2645.311154] [<ffffffff810a8731>] check_prev_add+0x3ca/0x583 [ 2645.325728] [<ffffffff810a8d47>] validate_chain+0x45d/0x567 [ 2645.334270] [<ffffffff810a9601>] __lock_acquire+0x7b0/0x838 [ 2645.348666] [<ffffffff810a974d>] lock_acquire+0xc4/0xe1 [ 2645.353764] [<ffffffff81d3060f>] mutex_lock_nested+0x68/0x2d2 [ 2645.368392] [<ffffffff811cc0f0>] reiserfs_write_lock+0x30/0x42 [ 2645.384411] [<ffffffff811c6d44>] do_journal_begin_r+0xa7/0x308 [ 2645.388725] [<ffffffff811c7178>] journal_begin+0xcb/0x10f [ 2645.406960] [<ffffffff811b924b>] reiserfs_fill_super+0x6f6/0xa04 [ 2645.415302] [<ffffffff81134090>] get_sb_bdev+0x134/0x17f [ 2645.426778] [<ffffffff811b67b3>] get_super_block+0x18/0x1a [ 2645.431864] [<ffffffff81132d7d>] vfs_kern_mount+0x5b/0xce [ 2645.447564] [<ffffffff81132e57>] do_kern_mount+0x4c/0xec [ 2645.463593] [<ffffffff8114aa3f>] do_mount+0x1c7/0x228 [ 2645.470094] [<ffffffff8114ab24>] sys_mount+0x84/0xc4 [ 2645.483554] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b [ 2645.489348] [ 2645.489348] -> #0 (&journal->j_mutex){+.+...}: [ 2645.504216] [<ffffffff810a8460>] check_prev_add+0xf9/0x583 [ 2645.510208] [<ffffffff810a8d47>] validate_chain+0x45d/0x567 [ 2645.525881] [<ffffffff810a9601>] __lock_acquire+0x7b0/0x838 [ 2645.531541] [<ffffffff810a974d>] lock_acquire+0xc4/0xe1 [ 2645.545697] [<ffffffff81d3060f>] mutex_lock_nested+0x68/0x2d2 [ 2645.550231] [<ffffffff811c6d3c>] do_journal_begin_r+0x9f/0x308 [ 2645.567055] [<ffffffff811c7178>] journal_begin+0xcb/0x10f [ 2645.583683] [<ffffffff811b24c9>] reiserfs_delete_inode+0x96/0x141 [ 2645.588035] [<ffffffff81145b3c>] generic_delete_inode+0xe1/0x174 [ 2645.606570] [<ffffffff81145beb>] generic_drop_inode+0x1c/0x67 [ 2645.614302] [<ffffffff81144a2d>] iput+0x66/0x6a [ 2645.625184] [<ffffffff811b8290>] finish_unfinished+0x47a/0x529 [ 2645.630581] [<ffffffff811b93eb>] reiserfs_fill_super+0x896/0xa04 [ 2645.647972] [<ffffffff81134090>] get_sb_bdev+0x134/0x17f [ 2645.663248] [<ffffffff811b67b3>] get_super_block+0x18/0x1a [ 2645.669144] [<ffffffff81132d7d>] vfs_kern_mount+0x5b/0xce [ 2645.684350] [<ffffffff81132e57>] do_kern_mount+0x4c/0xec [ 2645.694616] [<ffffffff8114aa3f>] do_mount+0x1c7/0x228 [ 2645.704382] [<ffffffff8114ab24>] sys_mount+0x84/0xc4 [ 2645.710595] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b [ 2645.724680] [ 2645.724681] other info that might help us debug this: [ 2645.724682] [ 2645.733003] 2 locks held by mount/23498: [ 2645.745553] #0: (&type->s_umount_key#17/1){+.+.+.}, at: [<ffffffff81133989>] alloc_super+0x153/0x227 [ 2645.765911] #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [<ffffffff811cc0f0>] reiserfs_write_lock+0x30/0x42 [ 2645.782668] [ 2645.782668] stack backtrace: [ 2645.785547] Pid: 23498, comm: mount Not tainted 2.6.33-rc1-tip-yh-00306-gae7a88c-dirty #1009 [ 2645.803579] Call Trace: [ 2645.807937] [<ffffffff810a7dc8>] print_circular_bug+0xb3/0xc2 [ 2645.812166] [<ffffffff810a8460>] check_prev_add+0xf9/0x583 [ 2645.825199] [<ffffffff810a8d47>] validate_chain+0x45d/0x567 [ 2645.829286] [<ffffffff810a9601>] __lock_acquire+0x7b0/0x838 [ 2645.845975] [<ffffffff81d3042e>] ? __mutex_unlock_slowpath+0x112/0x11e [ 2645.862834] [<ffffffff810a974d>] lock_acquire+0xc4/0xe1 [ 2645.865698] [<ffffffff811c6d3c>] ? do_journal_begin_r+0x9f/0x308 [ 2645.883721] [<ffffffff81d3060f>] mutex_lock_nested+0x68/0x2d2 [ 2645.891066] [<ffffffff811c6d3c>] ? do_journal_begin_r+0x9f/0x308 [ 2645.903975] [<ffffffff811c6d3c>] ? do_journal_begin_r+0x9f/0x308 [ 2645.908421] [<ffffffff811cb414>] ? reiserfs_for_each_xattr+0x72/0x2f0 [ 2645.926237] [<ffffffff8109b2c4>] ? cpu_clock+0x2d/0x3f [ 2645.931855] [<ffffffff811c6d3c>] do_journal_begin_r+0x9f/0x308 [ 2645.946286] [<ffffffff810a5c2a>] ? trace_hardirqs_off_caller+0x1f/0xa9 [ 2645.950545] [<ffffffff811c7178>] journal_begin+0xcb/0x10f [ 2645.966761] [<ffffffff811b24c9>] reiserfs_delete_inode+0x96/0x141 [ 2645.982242] [<ffffffff811b2433>] ? reiserfs_delete_inode+0x0/0x141 [ 2645.987447] [<ffffffff81145b3c>] generic_delete_inode+0xe1/0x174 [ 2646.002256] [<ffffffff81145beb>] generic_drop_inode+0x1c/0x67 [ 2646.008206] [<ffffffff81144a2d>] iput+0x66/0x6a [ 2646.022186] [<ffffffff811b8290>] finish_unfinished+0x47a/0x529 [ 2646.030400] [<ffffffff811cc0f0>] ? reiserfs_write_lock+0x30/0x42 [ 2646.042801] [<ffffffff810a6f25>] ? trace_hardirqs_on+0xd/0xf [ 2646.046242] [<ffffffff811b93eb>] reiserfs_fill_super+0x896/0xa04 [ 2646.063914] [<ffffffff81134090>] get_sb_bdev+0x134/0x17f [ 2646.071513] [<ffffffff811b8b55>] ? reiserfs_fill_super+0x0/0xa04 [ 2646.083348] [<ffffffff811b67b3>] get_super_block+0x18/0x1a [ 2646.090453] [<ffffffff81132d7d>] vfs_kern_mount+0x5b/0xce [ 2646.104207] [<ffffffff81132e57>] do_kern_mount+0x4c/0xec [ 2646.109827] [<ffffffff8114aa3f>] do_mount+0x1c7/0x228 [ 2646.124419] [<ffffffff8114ab24>] sys_mount+0x84/0xc4 [ 2646.130317] [<ffffffff81d31c4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 2646.145285] [<ffffffff81033bdb>] system_call_fastpath+0x16/0x1b [ 2646.154272] done [ 2646.156395] REISERFS (device sda2): There were 1 uncompleted unlinks/truncates. Completed ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lockdep with reiserfs 2009-12-24 0:30 ` Yinghai Lu @ 2009-12-30 1:05 ` Frederic Weisbecker 0 siblings, 0 replies; 4+ messages in thread From: Frederic Weisbecker @ 2009-12-30 1:05 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List On Wed, Dec 23, 2009 at 04:30:23PM -0800, Yinghai Lu wrote: > 2009/12/22 Ingo Molnar <mingo@elte.hu>: > > > > * Yinghai Lu <yinghai@kernel.org> wrote: > > > >> x:~ # mount /dev/sda2 /xx > >> > >> [ 277.586941] ======================================================= > >> [ 277.594680] [ INFO: possible circular locking dependency detected ] > >> [ 277.601299] 2.6.33-rc1-tip-yh-00304-g97a015d-dirty #1007 > >> [ 277.605492] ------------------------------------------------------- > >> [ 277.622611] mount/19427 is trying to acquire lock: > >> [ 277.627353] (&journal->j_mutex){+.+...}, at: [<ffffffff811c6d40>] > >> do_journal_begin_r+0x9f/0x308 > > > > Frederic has posted the patch below to lkml - does it do the trick for you? > > > with that patch, the problem still happen... > > how to duplicate it: > 1. boot sles 11 to user mode > 2. hard reset the system > 3. boot from network, current kernel with ramdisk as / > 4. mount the root fs of sles11, will get this warning. > > YH Thanks for your report. I have troubles to understand how that can happen since the lock doesn't seem to be recursively acquired there. Anyway, looking at the path, it seems to happen when unlinks and truncate were unfinished (case of a hard reset) and become resumed at mount time. I'm trying to reproduce it, thanks! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-12-30 1:05 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-23 4:50 lockdep with reiserfs Yinghai Lu 2009-12-23 6:06 ` Ingo Molnar 2009-12-24 0:30 ` Yinghai Lu 2009-12-30 1:05 ` Frederic Weisbecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox