[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Feb 2016 15:44:24 +0100
From: Mike Galbraith <umgwanakikbuti@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: mod_delayed_work() explosion due to 874bbfe6
Hi Tejun,
I'm looking at a crash analysis that fingers 874bbfe6 as being the
culprit. (I didn't do the analysis, but it appears to be correct)
Scenario: CPU168 calls mod_delayed_work(), is taken offline before the
timer expires. Due to 874bbfe6, dwork->cpu is the now offline CPU168
vs the previous WORK_CPU_UNBOUND, timer fires on CPU131, it tries to
__queue_work() with cpu == the now offline CPU168, gets to...
} else
pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
... and goes boom.
<snippet>
crash> p numa_node | grep 168
[168]: ffff8c03fdf0e328
crash> rd ffff8c03fdf0e328
ffff8c03fdf0e328: 00000000ffffffff ........
Thus, pwq becomes 000000000. Then, as the result of reference to
pwq->pool, NULL reference occurs at (*PANIC).
</snippet>
What if anything is supposed to prevent this?
-Mike
Powered by blists - more mailing lists