linux-stable.git/include/linux/reiserfs_fs.h, branch linux-2.6.33.y

Merge branch 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing

2010-01-02T19:17:05+00:00

* 'reiserfs/kill-bkl' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing:
  reiserfs: Safely acquire i_mutex from xattr_rmdir
  reiserfs: Safely acquire i_mutex from reiserfs_for_each_xattr
  reiserfs: Fix journal mutex <-> inode mutex lock inversion
  reiserfs: Fix unwanted recursive reiserfs lock in reiserfs_unlink()
  reiserfs: Relax lock before open xattr dir in reiserfs_xattr_set_handle()
  reiserfs: Relax reiserfs lock while freeing the journal
  reiserfs: Fix reiserfs lock <-> i_mutex dependency inversion on xattr
  reiserfs: Warn on lock relax if taken recursively
  reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion
  reiserfs: Fix remaining in-reclaim-fs <-> reclaim-fs-on locking inversion
  reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion
  reiserfs: Fix reiserfs lock and journal lock inversion dependency
  reiserfs: Fix possible recursive lock

reiserfs: Warn on lock relax if taken recursively

2010-01-02T00:54:37+00:00

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

reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion

2010-01-02T00:54:04+00:00

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/0x1b

Reported-and-tested-by: Christian Kujau 
Signed-off-by: Frederic Weisbecker 
Cc: Alexander Beregalov 
Cc: Chris Mason 
Cc: Ingo Molnar

reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion

2009-12-16T22:25:50+00:00

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=
/0x40

but task is already holding lock:
 (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
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){+.+.+.}:
       [] 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/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: []
lock_rename+0xcc/0xd0
 #1:  (&sb->s_type->i_mutex_key#5/3){+.+.+.}, at: []
reiserfs_for_each_xattr+0x10c/0x380

stack 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/0x36

Reported-by: Alexander Beregalov 
Signed-off-by: Frederic Weisbecker 
Cc: Chris Mason 
Cc: Ingo Molnar 
Cc: Thomas Gleixner

reiserfs: don't compile procfs.o at all if no support

2009-12-16T15:20:06+00:00

* small define cleanup in header
* fix #ifdeffery in procfs.c via Kconfig

Signed-off-by: Alexey Dobriyan 
Cc: Jeff Mahoney 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

reiserfs: remove /proc/fs/reiserfs/version

2009-12-16T15:20:06+00:00

/proc/fs/reiserfs/version is on the way of removing ->read_proc interface.
 It's empty however, so simply remove it instead of doing dummy
conversion.  It's hard to see what information userspace can extract from
empty file.

Signed-off-by: Alexey Dobriyan 
Cc: Jeff Mahoney 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kill-the-bkl/reiserfs: definitely drop the bkl from reiserfs_ioctl()

2009-10-14T21:28:12+00:00

The reiserfs ioctl path doesn't need the big kernel lock anymore , now
that the filesystem synchronizes through its own lock.

We can then turn reiserfs_ioctl() into an unlocked_ioctl callback.

Signed-off-by: Frederic Weisbecker 
Cc: Jeff Mahoney 
Cc: Chris Mason 
Cc: Ingo Molnar 
Cc: Alexander Beregalov 
Cc: Laurent Riffard 
Cc: Thomas Gleixner

kill-the-bkl/reiserfs: acquire the inode mutex safely

2009-09-14T05:18:24+00:00

While searching a pathname, an inode mutex can be acquired
in do_lookup() which calls reiserfs_lookup() which in turn
acquires the write lock.

On the other side reiserfs_fill_super() can acquire the write_lock
and then call reiserfs_lookup_privroot() which can acquire an
inode mutex (the root of the mount point).

So we theoretically risk an AB - BA lock inversion that could lead
to a deadlock.

As for other lock dependencies found since the bkl to mutex
conversion, the fix is to use reiserfs_mutex_lock_safe() which
drops the lock dependency to the write lock.

[ Impact: fix a possible deadlock with reiserfs ]

Cc: Jeff Mahoney 
Cc: Chris Mason 
Cc: Ingo Molnar 
Cc: Alexander Beregalov 
Signed-off-by: Frederic Weisbecker

kill-the-bkl/reiserfs: conditionaly release the write lock on fs_changed()

2009-09-14T05:18:15+00:00

The goal of fs_changed() is to check whether the tree changed during a
schedule(). This is a BKL legacy.

A recent patch added an explicit unconditional release/reacquire of the
write lock around the cond_resched() called inside fs_changed.

But it's wasteful to unconditionally do that, we are creating superfluous
lock contention in !TIF_NEED_RESCHED case.

This patch manage that by calling reiserfs_cond_resched() from fs_changed()
which only releases the lock if we are going to reschedule.

[ Impact: inject less lock contention and tree job retries ]

Cc: Jeff Mahoney 
Cc: Chris Mason 
Cc: Ingo Molnar 
Cc: Alexander Beregalov 
Signed-off-by: Frederic Weisbecker

kill-the-BKL/reiserfs: add reiserfs_cond_resched()

2009-09-14T05:18:14+00:00

Usually, when we call cond_resched(), we want the write lock
to be released and then reacquired once we return from scheduling.
Not only does it follow the previous bkl based locking scheme, but
it also let other waiters to get the lock.

But if we aren't going to reschedule(), such as in !TIF_NEED_RESCHED
case, it's useless to release the lock. Worse, if we release and reacquire
the lock whereas it is not needed, we create useless contentions. Also
if someone takes the lock while we are modifying or reading the tree,
there are good chances we'll have to retry our operation, eg if the
block we were seeeking has moved.

So this patch introduces a helper which only unlock the write lock
if we are going to schedule.

[ Impact: prepare to inject less lock contention and less tree operation attempts ]

Reported-by: Andi Kleen 
Cc: Jeff Mahoney 
Cc: Chris Mason 
Cc: Ingo Molnar 
Cc: Alexander Beregalov 
Signed-off-by: Frederic Weisbecker