[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwQDMuieCNEh86GXKoCjj+B6aZBTt--y7sUCtqzLkPf5Q@mail.gmail.com>
Date: Tue, 9 Feb 2016 08:39:15 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mike Galbraith <umgwanakikbuti@...il.com>
Cc: Tejun Heo <tj@...nel.org>, 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 <stable@...r.kernel.org>,
Daniel Bilik <daniel.bilik@...system.cz>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: Crashes with 874bbfe600a6 in 3.18.25
On Tue, Feb 9, 2016 at 7:31 AM, Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> On Fri, 2016-02-05 at 16:06 -0500, Tejun Heo wrote:
>> >
>> > 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.
>
> A niggling question remaining is when is it gonna be killed?
It probably should be killed sooner rather than later.
Just document that if you need something to run on a _particular_ cpu,
you need to use "schedule_delayed_work_on()" and "add_timer_on()".
The proper fix was 176bed1de5bf, and 874bbfe6 was just wrong.
Linus
Powered by blists - more mailing lists