From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751347AbdIPVrV (ORCPT ); Sat, 16 Sep 2017 17:47:21 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:48083 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751288AbdIPVrU (ORCPT ); Sat, 16 Sep 2017 17:47:20 -0400 Date: Sat, 16 Sep 2017 23:47:10 +0200 (CEST) From: Thomas Gleixner To: Linus Torvalds cc: Fengguang Wu , LKP , LKML , Don Zickus , Ingo Molnar , Peter Zijlstra Subject: Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208 In-Reply-To: Message-ID: References: <59baf8db.Rfy+1ZsQ37PfCiRH%fengguang.wu@intel.com> <20170916124652.jpjoj4zgosw2af2z@wfg-t540p.sh.intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) 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 Sat, 16 Sep 2017, Linus Torvalds wrote: > On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner wrote: > >> > >> So I suspect your perf fix is the right one, and maybe we could/should > >> just make people more aware of the empty cpumask issue with UP. > > > > Right, I just got a bit frightened as I really was not aware about that > > 'opmtimization' which means that so far I just was lucky not to trip over > > it. > > Yeah. I can't say that I was really aware of it either in a every-day > kind of way, it was only when I looked it up that I went "Oh, right, > that's what we did". > > So it's subtle and unexpected, and the saving grace is basically that > empty cpumasks are really the exception to begin with. They basically > don't happen in normal situations. Yes and no. We get more code which uses cpumasks to store state, just like I did, and while a lot of the cpumask functions just work as expected a subset including for_each_cpu does not. That's confusing at best and I rather avoid the hard to debug issues on UP, which probably gets less testing anyway. Thanks, tglx