commit
161b6ae0e067e421b20bb35caf66bdb405c929ac upstream.
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: Marcin 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>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* initialized:
*/
if (obj_pool_free > ODEBUG_POOL_SIZE && obj_cache)
- sched = !work_pending(&debug_obj_work);
+ sched = keventd_up() && !work_pending(&debug_obj_work);
hlist_add_head(&obj->node, &obj_pool);
obj_pool_free++;
obj_pool_used--;