[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1454518913.6148.15.camel@gmail.com>
Date: Wed, 03 Feb 2016 18:01:53 +0100
From: Mike Galbraith <umgwanakikbuti@...il.com>
To: Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...nel.org>
Cc: Jiri Slaby <jslaby@...e.cz>, Thomas Gleixner <tglx@...utronix.de>,
Petr Mladek <pmladek@...e.com>, Jan Kara <jack@...e.cz>,
Ben Hutchings <ben@...adent.org.uk>,
Sasha Levin <sasha.levin@...cle.com>, Shaohua Li <shli@...com>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
Daniel Bilik <daniel.bilik@...system.cz>
Subject: Re: Crashes with 874bbfe600a6 in 3.18.25
On Wed, 2016-02-03 at 11:24 -0500, Tejun Heo wrote:
> On Wed, Feb 03, 2016 at 01:28:56PM +0100, Michal Hocko wrote:
> > > The CPU was 168, and that one was offlined in the meantime. So
> > > __queue_work fails at:
> > > if (!(wq->flags & WQ_UNBOUND))
> > > pwq = per_cpu_ptr(wq->cpu_pwqs, cpu);
> > > else
> > > pwq = unbound_pwq_by_node(wq, cpu_to_node(cpu));
> > > ^^^ ^^^^ NODE is -1
> > > \ pwq is NULL
> > >
> > > if (last_pool && last_pool != pwq->pool) { <--- BOOM
>
> So, the proper fix here is keeping cpu <-> node mapping stable across
> cpu on/offlining which has been being worked on for a long time now.
> The patchst is pending and it fixes other issues too.
Hm, so it's ok to queue work to an offline CPU? What happens if it
doesn't come back for an eternity or two?
-Mike
Powered by blists - more mailing lists