Re: Crashes with 874bbfe600a6 in 3.18.25
From: Michal Hocko <mhocko@kernel.org>
Date: 2016-02-04 07:40:55
Also in:
lkml
On Thu 04-02-16 07:37:23, Michal Hocko wrote:
quoted hunk ↗ jump to hunk
On Wed 03-02-16 11:59:01, Tejun Heo wrote:quoted
On Wed, Feb 03, 2016 at 05:48:52PM +0100, Michal Hocko wrote:[...]quoted
quoted
anything and add_timer_on also for WORK_CPU_UNBOUND is really required then we should at least preserve WORK_CPU_UNBOUND in dwork->cpu so that __queue_work can actually move on to the local CPU properly and handle the offline cpu properly.delayed_work->cpu is determined on queueing time. Dealing with offlined cpus at execution is completley fine. There's no need to "preserve" anything.I've seen you have posted a fix in the mean time but just for my understading. Why the following is not an appropriate fix?diff --git a/kernel/workqueue.c b/kernel/workqueue.c index c579dbab2e36..52bb11cf20d1 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c@@ -1459,9 +1459,9 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq, dwork->wq = wq; /* timer isn't guaranteed to run in this cpu, record earlier */ + dwork->cpu = cpu; if (cpu == WORK_CPU_UNBOUND) cpu = raw_smp_processor_id(); - dwork->cpu = cpu; timer->expires = jiffies + delay; add_timer_on(timer, cpu);
Ok, so after some more thinking about that, this won't really help for memory less CPU which would still have NUMA_NO_NODE associated with it AFAIU. So this is definitely better to be handled at unbound_pwq_by_node level. -- Michal Hocko SUSE Labs