linux-kernel - Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 16 Sep 2017 23:47:10 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Fengguang Wu <fengguang.wu@...el.com>, LKP <lkp@...org>,
        LKML <linux-kernel@...r.kernel.org>,
        Don Zickus <dzickus@...hat.com>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG:
 unable to handle kernel NULL pointer dereference at 0000000000000208

On Sat, 16 Sep 2017, Linus Torvalds wrote:
> On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner <tglx@...utronix.de> 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