From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966041AbcBCTHR (ORCPT ); Wed, 3 Feb 2016 14:07:17 -0500 Received: from www.linutronix.de ([62.245.132.108]:60710 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964955AbcBCTHO (ORCPT ); Wed, 3 Feb 2016 14:07:14 -0500 Date: Wed, 3 Feb 2016 20:05:57 +0100 (CET) From: Thomas Gleixner To: Tejun Heo cc: Michal Hocko , Jiri Slaby , 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 In-Reply-To: <20160203190159.GM14091@mtj.duckdns.org> Message-ID: References: <20160122160903.GH32380@htj.duckdns.org> <1453515623.3734.156.camel@decadent.org.uk> <20160126093400.GV24938@quack.suse.cz> <20160126111438.GA731@pathway.suse.cz> <56B1C9E4.4020400@suse.cz> <20160203122855.GB6762@dhcp22.suse.cz> <20160203162441.GE14091@mtj.duckdns.org> <20160203190159.GM14091@mtj.duckdns.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 3 Feb 2016, Tejun Heo wrote: > On Wed, Feb 03, 2016 at 07:46:11PM +0100, Thomas Gleixner wrote: > > > > So I think 874bbfe600a6 is really bogus. It should be reverted. We > > > > already have a proper fix for vmstat 176bed1de5bf ("vmstat: explicitly > > > > schedule per-cpu work on the CPU we need it to run on"). This which > > > > should be used for the stable trees as a replacement. > > > > > > It's not bogus. We can't flip a property that has been guaranteed > > > without any provision for verification. Why do you think vmstat blow > > > up in the first place? vmstat would be the canary case as it runs > > > frequently on all systems. It's exactly the sign that we can't break > > > this guarantee willy-nilly. > > > > You're in complete failure denial mode once again. > > Well, you're in an unnecessary escalation mode as usual. Was the > attitude really necessary? Chill out and read the thread again. > Michal is saying the dwork->cpu assignment was bogus and I was > refuting that. Right, but at the same time you could have admitted, that the current state is buggy and needs a sanity check in unbound_pwq_by_node(). > Michal brought it up here but there's a different thread where Mike > reported NUMA_NO_NODE issue and I already posted the fix. > > http://lkml.kernel.org/g/20160203185425.GK14091@mtj.duckdns.org 5 minute ago w/o cc'ing the people who participated in that discussion. Thanks, tglx