From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757210AbcBEVGQ (ORCPT <rfc822;w@1wt.eu>);
	Fri, 5 Feb 2016 16:06:16 -0500
Received: from mail-yw0-f173.google.com ([209.85.161.173]:34909 "EHLO
	mail-yw0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757161AbcBEVGK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 5 Feb 2016 16:06:10 -0500
Date: Fri, 5 Feb 2016 16:06:06 -0500
From: Tejun Heo <tj@kernel.org>
To: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>, Jiri Slaby <jslaby@suse.cz>,
        Thomas Gleixner <tglx@linutronix.de>, Petr Mladek <pmladek@suse.com>,
        Jan Kara <jack@suse.cz>, Ben Hutchings <ben@decadent.org.uk>,
        Sasha Levin <sasha.levin@oracle.com>, Shaohua Li <shli@fb.com>,
        LKML <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
        Daniel Bilik <daniel.bilik@neosystem.cz>
Subject: Re: Crashes with 874bbfe600a6 in 3.18.25
Message-ID: <20160205210606.GH4401@htj.duckdns.org>
References: <56B1C9E4.4020400@suse.cz>
 <20160203122855.GB6762@dhcp22.suse.cz>
 <20160203162441.GE14091@mtj.duckdns.org>
 <1454518913.6148.15.camel@gmail.com>
 <20160203170652.GI14091@mtj.duckdns.org>
 <1454551217.3677.27.camel@gmail.com>
 <20160205164923.GC4401@htj.duckdns.org>
 <1454705231.3819.151.camel@gmail.com>
 <20160205205456.GG4401@htj.duckdns.org>
 <1454705989.3819.158.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1454705989.3819.158.camel@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Thanks.

-- 
tejun