1. 07 5月, 2014 5 次提交
  2. 04 4月, 2014 1 次提交
  3. 25 1月, 2014 1 次提交
  4. 24 1月, 2014 2 次提交
  5. 09 8月, 2013 1 次提交
    • J
      reiserfs: locking, handle nested locks properly · 278f6679
      Jeff Mahoney 提交于
      The reiserfs write lock replaced the BKL and uses similar semantics.
      
      Frederic's locking code makes a distinction between when the lock is nested
      and when it's being acquired/released, but I don't think that's the right
      distinction to make.
      
      The right distinction is between the lock being released at end-of-use and
      the lock being released for a schedule. The unlock should return the depth
      and the lock should restore it, rather than the other way around as it is now.
      
      This patch implements that and adds a number of places where the lock
      should be dropped.
      Signed-off-by: NJeff Mahoney <jeffm@suse.com>
      278f6679
  6. 29 6月, 2013 2 次提交
  7. 21 12月, 2012 1 次提交
  8. 01 6月, 2012 2 次提交
    • A
      reiserfs: get rid of resierfs_sync_super · 033369d1
      Artem Bityutskiy 提交于
      This patch stops reiserfs using the VFS 'write_super()' method along with the
      s_dirt flag, because they are on their way out.
      
      The whole "superblock write-out" VFS infrastructure is served by the
      'sync_supers()' kernel thread, which wakes up every 5 (by default) seconds and
      writes out all dirty superblock using the '->write_super()' call-back.  But the
      problem with this thread is that it wastes power by waking up the system every
      5 seconds, even if there are no diry superblocks, or there are no client
      file-systems which would need this (e.g., btrfs does not use
      '->write_super()'). So we want to kill it completely and thus, we need to make
      file-systems to stop using the '->write_super()' VFS service, and then remove
      it together with the kernel thread.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      033369d1
    • A
      reiserfs: clean-up function return type · 25729b0e
      Artem Bityutskiy 提交于
      Turn 'reiserfs_flush_old_commits()' into a void function because the callers
      do not cares about what it returns anyway.
      
      We are going to remove the 'sb->s_dirt' field completely and this patch is a
      small step towards this direction.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      25729b0e
  9. 30 5月, 2012 1 次提交
  10. 21 3月, 2012 2 次提交
  11. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  12. 07 1月, 2012 1 次提交
  13. 04 1月, 2012 1 次提交
  14. 26 7月, 2011 1 次提交
  15. 31 3月, 2011 1 次提交
  16. 24 3月, 2011 1 次提交
  17. 18 11月, 2010 1 次提交
  18. 26 10月, 2010 1 次提交
  19. 10 8月, 2010 1 次提交
  20. 19 7月, 2010 1 次提交
  21. 06 3月, 2010 1 次提交
  22. 02 1月, 2010 2 次提交
    • F
      reiserfs: Warn on lock relax if taken recursively · c4a62ca3
      Frederic Weisbecker 提交于
      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: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      c4a62ca3
    • F
      reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion · 0719d343
      Frederic Weisbecker 提交于
      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: [<ffffffff81159505>] reiserfs_write_lock+0x35/0x50
      [  990.013233]
      [  990.013233] but task is already holding lock:
      [  990.013233]  (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [<ffffffff8115899a>] 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]        [<ffffffff81063afc>] __lock_acquire+0xf9c/0x1560
      [  990.013233]        [<ffffffff8106414f>] lock_acquire+0x8f/0xb0
      [  990.013233]        [<ffffffff814ac194>] down_write+0x44/0x80
      [  990.013233]        [<ffffffff8115899a>] reiserfs_xattr_set_handle+0x8a/0x470
      [  990.013233]        [<ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
      [  990.013233]        [<ffffffff8115a6aa>] user_set+0x8a/0x90
      [  990.013233]        [<ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
      [  990.013233]        [<ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
      [  990.013233]        [<ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
      [  990.013233]        [<ffffffff810e2780>] setxattr+0xc0/0x150
      [  990.013233]        [<ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
      [  990.013233]        [<ffffffff81002dab>] system_call_fastpath+0x16/0x1b
      [  990.013233]
      [  990.013233] -> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
      [  990.013233]        [<ffffffff81063e30>] __lock_acquire+0x12d0/0x1560
      [  990.013233]        [<ffffffff8106414f>] lock_acquire+0x8f/0xb0
      [  990.013233]        [<ffffffff814aba77>] __mutex_lock_common+0x47/0x3b0
      [  990.013233]        [<ffffffff814abebe>] mutex_lock_nested+0x3e/0x50
      [  990.013233]        [<ffffffff81159505>] reiserfs_write_lock+0x35/0x50
      [  990.013233]        [<ffffffff811340e5>] reiserfs_prepare_write+0x45/0x180
      [  990.013233]        [<ffffffff81158bb6>] reiserfs_xattr_set_handle+0x2a6/0x470
      [  990.013233]        [<ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
      [  990.013233]        [<ffffffff8115a6aa>] user_set+0x8a/0x90
      [  990.013233]        [<ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
      [  990.013233]        [<ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
      [  990.013233]        [<ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
      [  990.013233]        [<ffffffff810e2780>] setxattr+0xc0/0x150
      [  990.013233]        [<ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
      [  990.013233]        [<ffffffff81002dab>] 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: [<ffffffff810e2678>] vfs_setxattr+0x78/0xc0
      [  990.013233]  #1:  (&REISERFS_I(inode)->i_xattr_sem){+.+.+.}, at: [<ffffffff8115899a>] 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]  [<ffffffff81061639>] print_circular_bug+0xe9/0xf0
      [  990.013233]  [<ffffffff81063e30>] __lock_acquire+0x12d0/0x1560
      [  990.013233]  [<ffffffff8115899a>] ? reiserfs_xattr_set_handle+0x8a/0x470
      [  990.013233]  [<ffffffff8106414f>] lock_acquire+0x8f/0xb0
      [  990.013233]  [<ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
      [  990.013233]  [<ffffffff8115899a>] ? reiserfs_xattr_set_handle+0x8a/0x470
      [  990.013233]  [<ffffffff814aba77>] __mutex_lock_common+0x47/0x3b0
      [  990.013233]  [<ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
      [  990.013233]  [<ffffffff81159505>] ? reiserfs_write_lock+0x35/0x50
      [  990.013233]  [<ffffffff81062592>] ? mark_held_locks+0x72/0xa0
      [  990.013233]  [<ffffffff814ab81d>] ? __mutex_unlock_slowpath+0xbd/0x140
      [  990.013233]  [<ffffffff810628ad>] ? trace_hardirqs_on_caller+0x14d/0x1a0
      [  990.013233]  [<ffffffff814abebe>] mutex_lock_nested+0x3e/0x50
      [  990.013233]  [<ffffffff81159505>] reiserfs_write_lock+0x35/0x50
      [  990.013233]  [<ffffffff811340e5>] reiserfs_prepare_write+0x45/0x180
      [  990.013233]  [<ffffffff81158bb6>] reiserfs_xattr_set_handle+0x2a6/0x470
      [  990.013233]  [<ffffffff81158e30>] reiserfs_xattr_set+0xb0/0x150
      [  990.013233]  [<ffffffff814abcb4>] ? __mutex_lock_common+0x284/0x3b0
      [  990.013233]  [<ffffffff8115a6aa>] user_set+0x8a/0x90
      [  990.013233]  [<ffffffff8115901a>] reiserfs_setxattr+0xaa/0xb0
      [  990.013233]  [<ffffffff810e2596>] __vfs_setxattr_noperm+0x36/0xa0
      [  990.013233]  [<ffffffff810e26bc>] vfs_setxattr+0xbc/0xc0
      [  990.013233]  [<ffffffff810e2780>] setxattr+0xc0/0x150
      [  990.013233]  [<ffffffff81056018>] ? sched_clock_cpu+0xb8/0x100
      [  990.013233]  [<ffffffff8105eded>] ? trace_hardirqs_off+0xd/0x10
      [  990.013233]  [<ffffffff810560a3>] ? cpu_clock+0x43/0x50
      [  990.013233]  [<ffffffff810c6820>] ? fget+0xb0/0x110
      [  990.013233]  [<ffffffff810c6770>] ? fget+0x0/0x110
      [  990.013233]  [<ffffffff81002ddc>] ? sysret_check+0x27/0x62
      [  990.013233]  [<ffffffff810e289d>] sys_fsetxattr+0x8d/0xa0
      [  990.013233]  [<ffffffff81002dab>] system_call_fastpath+0x16/0x1b
      Reported-and-tested-by: NChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      0719d343
  23. 17 12月, 2009 1 次提交
    • F
      reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion · 47376ceb
      Frederic Weisbecker 提交于
      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-gf4054253-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-gf4054253-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: NAlexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      47376ceb
  24. 16 12月, 2009 2 次提交
  25. 15 10月, 2009 1 次提交
    • F
      kill-the-bkl/reiserfs: definitely drop the bkl from reiserfs_ioctl() · 205cb37b
      Frederic Weisbecker 提交于
      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: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Cc: Laurent Riffard <laurent.riffard@free.fr>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      205cb37b
  26. 14 9月, 2009 5 次提交
    • F
      kill-the-bkl/reiserfs: acquire the inode mutex safely · c72e0575
      Frederic Weisbecker 提交于
      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 <jeffm@suse.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      c72e0575
    • F
      kill-the-bkl/reiserfs: conditionaly release the write lock on fs_changed() · d663af80
      Frederic Weisbecker 提交于
      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 <jeffm@suse.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      d663af80
    • F
      kill-the-BKL/reiserfs: add reiserfs_cond_resched() · e43d3f21
      Frederic Weisbecker 提交于
      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: NAndi Kleen <andi@firstfloor.org>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      e43d3f21
    • F
      kill-the-BKL/reiserfs: release write lock on fs_changed() · f32049dc
      Frederic Weisbecker 提交于
      fs_changed() is a macro used by reiserfs to check whether its tree has been
      rebalanced. It has been designed to check parallel changes on the tree after
      calling a sleeping function, which released the Bkl.
      
      fs_changed() also calls cond_resched(), so that if rescheduling is needed,
      we are in the best place to do that, since we check if the tree has changed
      just after (because of the bkl release on schedule()).
      
      Even if we are not anymore using the Bkl, we still want to release the lock
      while we reschedule, so that other waiters for the lock can acquire it safely,
      because of the following __fs_changed() check.
      
      [ Impact: release the reiserfs write lock when it is not needed ]
      
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      f32049dc
    • F
      kill-the-BKL/reiserfs: provide a tool to lock only once the write lock · daf88c89
      Frederic Weisbecker 提交于
      Sometimes we don't want to recursively hold the per superblock write
      lock because we want to be sure it is actually released when we come
      to sleep.
      
      This patch introduces the necessary tools for that.
      
      reiserfs_write_lock_once() does the same job than reiserfs_write_lock()
      except that it won't try to acquire recursively the lock if the current
      task already owns it. Also the lock_depth before the call of this function
      is returned.
      
      reiserfs_write_unlock_once() unlock only if reiserfs_write_lock_once()
      returned a depth equal to -1, ie: only if it actually locked.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Alessio Igor Bogani <abogani@texware.it>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      LKML-Reference: <1239680065-25013-2-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      daf88c89