From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352AbdIPWCK (ORCPT ); Sat, 16 Sep 2017 18:02:10 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:33993 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751288AbdIPWCJ (ORCPT ); Sat, 16 Sep 2017 18:02:09 -0400 X-Google-Smtp-Source: AOwi7QBEsNX/s+WPmoGio3q8i/LKfQe8rEdbTOEoob1/EcLmhhubuNwGhcRkidtBeTnBgbthW5j7UY8eKEHVJAF8w2Y= MIME-Version: 1.0 In-Reply-To: References: <59baf8db.Rfy+1ZsQ37PfCiRH%fengguang.wu@intel.com> <20170916124652.jpjoj4zgosw2af2z@wfg-t540p.sh.intel.com> From: Linus Torvalds Date: Sat, 16 Sep 2017 15:02:07 -0700 X-Google-Sender-Auth: 728g9jqSfvnaSXmlYVxIPTOXEW0 Message-ID: Subject: Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208 To: Thomas Gleixner Cc: Fengguang Wu , LKP , LKML , Don Zickus , Ingo Molnar , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner wrote: > > 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. I certainly agree that the UP situation has changed over the years. But I'd hate to make all those loops etc (that the compiler can currently almost always trivially turn into trivial unconditional non-loops) be sometrhing that ends up testing a bit and having a conditional. I wonder if we could have some checking mode or something that at least makes those things easier to notice. But I don't see a sane way to do that statically. Looking at that patch of yours, it seems to depend on 'watchdog_allowed_mask' having just been initialized as empty, which is the case that doesn't work well for UP. So there isn't even any code to trigger on, it would have to be some added warning to all users that does something along the lines of 'WARN_ON_ONCE(cpumask != 1)' .. and then hardly anybody would run that configuration anyway. Annoying. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5703916032268461456==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208 Date: Sat, 16 Sep 2017 15:02:07 -0700 Message-ID: In-Reply-To: List-Id: --===============5703916032268461456== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner wro= te: > > 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. I certainly agree that the UP situation has changed over the years. But I'd hate to make all those loops etc (that the compiler can currently almost always trivially turn into trivial unconditional non-loops) be sometrhing that ends up testing a bit and having a conditional. I wonder if we could have some checking mode or something that at least makes those things easier to notice. But I don't see a sane way to do that statically. Looking at that patch of yours, it seems to depend on 'watchdog_allowed_mask' having just been initialized as empty, which is the case that doesn't work well for UP. So there isn't even any code to trigger on, it would have to be some added warning to all users that does something along the lines of 'WARN_ON_ONCE(cpumask !=3D 1)' .. and then hardly anybody would run that configuration anyway. Annoying. Linus --===============5703916032268461456==--