[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160203170652.GI14091@mtj.duckdns.org>
Date: Wed, 3 Feb 2016 12:06:52 -0500
From: Tejun Heo <tj@...nel.org>
To: Mike Galbraith <umgwanakikbuti@...il.com>
Cc: Michal Hocko <mhocko@...nel.org>, 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, Feb 03, 2016 at 06:01:53PM +0100, Mike Galbraith wrote:
> 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?
Right now, it just loses affinity. A more interesting case is a cpu
going offline whlie work items bound to the cpu are still running and
the root problem is that we've never distinguished between affinity
for correctness and optimization and thus can't flush or warn on the
stagglers. The plan is to ensure that all correctness users specify
the CPU explicitly. Once we're there, we can warn on illegal usages.
Thanks.
--
tejun
Powered by blists - more mailing lists