20 Jun, 2011

1 commit

  • 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: [] __queue_work+0x29/0x41a
    [] queue_work_on+0x16/0x1d
    [] queue_work+0x29/0x55
    [] schedule_work+0x13/0x15
    [] free_object+0x90/0x95
    [] debug_check_no_obj_freed+0x187/0x1d3
    [] ? _raw_spin_unlock_irqrestore+0x30/0x4d
    [] ? free_object_rcu+0x68/0x6d
    [] kmem_cache_free+0x64/0x12c
    [] free_object_rcu+0x68/0x6d
    [] __rcu_process_callbacks+0x1b6/0x2d9
    ...

    because system_wq is NULL.

    Fix it by checking if workqueues susbystem was initialized before using.

    Signed-off-by: Marcin Slusarz
    Cc: Catalin Marinas
    Cc: Tejun Heo
    Cc: Dipankar Sarma
    Cc: Paul E. McKenney
    Cc: stable@kernel.org
    Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
    Signed-off-by: Thomas Gleixner

    Marcin Slusarz
     

08 Mar, 2011

1 commit

  • 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: Stanislaw Gruszka
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Stanislaw Gruszka
     

18 May, 2010

2 commits

  • * 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (24 commits)
    rcu: remove all rcu head initializations, except on_stack initializations
    rcu head introduce rcu head init on stack
    Debugobjects transition check
    rcu: fix build bug in RCU_FAST_NO_HZ builds
    rcu: RCU_FAST_NO_HZ must check RCU dyntick state
    rcu: make SRCU usable in modules
    rcu: improve the RCU CPU-stall warning documentation
    rcu: reduce the number of spurious RCU_SOFTIRQ invocations
    rcu: permit discontiguous cpu_possible_mask CPU numbering
    rcu: improve RCU CPU stall-warning messages
    rcu: print boot-time console messages if RCU configs out of ordinary
    rcu: disable CPU stall warnings upon panic
    rcu: enable CPU_STALL_VERBOSE by default
    rcu: slim down rcutiny by removing rcu_scheduler_active and friends
    rcu: refactor RCU's context-switch handling
    rcu: rename rcutiny rcu_ctrlblk to rcu_sched_ctrlblk
    rcu: shrink rcutiny by making synchronize_rcu_bh() be inline
    rcu: fix now-bogus rcu_scheduler_active comments.
    rcu: Fix bogus CONFIG_PROVE_LOCKING in comments to reflect reality.
    rcu: ignore offline CPUs in last non-dyntick-idle CPU check
    ...

    Linus Torvalds
     
  • …/kernel/git/tip/linux-2.6-tip

    * 'core-debugobjects-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    debugobjects: Section mismatch cleanup

    Linus Torvalds
     

11 May, 2010

1 commit

  • 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: Mathieu Desnoyers
    Reviewed-by: Thomas Gleixner
    Acked-by: David S. Miller
    CC: "Paul E. McKenney"
    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
    Signed-off-by: Paul E. McKenney

    Mathieu Desnoyers
     

30 Mar, 2010

1 commit

  • …it 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: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

27 Mar, 2010

1 commit

  • 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: Henrik Kretzschmar
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Henrik Kretzschmar
     

15 Dec, 2009

1 commit


12 Oct, 2009

1 commit


17 Mar, 2009

2 commits

  • 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: Thomas Gleixner
    LKML-Reference:

    Thomas Gleixner
     
  • 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: Thomas Gleixner
    LKML-Reference:

    Thomas Gleixner
     

02 Mar, 2009

1 commit

  • While trying to debug why my Atom netbook is falling over booting
    rawhide debug-enabled kernels, I stumbled across the fact that we've
    been enabling object debugging by default. However, once you default it
    to on, you've got no way to turn it back off again at runtime.

    Add a boolean toggle to turn it off. I would just make it an int
    module_param, however people may already expect the boolean enable
    behaviour, so just add an analogue for disabling.

    Signed-off-by: Kyle McMartin
    Signed-off-by: Ingo Molnar

    Kyle McMartin
     

26 Nov, 2008

1 commit

  • 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: Ingo Molnar

    Ingo Molnar
     

01 Sep, 2008

1 commit

  • 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: [] add_partial+0x26/0x80
    >
    > but task is already holding lock:
    > (&obj_hash[i].lock){++..}, at: []
    > 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: Daniel J Blueman
    Signed-off-by: Vegard Nossum
    Signed-off-by: Thomas Gleixner

    Vegard Nossum
     

27 Jul, 2008

1 commit

  • Use WARN() instead of a printk+WARN_ON() pair; this way the message becomes
    part of the warning section for better reporting/collection. In addition, one
    of the if() clauses collapes into the WARN() entirely now.

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

    Arjan van de Ven
     

25 Jul, 2008

1 commit

  • lib/debugobjects.c has a function to test if an object is on the stack.
    The block layer and ide needs it (they need to avoid DMA from/to stack
    buffers). This patch moves the function to include/linux/sched.h so that
    everyone can use it.

    lib/debugobjects.c uses current->stack but this patch uses a
    task_stack_page() accessor, which is a preferable way to access the stack.

    Signed-off-by: FUJITA Tomonori
    Cc: Christoph Lameter
    Cc: Andy Whitcroft
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    FUJITA Tomonori
     

18 Jun, 2008

1 commit

  • 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: [] deactivate_slab+0x173/0x1e0
    |
    | but task is already holding lock:
    | (&obj_hash[i].lock){++..}, at: []
    | __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: Daniel J Blueman
    Signed-off-by: Vegard Nossum
    Signed-off-by: Thomas Gleixner

    Vegard Nossum
     

30 Apr, 2008

1 commit

  • 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: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Cc: Greg KH
    Cc: Randy Dunlap
    Cc: Kay Sievers
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner