07 Jan, 2010
3 commits
-
Fix remaining xattr locks acquired in reiserfs_xattr_set_handle()
while we are holding the reiserfs lock to avoid lock inversions.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
Stanse found an unreachable statement in reiserfs_ioctl. There is a
if followed by error assignment and `break' with no braces. Add the
braces so that we don't break every time, but only in error case,
so that REISERFS_IOC_SETVERSION actually works when it returns no
error.Signed-off-by: Jiri Slaby
Cc: Reiserfs
Cc: Andrew Morton
Signed-off-by: Frederic Weisbecker -
reiserfs_get_acl is usually not called under the reiserfs lock,
as it doesn't need it. But it happens when it is called by
reiserfs_acl_chmod(), which creates a dependency inversion against
the private xattr inodes mutexes for the given inode.We need to call it without the reiserfs lock, especially since
it's unnecessary.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
05 Jan, 2010
3 commits
-
When we remove an xattr, we call lookup_and_delete_xattr()
that takes some private xattr inodes mutexes. But we hold
the reiserfs lock at this time, which leads to dependency
inversions.We can safely call lookup_and_delete_xattr() without the
reiserfs lock, where xattr inodes lookups only need the
xattr inodes mutexes.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
While truncating a file, reiserfs_setattr() calls inode_setattr()
that will truncate the mapping for the given inode, but for that
it needs the pages locks.In order to release these, the owners need the reiserfs lock to
complete their jobs. But they can't, as we don't release it before
calling inode_setattr().We need to do that to fix the following softlockups:
INFO: task flush-8:0:2149 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
flush-8:0 D f51af998 0 2149 2 0x00000000
f51af9ac 00000092 00000002 f51af998 c2803304 00000000 c1894ad0 010f3000
f51af9cc c1462604 c189ef80 f51af974 c1710304 f715b450 f715b5ec c2807c40
00000000 0005bb00 c2803320 c102c55b c1710304 c2807c50 c2803304 00000246
Call Trace:
[] ? schedule+0x434/0xb20
[] ? resched_task+0x4b/0x70
[] ? mark_held_locks+0x62/0x80
[] ? mutex_lock_nested+0x1fd/0x350
[] mutex_lock_nested+0x169/0x350
[] ? reiserfs_write_lock+0x2e/0x40
[] reiserfs_write_lock+0x2e/0x40
[] do_journal_end+0xc2/0xe70
[] journal_end+0xb2/0x120
[] ? pathrelse+0x33/0xb0
[] reiserfs_end_persistent_transaction+0x64/0x70
[] reiserfs_get_block+0x12ba/0x15f0
[] ? mark_held_locks+0x62/0x80
[] reiserfs_writepage+0xa74/0xe80
[] ? _raw_spin_unlock_irq+0x27/0x50
[] ? radix_tree_gang_lookup_tag_slot+0x95/0xc0
[] ? find_get_pages_tag+0x127/0x1a0
[] ? mark_held_locks+0x62/0x80
[] ? trace_hardirqs_on_caller+0x124/0x170
[] __writepage+0x10/0x40
[] write_cache_pages+0x16b/0x320
[] ? __writepage+0x0/0x40
[] generic_writepages+0x28/0x40
[] do_writepages+0x35/0x40
[] writeback_single_inode+0xc7/0x330
[] writeback_inodes_wb+0x2c2/0x490
[] wb_writeback+0x106/0x1b0
[] wb_do_writeback+0x106/0x1e0
[] ? wb_do_writeback+0x28/0x1e0
[] bdi_writeback_task+0x3a/0xb0
[] bdi_start_fn+0x63/0xc0
[] ? bdi_start_fn+0x0/0xc0
[] kthread+0x74/0x80
[] ? kthread+0x0/0x80
[] kernel_thread_helper+0x6/0x10
3 locks held by flush-8:0/2149:
#0: (&type->s_umount_key#30){+++++.}, at: [] writeback_inodes_wb+0x27f/0x490
#1: (&journal->j_mutex){+.+...}, at: [] do_journal_end+0xba/0xe70
#2: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x2e/0x40
INFO: task fstest:3813 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
fstest D 00000002 0 3813 3812 0x00000000
f5103c94 00000082 f5103c40 00000002 f5ad5450 00000007 f5103c28 011f3000
00000006 f5ad5450 c10bb005 00000480 c1710304 f5ad5450 f5ad55ec c2907c40
00000001 f5ad5450 f5103c74 00000046 00000002 f5ad5450 00000007 f5103c6c
Call Trace:
[] ? free_hot_cold_page+0x1d5/0x280
[] io_schedule+0x74/0xc0
[] sync_page+0x35/0x60
[] __wait_on_bit_lock+0x4a/0x90
[] ? sync_page+0x0/0x60
[] __lock_page+0x85/0x90
[] ? wake_bit_function+0x0/0x60
[] truncate_inode_pages_range+0x1e4/0x2d0
[] truncate_inode_pages+0x1f/0x30
[] truncate_pagecache+0x5f/0xa0
[] vmtruncate+0x5a/0x70
[] inode_setattr+0x5d/0x190
[] reiserfs_setattr+0x1f7/0x2f0
[] ? down_write+0x49/0x70
[] notify_change+0x151/0x330
[] do_truncate+0x6d/0xa0
[] do_filp_open+0x9a2/0xcf0
[] ? _raw_spin_unlock+0x2c/0x50
[] ? alloc_fd+0xe0/0x100
[] do_sys_open+0x6d/0x130
[] ? sysenter_exit+0xf/0x16
[] sys_open+0x2e/0x40
[] sysenter_do_call+0x12/0x32
3 locks held by fstest/3813:
#0: (&sb->s_type->i_mutex_key#4){+.+.+.}, at: [] do_truncate+0x63/0xa0
#1: (&sb->s_type->i_alloc_sem_key#3){+.+.+.}, at: [] notify_change+0x257/0x330
#2: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock_once+0x2e/0x50Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
On chown, reiserfs will call reiserfs_setattr() to change the owner
of the given inode, but it may also recursively call
reiserfs_setattr() to propagate the owner change to the private xattr
files for this inode.Hence, the reiserfs lock may be acquired twice which is not wanted
as reiserfs_setattr() calls journal_begin() that is going to try to
relax the lock in order to safely acquire the journal mutex.Using reiserfs_write_lock_once() from reiserfs_setattr() solves
the problem.This fixes the following warning, that precedes a lockdep report.
WARNING: at fs/reiserfs/lock.c:95 reiserfs_lock_check_recursive+0x3f/0x50()
Hardware name: MS-7418
Unwanted recursive reiserfs lock!
Pid: 4189, comm: fsstress Not tainted 2.6.33-rc2-tip-atom+ #195
Call Trace:
[] ? reiserfs_lock_check_recursive+0x3f/0x50
[] ? reiserfs_lock_check_recursive+0x3f/0x50
[] warn_slowpath_common+0x6c/0xc0
[] ? reiserfs_lock_check_recursive+0x3f/0x50
[] warn_slowpath_fmt+0x2b/0x30
[] reiserfs_lock_check_recursive+0x3f/0x50
[] do_journal_begin_r+0x83/0x350
[] journal_begin+0x7d/0x140
[] ? in_group_p+0x2a/0x30
[] ? inode_change_ok+0x91/0x140
[] reiserfs_setattr+0x15d/0x2e0
[] ? dput+0xe3/0x140
[] ? _raw_spin_unlock+0x2c/0x50
[] chown_one_xattr+0xd/0x10
[] reiserfs_for_each_xattr+0x113/0x2c0
[] ? chown_one_xattr+0x0/0x10
[] ? mutex_lock_nested+0x2a9/0x350
[] reiserfs_chown_xattrs+0x1f/0x60
[] ? in_group_p+0x2a/0x30
[] ? inode_change_ok+0x91/0x140
[] reiserfs_setattr+0x126/0x2e0
[] ? reiserfs_getxattr+0x0/0x90
[] ? cap_inode_need_killpriv+0x37/0x50
[] notify_change+0x151/0x330
[] chown_common+0x6f/0x90
[] sys_lchown+0x6d/0x80
[] sysenter_do_call+0x12/0x32
---[ end trace 7c2b77224c1442fc ]---Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
03 Jan, 2010
1 commit
-
Fix a mistake in commit 0719d3434747889b314a1e8add776418c4148bcf
(reiserfs: Fix reiserfs lock i_xattr_sem dependency inversion)
that has converted a down_write() into a down_read() accidentally.Signed-off-by: Frederic Weisbecker
Cc: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
02 Jan, 2010
9 commits
-
Relax the reiserfs lock before taking the inode mutex from
xattr_rmdir() to avoid the usual reiserfs lock inode mutex
bad dependency.Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
Relax the reiserfs lock before taking the inode mutex from
reiserfs_for_each_xattr() to avoid the usual bad dependencies:=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #179
-------------------------------------------------------
rm/3242 is trying to acquire lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] reiserfs_for_each_xattr+0x23f/0x290but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] reiserfs_for_each_xattr+0x70/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32-> #0 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_for_each_xattr+0x23f/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
1 lock held by rm/3242:
#0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40stack backtrace:
Pid: 3242, comm: rm Not tainted 2.6.32-atom #179
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? mark_held_locks+0x62/0x80
[] ? trace_hardirqs_on+0xb/0x10
[] ? mutex_unlock+0x8/0x10
[] lock_acquire+0x68/0x90
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_for_each_xattr+0x23f/0x290
[] reiserfs_for_each_xattr+0x23f/0x290
[] ? delete_one_xattr+0x0/0x100
[] reiserfs_delete_xattrs+0x1a/0x60
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_delete_inode+0x9f/0x150
[] ? _atomic_dec_and_lock+0x4f/0x70
[] ? reiserfs_delete_inode+0x0/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] ? mutex_unlock+0x8/0x10
[] ? vfs_readdir+0x7d/0xb0
[] ? filldir64+0x0/0xf0
[] ? sysenter_exit+0xf/0x16
[] ? trace_hardirqs_on_caller+0x124/0x170
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
We need to relax the reiserfs lock before locking the inode mutex
from xattr_unlink(), otherwise we'll face the usual bad dependencies:=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #178
-------------------------------------------------------
rm/3202 is trying to acquire lock:
(&journal->j_mutex){+.+...}, at: [] do_journal_begin_r+0x94/0x360but task is already holding lock:
(&sb->s_type->i_mutex_key#4/2){+.+...}, at: [] xattr_unlink+0x57/0xb0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&sb->s_type->i_mutex_key#4/2){+.+...}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] xattr_unlink+0x57/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock+0x29/0x40
[] do_journal_begin_r+0x9c/0x360
[] journal_begin+0x80/0x130
[] reiserfs_remount+0x223/0x4e0
[] do_remount_sb+0xa6/0x140
[] do_mount+0x560/0x750
[] sys_mount+0x84/0xb0
[] sysenter_do_call+0x12/0x32-> #0 (&journal->j_mutex){+.+...}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] do_journal_begin_r+0x94/0x360
[] journal_begin+0x80/0x130
[] reiserfs_unlink+0x83/0x2e0
[] xattr_unlink+0x64/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by rm/3202:
#0: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] reiserfs_for_each_xattr+0x9b/0x290
#1: (&sb->s_type->i_mutex_key#4/2){+.+...}, at: [] xattr_unlink+0x57/0xb0stack backtrace:
Pid: 3202, comm: rm Not tainted 2.6.32-atom #178
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? xattr_unlink+0x57/0xb0
[] lock_acquire+0x68/0x90
[] ? do_journal_begin_r+0x94/0x360
[] ? do_journal_begin_r+0x94/0x360
[] mutex_lock_nested+0x5b/0x340
[] ? do_journal_begin_r+0x94/0x360
[] do_journal_begin_r+0x94/0x360
[] ? run_timer_softirq+0x1a6/0x220
[] ? __do_softirq+0x50/0x140
[] journal_begin+0x80/0x130
[] ? __do_softirq+0xf2/0x140
[] ? hrtimer_interrupt+0xdf/0x220
[] reiserfs_unlink+0x83/0x2e0
[] ? mark_held_locks+0x62/0x80
[] ? trace_hardirqs_on_thunk+0xc/0x10
[] ? restore_all_notrace+0x0/0x18
[] ? xattr_unlink+0x57/0xb0
[] xattr_unlink+0x64/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] ? delete_one_xattr+0x0/0x100
[] ? mutex_lock_nested+0x299/0x340
[] reiserfs_delete_xattrs+0x1a/0x60
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_delete_inode+0x9f/0x150
[] ? _atomic_dec_and_lock+0x4f/0x70
[] ? reiserfs_delete_inode+0x0/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] ? mutex_unlock+0x8/0x10
[] ? vfs_readdir+0x7d/0xb0
[] ? filldir64+0x0/0xf0
[] ? sysenter_exit+0xf/0x16
[] ? trace_hardirqs_on_caller+0x124/0x170
[] sys_unlinkat+0x23/0x40
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
reiserfs_unlink() may or may not be called under the reiserfs
lock.
But it also takes the reiserfs lock and can then acquire it
recursively which leads to do_journal_begin_r() that fails to
relax the reiserfs lock before grabbing the journal mutex,
creating an unexpected lock inversion.We need to ensure reiserfs_unlink() won't get the reiserfs lock
recursively using reiserfs_write_lock_once().This fixes the following warning that precedes a lock inversion
report (reiserfs lock journal mutex).------------[ cut here ]------------
WARNING: at fs/reiserfs/lock.c:95 reiserfs_lock_check_recursive+0x3a/0x50()
Hardware name: MS-7418
Unwanted recursive reiserfs lock!
Pid: 3208, comm: dbench Not tainted 2.6.32-atom #177
Call Trace:
[] ? reiserfs_lock_check_recursive+0x3a/0x50
[] ? reiserfs_lock_check_recursive+0x3a/0x50
[] warn_slowpath_common+0x67/0xc0
[] ? reiserfs_lock_check_recursive+0x3a/0x50
[] warn_slowpath_fmt+0x26/0x30
[] reiserfs_lock_check_recursive+0x3a/0x50
[] do_journal_begin_r+0x83/0x360
[] ? __lock_acquire+0x1296/0x19e0
[] ? xattr_unlink+0x57/0xb0
[] journal_begin+0x80/0x130
[] reiserfs_unlink+0x7d/0x2d0
[] ? xattr_unlink+0x57/0xb0
[] ? xattr_unlink+0x57/0xb0
[] ? xattr_unlink+0x57/0xb0
[] xattr_unlink+0x64/0xb0
[] delete_one_xattr+0x29/0x100
[] reiserfs_for_each_xattr+0x10b/0x290
[] ? delete_one_xattr+0x0/0x100
[] ? mutex_lock_nested+0x299/0x340
[] reiserfs_delete_xattrs+0x1a/0x60
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_delete_inode+0x9f/0x150
[] ? _atomic_dec_and_lock+0x4f/0x70
[] ? reiserfs_delete_inode+0x0/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] ? up_read+0x16/0x30
[] ? do_page_fault+0x187/0x330
[] ? restore_all_notrace+0x0/0x18
[] ? do_page_fault+0x0/0x330
[] ? trace_hardirqs_on_caller+0x124/0x170
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x32
---[ end trace 2e35d71a6cc69d0c ]---Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
We call xattr_lookup() from reiserfs_xattr_get(). We then hold
the reiserfs lock when we grab the i_mutex. But later, we may
relax the reiserfs lock, creating dependency inversion between
both locks.The lookups and creation jobs ar already protected by the
inode mutex, so we can safely relax the reiserfs lock, dropping
the unwanted reiserfs lock -> i_mutex dependency, as shown
in the following lockdep report:=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #173
-------------------------------------------------------
cp/3204 is trying to acquire lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock_once+0x29/0x50but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] open_xa_dir+0x43/0x1b0
[] reiserfs_for_each_xattr+0x62/0x260
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x32-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] reiserfs_cache_default_acl+0x3a/0x160
[] reiserfs_mkdir+0x6c/0x2c0
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? check_usage+0x6a/0x460
[] lock_acquire+0x68/0x90
[] ? reiserfs_write_lock_once+0x29/0x50
[] ? reiserfs_write_lock_once+0x29/0x50
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] ? debug_check_no_locks_freed+0x8a/0x140
[] ? trace_hardirqs_on_caller+0x124/0x170
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] ? new_inode+0x27/0xa0
[] reiserfs_cache_default_acl+0x3a/0x160
[] ? _spin_unlock+0x27/0x40
[] reiserfs_mkdir+0x6c/0x2c0
[] ? __d_lookup+0x108/0x190
[] ? mark_held_locks+0x62/0x80
[] ? mutex_lock_nested+0x2bd/0x340
[] ? generic_permission+0x1a/0xa0
[] ? security_inode_permission+0x1e/0x20
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] ? up_read+0x16/0x30
[] ? restore_all_notrace+0x0/0x18
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
Keeping the reiserfs lock while freeing the journal on
umount path triggers a lock inversion between bdev->bd_mutex
and the reiserfs lock.We don't need the reiserfs lock at this stage. The filesystem
is not usable anymore, and there are no more pending commits,
everything got flushed (even this operation was done in parallel
and didn't required the reiserfs lock from the current process).This fixes the following lockdep report:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #172
-------------------------------------------------------
umount/3904 is trying to acquire lock:
(&bdev->bd_mutex){+.+.+.}, at: [] __blkdev_put+0x22/0x160but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_get_block+0x85/0x1620
[] do_mpage_readpage+0x1f0/0x6d0
[] mpage_readpages+0xc0/0x100
[] reiserfs_readpages+0x19/0x20
[] __do_page_cache_readahead+0x1bc/0x260
[] ra_submit+0x28/0x40
[] filemap_fault+0x40e/0x420
[] __do_fault+0x3d/0x430
[] handle_mm_fault+0x12e/0x790
[] do_page_fault+0x135/0x330
[] error_code+0x6b/0x70
[] load_elf_binary+0x82a/0x1a10
[] search_binary_handler+0x90/0x1d0
[] do_execve+0x1df/0x250
[] sys_execve+0x46/0x70
[] syscall_call+0x7/0xb-> #2 (&mm->mmap_sem){++++++}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] might_fault+0x8b/0xb0
[] copy_to_user+0x32/0x70
[] filldir64+0xa4/0xf0
[] sysfs_readdir+0x116/0x210
[] vfs_readdir+0x8d/0xb0
[] sys_getdents64+0x69/0xb0
[] sysenter_do_call+0x12/0x32-> #1 (sysfs_mutex){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] sysfs_addrm_start+0x2c/0xb0
[] create_dir+0x40/0x90
[] sysfs_create_dir+0x2b/0x50
[] kobject_add_internal+0xc2/0x1b0
[] kobject_add_varg+0x31/0x50
[] kobject_add+0x2c/0x60
[] device_add+0x94/0x560
[] add_partition+0x18a/0x2a0
[] rescan_partitions+0x33a/0x450
[] __blkdev_get+0x12f/0x2d0
[] blkdev_get+0xa/0x10
[] register_disk+0x108/0x130
[] add_disk+0xd9/0x130
[] sd_probe_async+0x105/0x1d0
[] async_thread+0xcf/0x230
[] kthread+0x74/0x80
[] kernel_thread_helper+0x7/0x3c-> #0 (&bdev->bd_mutex){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] __blkdev_put+0x22/0x160
[] blkdev_put+0xa/0x10
[] free_journal_ram+0xd2/0x130
[] do_journal_release+0x98/0x190
[] journal_release+0xa/0x10
[] reiserfs_put_super+0x36/0x130
[] generic_shutdown_super+0x4f/0xe0
[] kill_block_super+0x25/0x40
[] reiserfs_kill_sb+0x7f/0x90
[] deactivate_super+0x7a/0x90
[] mntput_no_expire+0x98/0xd0
[] sys_umount+0x4c/0x310
[] sys_oldumount+0x19/0x20
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by umount/3904:
#0: (&type->s_umount_key#30){+++++.}, at: [] deactivate_super+0x75/0x90
#1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x29/0x40stack backtrace:
Pid: 3904, comm: umount Not tainted 2.6.32-atom #172
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? free_pcppages_bulk+0x1f/0x250
[] lock_acquire+0x68/0x90
[] ? __blkdev_put+0x22/0x160
[] ? __blkdev_put+0x22/0x160
[] mutex_lock_nested+0x5b/0x340
[] ? __blkdev_put+0x22/0x160
[] ? mark_held_locks+0x62/0x80
[] ? kfree+0x92/0xd0
[] __blkdev_put+0x22/0x160
[] ? trace_hardirqs_on+0xb/0x10
[] blkdev_put+0xa/0x10
[] free_journal_ram+0xd2/0x130
[] do_journal_release+0x98/0x190
[] journal_release+0xa/0x10
[] reiserfs_put_super+0x36/0x130
[] ? up_write+0x16/0x30
[] generic_shutdown_super+0x4f/0xe0
[] kill_block_super+0x25/0x40
[] ? vfs_quota_off+0x0/0x20
[] reiserfs_kill_sb+0x7f/0x90
[] deactivate_super+0x7a/0x90
[] mntput_no_expire+0x98/0xd0
[] sys_umount+0x4c/0x310
[] sys_oldumount+0x19/0x20
[] sysenter_do_call+0x12/0x32Signed-off-by: Frederic Weisbecker
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
While deleting the xattrs of an inode, we hold the reiserfs lock
and grab the inode->i_mutex of the targeted inode and the root
private xattr directory.Later on, we may relax the reiserfs lock for various reasons, this
creates inverted dependencies.We can remove the reiserfs lock -> i_mutex dependency by relaxing
the former before calling open_xa_dir(). This is fine because the
lookup and creation of xattr private directories done in
open_xa_dir() are covered by the targeted inode mutexes. And deeper
operations in the tree are still done under the write lock.This fixes the following lockdep report:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.32-atom #173
-------------------------------------------------------
cp/3204 is trying to acquire lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock_once+0x29/0x50but task is already holding lock:
(&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#4/3){+.+.+.}:
[] __lock_acquire+0x11ff/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] open_xa_dir+0x43/0x1b0
[] reiserfs_for_each_xattr+0x62/0x260
[] reiserfs_delete_xattrs+0x1a/0x60
[] reiserfs_delete_inode+0x9f/0x150
[] generic_delete_inode+0xa2/0x170
[] generic_drop_inode+0x4f/0x70
[] iput+0x47/0x50
[] do_unlinkat+0xd5/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x32-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] __lock_acquire+0x18f6/0x19e0
[] lock_acquire+0x68/0x90
[] mutex_lock_nested+0x5b/0x340
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] reiserfs_cache_default_acl+0x3a/0x160
[] reiserfs_mkdir+0x6c/0x2c0
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32other info that might help us debug this:
2 locks held by cp/3204:
#0: (&sb->s_type->i_mutex_key#4/1){+.+.+.}, at: [] lookup_create+0x26/0xa0
#1: (&sb->s_type->i_mutex_key#4/3){+.+.+.}, at: [] open_xa_dir+0xd8/0x1b0stack backtrace:
Pid: 3204, comm: cp Not tainted 2.6.32-atom #173
Call Trace:
[] ? printk+0x18/0x1a
[] print_circular_bug+0xca/0xd0
[] __lock_acquire+0x18f6/0x19e0
[] ? check_usage+0x6a/0x460
[] lock_acquire+0x68/0x90
[] ? reiserfs_write_lock_once+0x29/0x50
[] ? reiserfs_write_lock_once+0x29/0x50
[] mutex_lock_nested+0x5b/0x340
[] ? reiserfs_write_lock_once+0x29/0x50
[] reiserfs_write_lock_once+0x29/0x50
[] reiserfs_lookup+0x62/0x140
[] ? debug_check_no_locks_freed+0x8a/0x140
[] ? trace_hardirqs_on_caller+0x124/0x170
[] __lookup_hash+0xef/0x110
[] lookup_one_len+0x8d/0xc0
[] open_xa_dir+0xea/0x1b0
[] xattr_lookup+0x15/0x160
[] reiserfs_xattr_get+0x56/0x2a0
[] reiserfs_get_acl+0xa2/0x360
[] ? new_inode+0x27/0xa0
[] reiserfs_cache_default_acl+0x3a/0x160
[] ? _spin_unlock+0x27/0x40
[] reiserfs_mkdir+0x6c/0x2c0
[] ? __d_lookup+0x108/0x190
[] ? mark_held_locks+0x62/0x80
[] ? mutex_lock_nested+0x2bd/0x340
[] ? generic_permission+0x1a/0xa0
[] ? security_inode_permission+0x1e/0x20
[] vfs_mkdir+0xd6/0x180
[] sys_mkdirat+0xc0/0xd0
[] ? up_read+0x16/0x30
[] ? restore_all_notrace+0x0/0x18
[] sys_mkdir+0x20/0x30
[] sysenter_do_call+0x12/0x32v2: Don't drop reiserfs_mutex_lock_nested_safe() as we'll still
need it laterSigned-off-by: Frederic Weisbecker
Tested-by: Christian Kujau
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
When we relax the reiserfs lock to avoid creating unwanted
dependencies against others locks while grabbing these,
we want to ensure it has not been taken recursively, otherwise
the lock won't be really relaxed. Only its depth will be decreased.
The unwanted dependency would then actually happen.To prevent from that, add a reiserfs_lock_check_recursive() call
in the places that need it.Signed-off-by: Frederic Weisbecker
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar -
i_xattr_sem depends on the reiserfs lock. But after we grab
i_xattr_sem, we may relax/relock the reiserfs lock while waiting
on a freezed filesystem, creating a dependency inversion between
the two locks.In order to avoid the i_xattr_sem -> reiserfs lock dependency, let's
create a reiserfs_down_read_safe() that acts like
reiserfs_mutex_lock_safe(): relax the reiserfs lock while grabbing
another lock to avoid undesired dependencies induced by the
heivyweight reiserfs lock.This fixes the following warning:
[ 990.005931] =======================================================
[ 990.012373] [ INFO: possible circular locking dependency detected ]
[ 990.013233] 2.6.33-rc1 #1
[ 990.013233] -------------------------------------------------------
[ 990.013233] dbench/1891 is trying to acquire lock:
[ 990.013233] (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x35/0x50
[ 990.013233]
[ 990.013233] but task is already holding lock:
[ 990.013233] (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233]
[ 990.013233] which lock already depends on the new lock.
[ 990.013233]
[ 990.013233]
[ 990.013233] the existing dependency chain (in reverse order) is:
[ 990.013233]
[ 990.013233] -> #1 (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}:
[ 990.013233] [] __lock_acquire+0xf9c/0x1560
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] down_write+0x44/0x80
[ 990.013233] [] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] system_call_fastpath+0x16/0x1b
[ 990.013233]
[ 990.013233] -> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[ 990.013233] [] __lock_acquire+0x12d0/0x1560
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [] mutex_lock_nested+0x3e/0x50
[ 990.013233] [] reiserfs_write_lock+0x35/0x50
[ 990.013233] [] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] system_call_fastpath+0x16/0x1b
[ 990.013233]
[ 990.013233] other info that might help us debug this:
[ 990.013233]
[ 990.013233] 2 locks held by dbench/1891:
[ 990.013233] #0: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [] vfs_setxattr+0x78/0xc0
[ 990.013233] #1: (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [] reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233]
[ 990.013233] stack backtrace:
[ 990.013233] Pid: 1891, comm: dbench Not tainted 2.6.33-rc1 #1
[ 990.013233] Call Trace:
[ 990.013233] [] print_circular_bug+0xe9/0xf0
[ 990.013233] [] __lock_acquire+0x12d0/0x1560
[ 990.013233] [] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] lock_acquire+0x8f/0xb0
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? reiserfs_xattr_set_handle+0x8a/0x470
[ 990.013233] [] __mutex_lock_common+0x47/0x3b0
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? reiserfs_write_lock+0x35/0x50
[ 990.013233] [] ? mark_held_locks+0x72/0xa0
[ 990.013233] [] ? __mutex_unlock_slowpath+0xbd/0x140
[ 990.013233] [] ? trace_hardirqs_on_caller+0x14d/0x1a0
[ 990.013233] [] mutex_lock_nested+0x3e/0x50
[ 990.013233] [] reiserfs_write_lock+0x35/0x50
[ 990.013233] [] reiserfs_prepare_write+0x45/0x180
[ 990.013233] [] reiserfs_xattr_set_handle+0x2a6/0x470
[ 990.013233] [] reiserfs_xattr_set+0xb0/0x150
[ 990.013233] [] ? __mutex_lock_common+0x284/0x3b0
[ 990.013233] [] user_set+0x8a/0x90
[ 990.013233] [] reiserfs_setxattr+0xaa/0xb0
[ 990.013233] [] __vfs_setxattr_noperm+0x36/0xa0
[ 990.013233] [] vfs_setxattr+0xbc/0xc0
[ 990.013233] [] setxattr+0xc0/0x150
[ 990.013233] [] ? sched_clock_cpu+0xb8/0x100
[ 990.013233] [] ? trace_hardirqs_off+0xd/0x10
[ 990.013233] [] ? cpu_clock+0x43/0x50
[ 990.013233] [] ? fget+0xb0/0x110
[ 990.013233] [] ? fget+0x0/0x110
[ 990.013233] [] ? sysret_check+0x27/0x62
[ 990.013233] [] sys_fsetxattr+0x8d/0xa0
[ 990.013233] [] system_call_fastpath+0x16/0x1bReported-and-tested-by: Christian Kujau
Signed-off-by: Frederic Weisbecker
Cc: Alexander Beregalov
Cc: Chris Mason
Cc: Ingo Molnar
30 Dec, 2009
1 commit
-
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
Signed-off-by: Frederic Weisbecker
Cc: Chris Mason
Cc: Ingo Molnar
17 Dec, 2009
1 commit
-
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: [] reiserfs_write_lock+0x28=
/0x40but task is already holding lock:
(&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
reiserfs_for_each_xattr+0x10c/0x380which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&sb->s_type->i_mutex_key#5/3){+.+.+.}:
[] validate_chain+0xa23/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] reiserfs_for_each_xattr+0x84/0x380
[] reiserfs_delete_xattrs+0x15/0x50
[] reiserfs_delete_inode+0x8f/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] do_unlinkat+0xdb/0x160
[] sys_unlink+0x10/0x20
[] sysenter_do_call+0x12/0x36-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
[] validate_chain+0xf68/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] reiserfs_write_lock+0x28/0x40
[] search_by_key+0x1f7b/0x21b0
[] search_by_entry_key+0x1f/0x3b0
[] reiserfs_find_entry+0x77/0x400
[] reiserfs_lookup+0x85/0x130
[] __lookup_hash+0xb4/0x110
[] lookup_one_len+0xb3/0x100
[] reiserfs_for_each_xattr+0x120/0x380
[] reiserfs_delete_xattrs+0x15/0x50
[] reiserfs_delete_inode+0x8f/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] dentry_iput+0x6f/0xf0
[] d_kill+0x24/0x50
[] dput+0x5b/0x120
[] sys_renameat+0x1b9/0x230
[] sys_rename+0x28/0x30
[] sysenter_do_call+0x12/0x36other info that might help us debug this:
2 locks held by mv/18566:
#0: (&sb->s_type->i_mutex_key#5/1){+.+.+.}, at: []
lock_rename+0xcc/0xd0
#1: (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
reiserfs_for_each_xattr+0x10c/0x380stack backtrace:
Pid: 18566, comm: mv Tainted: G C 2.6.32-06793-gf405425-dirty #2
Call Trace:
[] ? printk+0x18/0x1e
[] print_circular_bug+0xc0/0xd0
[] validate_chain+0xf68/0xf70
[] ? trace_hardirqs_off+0xb/0x10
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] ? reiserfs_write_lock+0x28/0x40
[] mutex_lock_nested+0x5f/0x2b0
[] ? reiserfs_write_lock+0x28/0x40
[] ? reiserfs_write_lock+0x28/0x40
[] ? schedule+0x27a/0x440
[] reiserfs_write_lock+0x28/0x40
[] search_by_key+0x1f7b/0x21b0
[] ? __lock_acquire+0x506/0xa70
[] ? lock_release_non_nested+0x1e7/0x340
[] ? reiserfs_write_lock+0x28/0x40
[] ? trace_hardirqs_on_caller+0x124/0x170
[] ? trace_hardirqs_on+0xb/0x10
[] ? T.316+0x15/0x1a0
[] ? sched_clock_cpu+0x9d/0x100
[] search_by_entry_key+0x1f/0x3b0
[] ? __mutex_unlock_slowpath+0x9a/0x120
[] ? trace_hardirqs_on_caller+0x124/0x170
[] reiserfs_find_entry+0x77/0x400
[] reiserfs_lookup+0x85/0x130
[] ? sched_clock_cpu+0x9d/0x100
[] __lookup_hash+0xb4/0x110
[] lookup_one_len+0xb3/0x100
[] reiserfs_for_each_xattr+0x120/0x380
[] ? delete_one_xattr+0x0/0x1c0
[] ? math_error+0x22/0x150
[] ? reiserfs_write_lock+0x28/0x40
[] reiserfs_delete_xattrs+0x15/0x50
[] ? reiserfs_write_lock+0x28/0x40
[] reiserfs_delete_inode+0x8f/0x140
[] ? generic_delete_inode+0x5f/0x150
[] ? reiserfs_delete_inode+0x0/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] dentry_iput+0x6f/0xf0
[] d_kill+0x24/0x50
[] dput+0x5b/0x120
[] sys_renameat+0x1b9/0x230
[] ? sched_clock_cpu+0x9d/0x100
[] ? trace_hardirqs_off+0xb/0x10
[] ? cpu_clock+0x4e/0x60
[] ? do_page_fault+0x155/0x370
[] ? up_read+0x16/0x30
[] ? do_page_fault+0x155/0x370
[] sys_rename+0x28/0x30
[] sysenter_do_call+0x12/0x36Reported-by: Alexander Beregalov
Signed-off-by: Frederic Weisbecker
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Thomas Gleixner
14 Dec, 2009
2 commits
-
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: [] do_journal_begin_r+0x64/0x2f0but task is already holding lock:
(&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[] validate_chain+0xa23/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] reiserfs_write_lock+0x28/0x40
[] do_journal_begin_r+0x6b/0x2f0
[] journal_begin+0x7f/0x120
[] reiserfs_remount+0x212/0x4d0
[] do_remount_sb+0x67/0x140
[] do_mount+0x436/0x6b0
[] sys_mount+0x66/0xa0
[] sysenter_do_call+0x12/0x36-> #0 (&journal->j_mutex){+.+...}:
[] validate_chain+0xf68/0xf70
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] mutex_lock_nested+0x5f/0x2b0
[] do_journal_begin_r+0x64/0x2f0
[] journal_begin+0x7f/0x120
[] reiserfs_delete_inode+0x9f/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] reiserfs_create+0x16c/0x1c0
[] vfs_create+0xc1/0x130
[] do_filp_open+0x81c/0x920
[] do_sys_open+0x4f/0x110
[] sys_open+0x29/0x40
[] sysenter_do_call+0x12/0x36other info that might help us debug this:
2 locks held by vi/23454:
#0: (&sb->s_type->i_mutex_key#5){+.+.+.}, at: []
do_filp_open+0x27e/0x920
#1: (&REISERFS_SB(s)->lock){+.+.+.}, at: []
reiserfs_write_lock+0x28/0x40stack backtrace:
Pid: 23454, comm: vi Not tainted 2.6.32-06486-g053fe57 #2
Call Trace:
[] ? printk+0x18/0x1e
[] print_circular_bug+0xc0/0xd0
[] validate_chain+0xf68/0xf70
[] ? trace_hardirqs_off+0xb/0x10
[] __lock_acquire+0x4e5/0xa70
[] lock_acquire+0x7a/0xa0
[] ? do_journal_begin_r+0x64/0x2f0
[] mutex_lock_nested+0x5f/0x2b0
[] ? do_journal_begin_r+0x64/0x2f0
[] ? do_journal_begin_r+0x64/0x2f0
[] ? delete_one_xattr+0x0/0x1c0
[] do_journal_begin_r+0x64/0x2f0
[] journal_begin+0x7f/0x120
[] ? reiserfs_delete_xattrs+0x15/0x50
[] reiserfs_delete_inode+0x9f/0x140
[] ? generic_delete_inode+0x5f/0x150
[] ? reiserfs_delete_inode+0x0/0x140
[] generic_delete_inode+0x9c/0x150
[] generic_drop_inode+0x3d/0x60
[] iput+0x47/0x50
[] reiserfs_create+0x16c/0x1c0
[] ? inode_permission+0x7d/0xa0
[] vfs_create+0xc1/0x130
[] ? reiserfs_create+0x0/0x1c0
[] do_filp_open+0x81c/0x920
[] ? trace_hardirqs_off+0xb/0x10
[] ? _spin_unlock+0x1d/0x20
[] ? alloc_fd+0xba/0xf0
[] do_sys_open+0x4f/0x110
[] sys_open+0x29/0x40
[] sysenter_do_call+0x12/0x36To fix this, use reiserfs_lock_once() from reiserfs_delete_inode()
which prevents from adding reiserfs lock recursion.Reported-by: Alexander Beregalov
Signed-off-by: Frederic Weisbecker
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Thomas Gleixner -
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: [] reiserfs_write_lock+0x28/0x40
{RECLAIM_FS-ON-W} state was registered at:
[] mark_held_locks+0x62/0x90
[] lockdep_trace_alloc+0x9a/0xc0
[] kmem_cache_alloc+0x26/0xf0
[] __get_vm_area_node+0x6c/0xf0
[] __vmalloc_node+0x7e/0xa0
[] vmalloc+0x2b/0x30
[] reiserfs_init_bitmap_cache+0x39/0x70
[] reiserfs_fill_super+0x2e8/0xb90
[] get_sb_bdev+0x145/0x180
[] get_super_block+0x21/0x30
[] vfs_kern_mount+0x40/0xd0
[] do_kern_mount+0x39/0xd0
[] do_mount+0x2c7/0x6b0
[] sys_mount+0x66/0xa0
[] mount_block_root+0xc4/0x245
[] mount_root+0x59/0x5f
[] prepare_namespace+0x111/0x14b
[] kernel_init+0xcf/0xdb
[] kernel_thread_helper+0x7/0x1cThis 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
Signed-off-by: Frederic Weisbecker
Cc: Chris Mason
Cc: Ingo Molnar
Cc: Thomas Gleixner
07 Dec, 2009
1 commit
-
Merge-reason: The tree was based 2.6.31. It's better to be up to date
with 2.6.32. Although no conflicting changes were made in between,
it gives benchmarking results closer to the lastest kernel behaviour.
03 Dec, 2009
15 commits
-
request_region should be used with release_region, not request_mem_region.
Geert Uytterhoeven pointed out that in the case of drivers/video/gbefb.c,
the problem is actually the other way around; request_mem_region should be
used instead of request_region.The semantic patch that finds/fixes this problem is as follows:
(http://coccinelle.lip6.fr/)//
@r1@
expression start;
@@request_region(start,...)
@b1@
expression r1.start;
@@request_mem_region(start,...)
@depends on !b1@
expression r1.start;
expression E;
@@- release_mem_region
+ release_region
(start,E)
//Signed-off-by: Julia Lawall
Signed-off-by: Ralf Baechle -
TXx9 SPI bit rate is calculated by:
fBR = (spi-baseclk) / (n + 1)
Fix calculation of min_speed_hz, max_speed_hz and n.Signed-off-by: Atsushi Nemoto
Signed-off-by: Ralf Baechle -
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
mfd: Correct WM831X_MAX_ISEL_VALUE -
These laptops often leave i8042 in a wierd state resulting in non-
operational touchpad and keyboard.Signed-off-by: Anisse Astier
Signed-off-by: Dmitry Torokhov
Signed-off-by: Linus Torvalds -
* 'for-linus' of git://neil.brown.name/md:
md: revert incorrect fix for read error handling in raid1. -
Jon confirms that recent modprobe will look in /proc/cmdline, so these
cmdline options can still be used.See http://bugzilla.kernel.org/show_bug.cgi?id=14164
Reported-by: Adam Williamson
Cc: stable@kernel.org
Signed-off-by: Rusty Russell
Signed-off-by: Linus Torvalds -
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
MIPS: RB532: Fix devices.c compilation.
MIPS: Fix MIPS I build. -
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
[PATCH] rc32434_wdt: fix compilation failure
[WATCHDOG] rc32434_wdt.c: use resource_size() -
On the parisc architecture we face for each and every loaded kernel module
this kernel "badness warning":
sysfs: cannot create duplicate filename '/module/ac97_bus/sections/.text'
Badness at fs/sysfs/dir.c:487Reason for that is, that on parisc all kernel modules do have multiple
.text sections due to the usage of the -ffunction-sections compiler flag
which is needed to reach all jump targets on this platform.An objdump on such a kernel module gives:
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 00000024 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .text 00000000 00000000 00000000 00000058 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .text.ac97_bus_match 0000001c 00000000 00000000 00000058 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .text 00000000 00000000 00000000 000000d4 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
Since the .text sections are empty (size of 0 bytes) and won't be
loaded by the kernel module loader anyway, I don't see a reason
why such sections need to be listed under
/sys/module//sections/ either.The attached patch does solve this issue by not exporting section
names which are empty.This fixes bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=14703
Signed-off-by: Helge Deller
CC: rusty@rustcorp.com.au
CC: akpm@linux-foundation.org
CC: James.Bottomley@HansenPartnership.com
CC: roland@redhat.com
CC: dave@hiauly1.hia.nrc.ca
Signed-off-by: Linus Torvalds -
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
regulator: Initialise wm831x structure pointor for ISINK driver -
The version that made it into mainline missed the initialisation of the
chip handle.Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood -
We should now use dev_set_drvdata to set the driver driver_data field.
Signed-off-by: Florian Fainelli
Patchwork: http://patchwork.linux-mips.org/patch/747/
Signed-off-by: Ralf Baechle -
Broken by d63c63e889bbeeaa461a8addf1245f89f3ce4ece (lmo) rsp.
f1e39a4a616cd9981a9decfd5332fd07a01abb8b (kernel.org).Signed-off-by: Ralf Baechle
Patchwork: http://patchwork.linux-mips.org/patch/746/ -
* 'fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6:
[ARM] pxamci: call mmc_remove_host() before freeing resources
02 Dec, 2009
4 commits
-
mmc_remove_host() will cause the mmc core to switch off the bus power by
eventually calling pxamci_set_ios(). This function uses the regulator or
the GPIO which have been freed already.This causes the following Oops on module unload.
[ 49.519649] Unable to handle kernel paging request at virtual address 30303a70
[ 49.526878] pgd = c7084000
[ 49.529563] [30303a70] *pgd=00000000
[ 49.533136] Internal error: Oops: 5 [#1]
[ 49.537025] last sysfs file: /sys/devices/platform/pxa27x-ohci/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/scsi_level
[ 49.547471] Modules linked in: pxamci(-) eeti_ts
[ 49.552061] CPU: 0 Not tainted (2.6.32-rc8 #322)
[ 49.557001] PC is at regulator_is_enabled+0x3c/0xbc
[ 49.561846] LR is at regulator_is_enabled+0x30/0xbc
[ 49.566691] pc : [] lr : [] psr: 60000013
[ 49.566702] sp : c7083e70 ip : 30303a30 fp : 00000000
[ 49.578093] r10: c705e200 r9 : c7082000 r8 : c705e2e0
[ 49.583280] r7 : c7061340 r6 : c7061340 r5 : c7083e70 r4 : 00000000
[ 49.589759] r3 : c04dc434 r2 : c04dc434 r1 : c03eecea r0 : 00000047
[ 49.596241] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 49.603329] Control: 0000397f Table: a7084018 DAC: 00000015
[ 49.609031] Process rmmod (pid: 1101, stack limit = 0xc7082278)
[ 49.614908] Stack: (0xc7083e70 to 0xc7084000)
[ 49.619238] 3e60: c7082000 c703c4f8 c705ea00 c04f4074
[ 49.627366] 3e80: 00000000 c705e3a0 ffffffff c0247ddc c70361a0 00000000 c705e3a0 ffffffff
[ 49.635499] 3ea0: c705e200 bf006400 c78c4f00 c705e200 c705e3a0 ffffffff c705e200 ffffffff
[ 49.643633] 3ec0: c04d8ac8 c02476d0 ffffffff c0247c60 c705e200 c0248678 c705e200 c0249064
[ 49.651765] 3ee0: ffffffff bf006204 c04d8ad0 c04d8ad0 c04d8ac8 bf007490 00000880 c00440c4
[ 49.659898] 3f00: 0000b748 c01c5708 bf007490 c01c44c8 c04d8ac8 c04d8afc bf007490 c01c4570
[ 49.668031] 3f20: bf007490 bf00750c c04f4258 c01c37a4 00000000 bf00750c c7083f44 c007b014
[ 49.676162] 3f40: 4000d000 6d617870 08006963 00000001 00000000 c7085000 00000001 00000000
[ 49.684287] 3f60: 4000d000 c7083f8c 00000001 bea01a54 00005401 c7ab1400 c00440c4 00082000
[ 49.692420] 3f80: bf00750c 00000880 c7083f8c 00000000 4000cfa8 00000000 00000880 bea01cc8
[ 49.700552] 3fa0: 00000081 c0043f40 00000000 00000880 bea01cc8 00000880 00000006 00000000
[ 49.708677] 3fc0: 00000000 00000880 bea01cc8 00000081 00000097 0000cca4 0000b748 00000000
[ 49.716802] 3fe0: 4001a4f0 bea01cc0 00018bf4 4001a4fc 20000010 bea01cc8 a063e021 a063e421
[ 49.724958] [] (regulator_is_enabled+0x3c/0xbc) from [] (mmc_regulator_set_ocr+0x14/0xd8)
[ 49.734836] [] (mmc_regulator_set_ocr+0x14/0xd8) from [] (pxamci_set_ios+0xd8/0x17c [pxamci])
[ 49.745044] [] (pxamci_set_ios+0xd8/0x17c [pxamci]) from [] (mmc_power_off+0x50/0x58)
[ 49.754555] [] (mmc_power_off+0x50/0x58) from [] (mmc_detach_bus+0x68/0xc4)
[ 49.763207] [] (mmc_detach_bus+0x68/0xc4) from [] (mmc_stop_host+0xd4/0x1bc)
[ 49.771944] [] (mmc_stop_host+0xd4/0x1bc) from [] (mmc_remove_host+0xc/0x20)
[ 49.780681] [] (mmc_remove_host+0xc/0x20) from [] (pxamci_remove+0xc8/0x174 [pxamci])
[ 49.790211] [] (pxamci_remove+0xc8/0x174 [pxamci]) from [] (platform_drv_remove+0x1c/0x24)
[ 49.800164] [] (platform_drv_remove+0x1c/0x24) from [] (__device_release_driver+0x7c/0xc4)
[ 49.810110] [] (__device_release_driver+0x7c/0xc4) from [] (driver_detach+0x60/0x8c)
[ 49.819535] [] (driver_detach+0x60/0x8c) from [] (bus_remove_driver+0x90/0xcc)
[ 49.828452] [] (bus_remove_driver+0x90/0xcc) from [] (sys_delete_module+0x1d8/0x254)
[ 49.837891] [] (sys_delete_module+0x1d8/0x254) from [] (ret_fast_syscall+0x0/0x28)
[ 49.847145] Code: eb06c53a e596c030 e1a0500d e59f106c (e59c0040)
[ 49.853566] ---[ end trace b5fa66a00cea142f ]---Signed-off-by: Daniel Mack
Reported-by: Sven Neumann
Cc: Pierre Ossman
Cc: linux-mmc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@kernel.org
Signed-off-by: Eric Miao -
This patch fixes the compilation failure of
rc32434 due to a bad module parameter description.Signed-off-by: Florian Fainelli
Signed-off-by: Wim Van Sebroeck -
The size value passed to ioremap_nocache() is not correct.
Use resource_size() to get the correct value.Signed-off-by: H Hartley Sweeten
Cc: Phil Sutter
Signed-off-by: Wim Van Sebroeck -
The SYSFS_DEPRECATED_V2 says "remove" older, deprecated features, but it
actually enables them, so correct this confusing, backwards text.Signed-off-by: Randy Dunlap
Cc: Kay Sievers
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
