Commit 161b6ae0 authored by Marcin Slusarz's avatar Marcin Slusarz Committed by Thomas Gleixner
Browse files

debugobjects: Fix boot crash when kmemleak and debugobjects enabled

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 <>
Cc: Catalin Marinas <>
Cc: Tejun Heo <>
Cc: Dipankar Sarma <>
Cc: Paul E. McKenney <>

Signed-off-by: default avatarThomas Gleixner <>
parent f8b7fc6b
......@@ -198,7 +198,7 @@ static void free_object(struct debug_obj *obj)
* 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);
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment