[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160206130742.GA17482@khazad-dum.debian.net>
Date: Sat, 6 Feb 2016 11:07:42 -0200
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Tejun Heo <tj@...nel.org>
Cc: Mike Galbraith <umgwanakikbuti@...il.com>,
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 Fri, 05 Feb 2016, Tejun Heo wrote:
> On Fri, Feb 05, 2016 at 09:59:49PM +0100, Mike Galbraith wrote:
> > On Fri, 2016-02-05 at 15:54 -0500, Tejun Heo wrote:
> >
> > > What are you suggesting?
> >
> > That 874bbfe6 should die.
>
> Yeah, it's gonna be killed. The commit is there because the behavior
> change broke things. We don't want to guarantee it but have been and
> can't change it right away just because we don't like it when things
> may break from it. The plan is to implement a debug option to force
> workqueue to always execute these work items on a foreign cpu to weed
> out breakages.
Is there a path to filter down sane behavior (whichever one it might be) to
the affected stable/LTS kernels?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Powered by blists - more mailing lists