* 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;
as well as URLs for NNTP newsgroup(s).