12 Apr, 2009

1 commit

• 9eeba6138   lockdep: warn about lockdep disabling after kernel taint ... Browse Code »

  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
  information.

  v2: Use a generic helper to disable lockdep instead of an
  open coded xchg().

  Signed-off-by: Frederic Weisbecker
  Cc: Peter Zijlstra
  LKML-Reference:
  Signed-off-by: Ingo Molnar

  Frederic Weisbecker

  2009-04-12 22:10:51 +0800  

01 Aug, 2008

1 commit

• e0fdace10   debug_locks: set oops_in_progress if we will log messages. ... Browse Code »

  Otherwise lock debugging messages on runqueue locks can deadlock the
  system due to the wakeups performed by printk().

  Signed-off-by: David S. Miller
  Signed-off-by: Ingo Molnar

  David Miller

  2008-08-01 16:46:43 +0800  

04 Jul, 2006

1 commit

• 9a11b49a8   [PATCH] lockdep: better lock debugging ... Browse Code »

  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:

  CONFIG_DEBUG_MUTEXES=y
  CONFIG_DEBUG_LOCK_ALLOC=y

  which do:

  config DEBUG_MUTEXES
  bool "Mutex debugging, basic checks"

  config DEBUG_LOCK_ALLOC
  bool "Detect incorrect freeing of live mutexes"

  Signed-off-by: Ingo Molnar
  Signed-off-by: Arjan van de Ven
  Signed-off-by: Andrew Morton
  Signed-off-by: Linus Torvalds

  Ingo Molnar

  2006-07-04 06:27:01 +0800