1. 13 Nov, 2018 1 commit
    • Waiman Long's avatar
      locking/lockdep: Fix debug_locks off performance problem · 5cf2ab06
      Waiman Long authored
      [ Upstream commit 9506a7425b094d2f1d9c877ed5a78f416669269b ]
      It was found that when debug_locks was turned off because of a problem
      found by the lockdep code, the system performance could drop quite
      significantly when the lock_stat code was also configured into the
      kernel. For instance, parallel kernel build time on a 4-socket x86-64
      server nearly doubled.
      Further analysis into the cause of the slowdown traced back to the
      frequent call to debug_locks_off() from the __lock_acquired() function
      probably due to some inconsistent lockdep states with debug_locks
      off. The debug_locks_off() function did an unconditional atomic xchg
      to write a 0 value into debug_locks which had already been set to 0.
      This led to severe cacheline contention in the cacheline that held
      debug_locks.  As debug_locks is being referenced in quite a few different
      places in the kernel, this greatly slow down the system performance.
      To prevent that trashing of debug_locks cacheline, lock_acquired()
      and lock_contended() now checks the state of debug_locks before
      proceeding. The debug_locks_off() function is also modified to check
      debug_locks before calling __debug_locks_off().
      Signed-off-by: 's avatarWaiman Long <longman@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-longman@redhat.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 26 Jun, 2013 1 commit
  3. 07 Mar, 2012 1 commit
  4. 29 Nov, 2010 1 commit
    • Dave Airlie's avatar
      Revert "debug_locks: set oops_in_progress if we will log messages." · bcb38ceb
      Dave Airlie authored
      This reverts commit e0fdace1.
      On-list discussion seems to suggest that the robustness fixes for printk
      make this unnecessary and DaveM has also agreed in person at Kernel Summit
      and on list.
      The main problem with this code is once we hit a lockdep splat we always
      keep oops_in_progress set, the console layer uses oops_in_progress with KMS
      to decide when it should be showing the oops and not showing X, so it causes
      problems around suspend/resume time when a userspace resume can cause a console
      switch away from X, only if oops_in_progress is set (which is what we want
      if an oops actually is in progress, but not because we had a lockdep splat
      2 days prior).
      Cc: David S Miller <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: 's avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 25 Feb, 2010 1 commit
    • Paul E. McKenney's avatar
      rcu: Introduce lockdep-based checking to RCU read-side primitives · 632ee200
      Paul E. McKenney authored
      Inspection is proving insufficient to catch all RCU misuses,
      which is understandable given that rcu_dereference() might be
      protected by any of four different flavors of RCU (RCU, RCU-bh,
      RCU-sched, and SRCU), and might also/instead be protected by any
      of a number of locking primitives. It is therefore time to
      enlist the aid of lockdep.
      This set of patches is inspired by earlier work by Peter
      Zijlstra and Thomas Gleixner, and takes the following approach:
      o	Set up separate lockdep classes for RCU, RCU-bh, and RCU-sched.
      o	Set up separate lockdep classes for each instance of SRCU.
      o	Create primitives that check for being in an RCU read-side
      	critical section.  These return exact answers if lockdep is
      	fully enabled, but if unsure, report being in an RCU read-side
      	critical section.  (We want to avoid false positives!)
      	The primitives are:
      	For RCU: rcu_read_lock_held(void)
      	For RCU-bh: rcu_read_lock_bh_held(void)
      	For RCU-sched: rcu_read_lock_sched_held(void)
      	For SRCU: srcu_read_lock_held(struct srcu_struct *sp)
      o	Add rcu_dereference_check(), which takes a second argument
      	in which one places a boolean expression based on the above
      	primitives and/or lockdep_is_held().
      o	A new kernel configuration parameter, CONFIG_PROVE_RCU, enables
      	rcu_dereference_check().  This depends on CONFIG_PROVE_LOCKING,
      	and should be quite helpful during the transition period while
      	CONFIG_PROVE_RCU-unaware patches are in flight.
      The existing rcu_dereference() primitive does no checking, but
      upcoming patches will change that.
      Signed-off-by: 's avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1266887105-1528-1-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
  6. 12 Apr, 2009 1 commit
    • Frederic Weisbecker's avatar
      lockdep: warn about lockdep disabling after kernel taint · 9eeba613
      Frederic Weisbecker authored
      Impact: provide useful missing info for developers
      Kernel taint can occur in several situations such as warnings,
      load of prorietary or staging modules, bad page, etc...
      But when such taint happens, a developer might still be working on
      the kernel, expecting that lockdep is still enabled. But a taint
      disables lockdep without ever warning about it.
      Such a kernel behaviour doesn't really help for kernel development.
      This patch adds this missing warning.
      Since the taint is done most of the time after the main message that
      explain the real source issue, it seems safe to warn about it inside
      add_taint() so that it appears at last, without hurting the main
      v2: Use a generic helper to disable lockdep instead of an
          open coded xchg().
      Signed-off-by: 's avatarFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      LKML-Reference: <1239412638-6739-1-git-send-email-fweisbec@gmail.com>
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
  7. 01 Aug, 2008 1 commit
  8. 03 Jul, 2006 1 commit
    • Ingo Molnar's avatar
      [PATCH] lockdep: better lock debugging · 9a11b49a
      Ingo Molnar authored
      Generic lock debugging:
       - generalized lock debugging framework. For example, a bug in one lock
         subsystem turns off debugging in all lock subsystems.
       - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from
         the mutex/rtmutex debugging code: it caused way too much prototype
         hackery, and lockdep will give the same information anyway.
       - ability to do silent tests
       - check lock freeing in vfree too.
       - more finegrained debugging options, to allow distributions to
         turn off more expensive debugging features.
      There's no separate 'held mutexes' list anymore - but there's a 'held locks'
      stack within lockdep, which unifies deadlock detection across all lock
      classes.  (this is independent of the lockdep validation stuff - lockdep first
      checks whether we are holding a lock already)
      Here are the current debugging options:
      which do:
       config DEBUG_MUTEXES
                bool "Mutex debugging, basic checks"
       config DEBUG_LOCK_ALLOC
               bool "Detect incorrect freeing of live mutexes"
      Signed-off-by: 's avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: 's avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>