• Marcin Slusarz's avatar
    debugobjects: Fix boot crash when kmemleak and debugobjects enabled · 161b6ae0
    Marcin Slusarz authored
    Order of initialization look like this:
    ...(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>