From: Linus Torvalds <torvalds@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
LKML <linux-kernel@vger.kernel.org>,
Don Zickus <dzickus@redhat.com>, Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.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 [thread overview]
Message-ID: <CA+55aFyYGHnQU-YYL7o40Z1_+-a+WND8h4i8rWFeTdHs3kax5g@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1709162342560.2105@nanos>
On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner <tglx@linutronix.de> 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
prev parent reply other threads:[~2017-09-16 22:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-14 21:47 d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208 kernel test robot
2017-09-15 7:50 ` Thomas Gleixner
2017-09-15 12:54 ` Thomas Gleixner
2017-09-15 16:24 ` Thomas Gleixner
2017-09-16 12:46 ` Fengguang Wu
2017-09-16 17:35 ` Thomas Gleixner
2017-09-16 17:55 ` Linus Torvalds
2017-09-16 18:12 ` Thomas Gleixner
2017-09-16 18:23 ` Linus Torvalds
2017-09-16 21:47 ` Thomas Gleixner
2017-09-16 22:02 ` Linus Torvalds [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+55aFyYGHnQU-YYL7o40Z1_+-a+WND8h4i8rWFeTdHs3kax5g@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).