From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbcBFNHt (ORCPT ); Sat, 6 Feb 2016 08:07:49 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40135 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbcBFNHq (ORCPT ); Sat, 6 Feb 2016 08:07:46 -0500 X-Sasl-enc: u4vE5mB6M6LsOP9nDi+KCzm/11U113oygDS6HktIN34y 1454764065 Date: Sat, 6 Feb 2016 11:07:42 -0200 From: Henrique de Moraes Holschuh To: Tejun Heo Cc: Mike Galbraith , Michal Hocko , Jiri Slaby , Thomas Gleixner , Petr Mladek , Jan Kara , Ben Hutchings , Sasha Levin , Shaohua Li , LKML , stable@vger.kernel.org, Daniel Bilik Subject: Re: Crashes with 874bbfe600a6 in 3.18.25 Message-ID: <20160206130742.GA17482@khazad-dum.debian.net> References: <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> <20160205210606.GH4401@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160205210606.GH4401@htj.duckdns.org> X-GPG-Fingerprint1: 4096R/39CB4807 C467 A717 507B BAFE D3C1 6092 0BD9 E811 39CB 4807 X-GPG-Fingerprint2: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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