1. 26 Mar, 2010 1 commit
    • Henrik Kretzschmar's avatar
      debugobjects: Section mismatch cleanup · 1fb2f77c
      Henrik Kretzschmar authored
      This patch marks two functions, which only get called at
      initialization, as __init.
      Here is also interesting, that modpost doesn't catch here the right
      function name.
      WARNING: lib/built-in.o(.text+0x585f): Section mismatch in reference
      from the function T.506() to the variable .init.data:obj
      The function T.506() references the variable __initdata obj.
      This is often because T.506 lacks a __initdata annotation or the 
      annotation of obj is wrong.
      Signed-off-by: default avatarHenrik Kretzschmar <henne@nachtwindheim.de>
      LKML-Reference: <1269632315-19403-1-git-send-email-henne@nachtwindheim.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  2. 14 Dec, 2009 1 commit
  3. 11 Oct, 2009 1 commit
  4. 17 Mar, 2009 2 commits
    • Thomas Gleixner's avatar
      debugobjects: delay free of internal objects · 337fff8b
      Thomas Gleixner authored
      Impact: avoid recursive kfree calls, less slab activity on heavy load
      debugobjects checks on kfree whether tracked objects are freed. When a
      tracked object is freed debugobjects frees the internal reference
      object as well. The debug object slab cache is marked to not recurse
      into debugobjects when a slab objects is freed, but the recursive call
      can be problematic versus locking in the memory allocator.
      Defer the freeing of debug slab objects via schedule_work. The reasons
      not to use RCU are:
      1) rcu makes the data structure larger
      2) there is no real need for rcu as nothing references the obj after
         we freed it
      3) under heavy load it is easier to reuse the to be freed objects instead
         of allocating new objects from the slab. This lowered the slab activity
         significantly in a heavy load networking test where lots of timers are
         created/destroyed. The workqueue based delayed free allows us just to
         put the to be freed objects back into the object pool and reuse them
         right away.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <200903162049.58058.nickpiggin@yahoo.com.au>
    • Thomas Gleixner's avatar
      debugobjects: replace static objects when slab cache becomes available · 1be1cb7b
      Thomas Gleixner authored
      Impact: refactor/consolidate object management, prepare for delayed free
      debugobjects allocates static reference objects to track objects which
      are initialized or activated before the slab cache becomes
      available. These static reference objects have to be handled
      seperately in free_object(). The handling of these objects is in the
      way of implementing a delayed free functionality. The delayed free is
      required to avoid callbacks into the mm code from
      Replace the static object references with dynamic ones after the slab
      cache has been initialized. The static objects are now marked initdata.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <200903162049.58058.nickpiggin@yahoo.com.au>
  5. 02 Mar, 2009 1 commit
  6. 26 Nov, 2008 1 commit
    • Ingo Molnar's avatar
      debugobjects: add boot parameter default value · 3ae70205
      Ingo Molnar authored
      Impact: add .config driven boot parameter default value
      Right now debugobjects can only be activated if the debug_objects
      boot parameter is passed in via the boot command line.
      Make this more convenient (and randomizable) by also providing
      a .config method. Enable it by default. (DEBUG_OBJECTS itself
      is default-off)
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  7. 01 Sep, 2008 1 commit
    • Vegard Nossum's avatar
      debugobjects: fix lockdep warning · 673d62cc
      Vegard Nossum authored
      Daniel J. Blueman reported:
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > 2.6.27-rc4-224c #1
      > -------------------------------------------------------
      > hald/4680 is trying to acquire lock:
      >  (&n->list_lock){++..}, at: [<ffffffff802bfa26>] add_partial+0x26/0x80
      > but task is already holding lock:
      >  (&obj_hash[i].lock){++..}, at: [<ffffffff8041cfdc>]
      > debug_object_free+0x5c/0x120
      We fix it by moving the actual freeing to outside the lock (the lock
      now only protects the list).
      The pool lock is also promoted to irq-safe (suggested by Dan). It's
      necessary because free_pool is now called outside the irq disabled
      region. So we need to protect against an interrupt handler which calls
      [tglx@linutronix.de: added hlist_move_list helper to avoid looping
      		     through the list twice]
      Reported-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  8. 26 Jul, 2008 1 commit
  9. 24 Jul, 2008 1 commit
  10. 18 Jun, 2008 1 commit
    • Vegard Nossum's avatar
      debugobjects: fix lockdep warning · 50db04dd
      Vegard Nossum authored
      Daniel J Blueman reported:
      | =======================================================
      | [ INFO: possible circular locking dependency detected ]
      | 2.6.26-rc5-201c #1
      | -------------------------------------------------------
      | nscd/3669 is trying to acquire lock:
      |  (&n->list_lock){.+..}, at: [<ffffffff802bab03>] deactivate_slab+0x173/0x1e0
      | but task is already holding lock:
      |  (&obj_hash[i].lock){++..}, at: [<ffffffff803fa56f>]
      | __debug_object_init+0x2f/0x350
      | which lock already depends on the new lock.
      There are two locks involved here; the first is a SLUB-local lock, and
      the second is a debugobjects-local lock. They are basically taken in two
      different orders:
      1. SLUB { debugobjects { ... } }
      2. debugobjects { SLUB { ... } }
      This patch changes pattern #2 by trying to fill the memory pool (e.g.
      the call into SLUB/kmalloc()) outside the debugobjects lock, so now the
      two patterns look like this:
      1. SLUB { debugobjects { ... } }
      2. SLUB { } debugobjects { ... }
      [ daniel.blueman@gmail.com: pool_lock needs to be taken irq safe in fill_pool ]
      Reported-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  11. 30 Apr, 2008 1 commit
    • Thomas Gleixner's avatar
      infrastructure to debug (dynamic) objects · 3ac7fe5a
      Thomas Gleixner authored
      We can see an ever repeating problem pattern with objects of any kind in the
      1) freeing of active objects
      2) reinitialization of active objects
      Both problems can be hard to debug because the crash happens at a point where
      we have no chance to decode the root cause anymore.  One problem spot are
      kernel timers, where the detection of the problem often happens in interrupt
      context and usually causes the machine to panic.
      While working on a timer related bug report I had to hack specialized code
      into the timer subsystem to get a reasonable hint for the root cause.  This
      debug hack was fine for temporary use, but far from a mergeable solution due
      to the intrusiveness into the timer code.
      The code further lacked the ability to detect and report the root cause
      instantly and keep the system operational.
      Keeping the system operational is important to get hold of the debug
      information without special debugging aids like serial consoles and special
      knowledge of the bug reporter.
      The problems described above are not restricted to timers, but timers tend to
      expose it usually in a full system crash.  Other objects are less explosive,
      but the symptoms caused by such mistakes can be even harder to debug.
      Instead of creating specialized debugging code for the timer subsystem a
      generic infrastructure is created which allows developers to verify their code
      and provides an easy to enable debug facility for users in case of trouble.
      The debugobjects core code keeps track of operations on static and dynamic
      objects by inserting them into a hashed list and sanity checking them on
      object operations and provides additional checks whenever kernel memory is
      The tracked object operations are:
      - initializing an object
      - adding an object to a subsystem list
      - deleting an object from a subsystem list
      Each operation is sanity checked before the operation is executed and the
      subsystem specific code can provide a fixup function which allows to prevent
      the damage of the operation.  When the sanity check triggers a warning message
      and a stack trace is printed.
      The list of operations can be extended if the need arises.  For now it's
      limited to the requirements of the first user (timers).
      The core code enqueues the objects into hash buckets.  The hash index is
      generated from the address of the object to simplify the lookup for the check
      on kfree/vfree.  Each bucket has it's own spinlock to avoid contention on a
      global lock.
      The debug code can be compiled in without being active.  The runtime overhead
      is minimal and could be optimized by asm alternatives.  A kernel command line
      option enables the debugging code.
      Thanks to Ingo Molnar for review, suggestions and cleanup patches.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>