1. 15 Sep, 2018 1 commit
  2. 01 Dec, 2016 1 commit
  3. 20 May, 2016 3 commits
    • Du, Changbin's avatar
      debugobjects: insulate non-fixup logic related to static obj from fixup callbacks · b9fdac7f
      Du, Changbin authored
      When activating a static object we need make sure that the object is
      tracked in the object tracker.  If it is a non-static object then the
      activation is illegal.
      
      In previous implementation, each subsystem need take care of this in
      their fixup callbacks.  Actually we can put it into debugobjects core.
      Thus we can save duplicated code, and have *pure* fixup callbacks.
      
      To achieve this, a new callback "is_static_object" is introduced to let
      the type specific code decide whether a object is static or not.  If
      yes, we take it into object tracker, otherwise give warning and invoke
      fixup callback.
      
      This change has paassed debugobjects selftest, and I also do some test
      with all debugobjects supports enabled.
      
      At last, I have a concern about the fixups that can it change the object
      which is in incorrect state on fixup? Because the 'addr' may not point
      to any valid object if a non-static object is not tracked.  Then Change
      such object can overwrite someone's memory and cause unexpected
      behaviour.  For example, the timer_fixup_activate bind timer to function
      stub_timer.
      
      Link: http://lkml.kernel.org/r/1462576157-14539-1-git-send-email-changbin.du@intel.com
      [changbin.du@intel.com: improve code comments where invoke the new is_static_object callback]
        Link: http://lkml.kernel.org/r/1462777431-8171-1-git-send-email-changbin.du@intel.com
      
      Signed-off-by: default avatarDu, Changbin <changbin.du@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Triplett <josh@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b9fdac7f
    • Du, Changbin's avatar
      debugobjects: correct the usage of fixup call results · e7a8e78b
      Du, Changbin authored
      
      
      If debug_object_fixup() return non-zero when problem has been fixed.
      But the code got it backwards, it taks 0 as fixup successfully.  So fix
      it.
      Signed-off-by: default avatarDu, Changbin <changbin.du@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Triplett <josh@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e7a8e78b
    • Du, Changbin's avatar
      debugobjects: make fixup functions return bool instead of int · b1e4d9d8
      Du, Changbin authored
      
      
      I am going to introduce debugobjects infrastructure to USB subsystem.
      But before this, I found the code of debugobjects could be improved.
      This patchset will make fixup functions return bool type instead of int.
      Because fixup only need report success or no.  boolean is the 'real'
      type.
      
      This patch (of 7):
      
      The object debugging infrastructure core provides some fixup callbacks
      for the subsystem who use it.  These callbacks are called from the debug
      code whenever a problem in debug_object_init is detected.  And
      debugobjects core suppose them returns 1 when the fixup was successful,
      otherwise 0.  So the return type is boolean.
      
      A bad thing is that debug_object_fixup use the return value for
      arithmetic operation.  It confused me that what is the reall return
      type.
      
      Reading over the whole code, I found some place do use the return value
      incorrectly(see next patch).  So why use bool type instead?
      Signed-off-by: default avatarDu, Changbin <changbin.du@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Triplett <josh@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b1e4d9d8
  4. 27 Jan, 2016 1 commit
  5. 04 Jun, 2014 3 commits
  6. 13 Nov, 2013 1 commit
  7. 19 Aug, 2013 1 commit
    • Paul E. McKenney's avatar
      debugobjects: Make debug_object_activate() return status · b778ae25
      Paul E. McKenney authored
      
      
      In order to better respond to things like duplicate invocations
      of call_rcu(), RCU needs to see the status of a call to
      debug_object_activate().  This would allow RCU to leak the callback in
      order to avoid adding freelist-reuse mischief to the duplicate invoations.
      This commit therefore makes debug_object_activate() return status,
      zero for success and -EINVAL for failure.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Cc: Davidlohr Bueso <davidlohr.bueso@hp.com>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      b778ae25
  8. 28 Feb, 2013 1 commit
    • Sasha Levin's avatar
      hlist: drop the node parameter from iterators · b67bfe0d
      Sasha Levin authored
      
      
      I'm not sure why, but the hlist for each entry iterators were conceived
      
              list_for_each_entry(pos, head, member)
      
      The hlist ones were greedy and wanted an extra parameter:
      
              hlist_for_each_entry(tpos, pos, head, member)
      
      Why did they need an extra pos parameter? I'm not quite sure. Not only
      they don't really need it, it also prevents the iterator from looking
      exactly like the list iterator, which is unfortunate.
      
      Besides the semantic patch, there was some manual work required:
      
       - Fix up the actual hlist iterators in linux/list.h
       - Fix up the declaration of other iterators based on the hlist ones.
       - A very small amount of places were using the 'node' parameter, this
       was modified to use 'obj->member' instead.
       - Coccinelle didn't handle the hlist_for_each_entry_safe iterator
       properly, so those had to be fixed up manually.
      
      The semantic patch which is mostly the work of Peter Senna Tschudin is here:
      
      @@
      iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
      
      type T;
      expression a,c,d,e;
      identifier b;
      statement S;
      @@
      
      -T b;
          <+... when != b
      (
      hlist_for_each_entry(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue(a,
      - b,
      c) S
      |
      hlist_for_each_entry_from(a,
      - b,
      c) S
      |
      hlist_for_each_entry_rcu(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_rcu_bh(a,
      - b,
      c, d) S
      |
      hlist_for_each_entry_continue_rcu_bh(a,
      - b,
      c) S
      |
      for_each_busy_worker(a, c,
      - b,
      d) S
      |
      ax25_uid_for_each(a,
      - b,
      c) S
      |
      ax25_for_each(a,
      - b,
      c) S
      |
      inet_bind_bucket_for_each(a,
      - b,
      c) S
      |
      sctp_for_each_hentry(a,
      - b,
      c) S
      |
      sk_for_each(a,
      - b,
      c) S
      |
      sk_for_each_rcu(a,
      - b,
      c) S
      |
      sk_for_each_from
      -(a, b)
      +(a)
      S
      + sk_for_each_from(a) S
      |
      sk_for_each_safe(a,
      - b,
      c, d) S
      |
      sk_for_each_bound(a,
      - b,
      c) S
      |
      hlist_for_each_entry_safe(a,
      - b,
      c, d, e) S
      |
      hlist_for_each_entry_continue_rcu(a,
      - b,
      c) S
      |
      nr_neigh_for_each(a,
      - b,
      c) S
      |
      nr_neigh_for_each_safe(a,
      - b,
      c, d) S
      |
      nr_node_for_each(a,
      - b,
      c) S
      |
      nr_node_for_each_safe(a,
      - b,
      c, d) S
      |
      - for_each_gfn_sp(a, c, d, b) S
      + for_each_gfn_sp(a, c, d) S
      |
      - for_each_gfn_indirect_valid_sp(a, c, d, b) S
      + for_each_gfn_indirect_valid_sp(a, c, d) S
      |
      for_each_host(a,
      - b,
      c) S
      |
      for_each_host_safe(a,
      - b,
      c, d) S
      |
      for_each_mesh_entry(a,
      - b,
      c, d) S
      )
          ...+>
      
      [akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
      [akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
      [akpm@linux-foundation.org: checkpatch fixes]
      [akpm@linux-foundation.org: fix warnings]
      [akpm@linux-foudnation.org: redo intrusive kvm changes]
      Tested-by: default avatarPeter Senna Tschudin <peter.senna@gmail.com>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Cc: Wu Fengguang <fengguang.wu@intel.com>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b67bfe0d
  9. 18 Apr, 2012 1 commit
  10. 11 Apr, 2012 2 commits
  11. 05 Mar, 2012 1 commit
  12. 23 Nov, 2011 2 commits
  13. 20 Jun, 2011 1 commit
    • Marcin Slusarz's avatar
      debugobjects: Fix boot crash when kmemleak and debugobjects enabled · 161b6ae0
      Marcin Slusarz authored
      
      
      Order of initialization look like this:
      ...
      debugobjects
      kmemleak
      ...(lots of other subsystems)...
      workqueues (through early initcall)
      ...
      
      debugobjects use schedule_work for batch freeing of its data and kmemleak
      heavily use debugobjects, so when it comes to freeing and workqueues were
      not initialized yet, kernel crashes:
      
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810854d1>] __queue_work+0x29/0x41a
       [<ffffffff81085910>] queue_work_on+0x16/0x1d
       [<ffffffff81085abc>] queue_work+0x29/0x55
       [<ffffffff81085afb>] schedule_work+0x13/0x15
       [<ffffffff81242de1>] free_object+0x90/0x95
       [<ffffffff81242f6d>] debug_check_no_obj_freed+0x187/0x1d3
       [<ffffffff814b6504>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
       [<ffffffff8110bd14>] ? free_object_rcu+0x68/0x6d
       [<ffffffff8110890c>] kmem_cache_free+0x64/0x12c
       [<ffffffff8110bd14>] free_object_rcu+0x68/0x6d
       [<ffffffff810b58bc>] __rcu_process_callbacks+0x1b6/0x2d9
      ...
      
      because system_wq is NULL.
      
      Fix it by checking if workqueues susbystem was initialized before using.
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      161b6ae0
  14. 08 Mar, 2011 1 commit
    • Stanislaw Gruszka's avatar
      debugobjects: Add hint for better object identification · 99777288
      Stanislaw Gruszka authored
      
      
      In complex subsystems like mac80211 structures can contain several
      timers and work structs, so identifying a specific instance from the
      call trace and object type output of debugobjects can be hard.
      
      Allow the subsystems which support debugobjects to provide a hint
      function. This function returns a pointer to a kernel address
      (preferrably the objects callback function) which is printed along
      with the debugobjects type.
      
      Add hint methods for timer_list, work_struct and hrtimer.
      
      [ tglx: Massaged changelog, made it compile ]
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      LKML-Reference: <20110307085809.GA9334@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      99777288
  15. 10 May, 2010 1 commit
    • Mathieu Desnoyers's avatar
      Debugobjects transition check · a5d8e467
      Mathieu Desnoyers authored
      
      
      Implement a basic state machine checker in the debugobjects.
      
      This state machine checker detects races and inconsistencies within the "active"
      life of a debugobject. The checker only keeps track of the current state; all
      the state machine logic is kept at the object instance level.
      
      The checker works by adding a supplementary "unsigned int astate" field to the
      debug_obj structure. It keeps track of the current "active state" of the object.
      
      The only constraints that are imposed on the states by the debugobjects system
      is that:
      
      - activation of an object sets the current active state to 0,
      - deactivation of an object expects the current active state to be 0.
      
      For the rest of the states, the state mapping is determined by the specific
      object instance. Therefore, the logic keeping track of the state machine is
      within the specialized instance, without any need to know about it at the
      debugobject level.
      
      The current object active state is changed by calling:
      
      debug_object_active_state(addr, descr, expect, next)
      
      where "expect" is the expected state and "next" is the next state to move to if
      the expected state is found. A warning is generated if the expected is not
      found.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      CC: akpm@linux-foundation.org
      CC: mingo@elte.hu
      CC: laijs@cn.fujitsu.com
      CC: dipankar@in.ibm.com
      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
      CC: eric.dumazet@gmail.com
      CC: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      a5d8e467
  16. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  17. 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>
      1fb2f77c
  18. 14 Dec, 2009 1 commit
  19. 11 Oct, 2009 1 commit
  20. 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>
      337fff8b
    • 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
      debug_check_no_obj_freed().
      
      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>
      1be1cb7b
  21. 02 Mar, 2009 1 commit
  22. 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>
      3ae70205
  23. 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
      debug_object_init().
      
      [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>
      673d62cc
  24. 26 Jul, 2008 1 commit
  25. 24 Jul, 2008 1 commit
  26. 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>
      50db04dd
  27. 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
      kernel:
      
      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
      freed.
      
      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>
      3ac7fe5a