1. 06 May, 2014 7 commits
  2. 03 Apr, 2014 1 commit
  3. 25 Jan, 2014 1 commit
  4. 24 Jan, 2014 2 commits
  5. 08 Aug, 2013 1 commit
    • Jeff Mahoney's avatar
      reiserfs: locking, handle nested locks properly · 278f6679
      Jeff Mahoney authored
      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: default avatarJeff Mahoney <jeffm@suse.com>
      278f6679
  6. 29 Jun, 2013 2 commits
  7. 20 Dec, 2012 1 commit
  8. 01 Jun, 2012 2 commits
    • Artem Bityutskiy's avatar
      reiserfs: get rid of resierfs_sync_super · 033369d1
      Artem Bityutskiy authored
      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: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      033369d1
    • Artem Bityutskiy's avatar
      reiserfs: clean-up function return type · 25729b0e
      Artem Bityutskiy authored
      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: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      25729b0e
  9. 30 May, 2012 1 commit
  10. 21 Mar, 2012 2 commits
  11. 04 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker authored
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  12. 07 Jan, 2012 1 commit
  13. 04 Jan, 2012 1 commit
  14. 26 Jul, 2011 1 commit
  15. 31 Mar, 2011 1 commit
  16. 24 Mar, 2011 1 commit
  17. 17 Nov, 2010 1 commit
  18. 26 Oct, 2010 1 commit
  19. 09 Aug, 2010 1 commit
  20. 19 Jul, 2010 1 commit
  21. 05 Mar, 2010 1 commit
  22. 02 Jan, 2010 2 commits
    • Frederic Weisbecker's avatar
      reiserfs: Warn on lock relax if taken recursively · c4a62ca3
      Frederic Weisbecker authored
      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: default avatarFrederic 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
    • Frederic Weisbecker's avatar
      reiserfs: Fix reiserfs lock <-> i_xattr_sem dependency inversion · 0719d343
      Frederic Weisbecker authored
      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: default avatarChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: default avatarFrederic 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. 16 Dec, 2009 3 commits
    • Frederic Weisbecker's avatar
      reiserfs: Fix reiserfs lock <-> inode mutex dependency inversion · 47376ceb
      Frederic Weisbecker authored
      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: default avatarAlexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      47376ceb
    • Alexey Dobriyan's avatar
      reiserfs: don't compile procfs.o at all if no support · e3c96f53
      Alexey Dobriyan authored
      * small define cleanup in header
      * fix #ifdeffery in procfs.c via Kconfig
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e3c96f53
    • Alexey Dobriyan's avatar
      reiserfs: remove /proc/fs/reiserfs/version · 904e8129
      Alexey Dobriyan authored
      /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: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: Jeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      904e8129
  24. 14 Oct, 2009 1 commit
    • Frederic Weisbecker's avatar
      kill-the-bkl/reiserfs: definitely drop the bkl from reiserfs_ioctl() · 205cb37b
      Frederic Weisbecker authored
      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: default avatarFrederic 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
  25. 14 Sep, 2009 3 commits
    • Frederic Weisbecker's avatar
      kill-the-bkl/reiserfs: acquire the inode mutex safely · c72e0575
      Frederic Weisbecker authored
      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: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      c72e0575
    • Frederic Weisbecker's avatar
      kill-the-bkl/reiserfs: conditionaly release the write lock on fs_changed() · d663af80
      Frederic Weisbecker authored
      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: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      d663af80
    • Frederic Weisbecker's avatar
      kill-the-BKL/reiserfs: add reiserfs_cond_resched() · e43d3f21
      Frederic Weisbecker authored
      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: default avatarAndi 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: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      e43d3f21