linux-kernel - Re: [GIT pull] x86/pti: Preparatory changes

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 linux-cve-announce PHC
Open Source and information security mailing list archives

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

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

Message-ID: <CA+55aFzOd3j6ZUSkEwTdk85qtt1JywOtm3ZAb-qAvt8_hJ6D4A@mail.gmail.com>
Date:   Sat, 23 Dec 2017 12:12:35 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [GIT pull] x86/pti: Preparatory changes

On Sat, Dec 23, 2017 at 11:23 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Todays Advent calendar window contains twentyfour easy to digest
> patches.

Thanks, this was nice and clear and I saw nothing odd at all.

My only reaction ended up being that I don't much like how complex the
NR_CPUS config entry has become, and how confusing that is.

For example, we now have

        range 2 64 if SMP && X86_32 && X86_BIGSMP

but then we have

        default "8192" if MAXSMP

which seems to make no sense, and unlike some of the other defaults
it's not clear that those things aren't compatible. It turns out that
MAXSMP is limited to X86_64, but that's not at all obvious within that
config entry.

So I think that could be simplified by introducing separate
MAX_CONFIG_CPUS etc entries (that aren't user choice, but just codify
the limits), so that there would be some more abstraction there.

So the NR_CPUS thing would become something like

    config NR_CPUS
        int "Maximum number of CPUs" if SMP && !MAXSMP
        range MIN_CONFIG_CPUS MAX_CONFIG_CPUS
        default DEF_CONFIG_CPUS

and then have separate (simpler) config expressions for those
MIN/MAX/DEF values, rather than making it one big complex config
entry.

But that was not new complexity (just added complexity to an already
confusing case), and it's purely bike-shedding.

So I've pulled this stuff, and will push out once it passes my trivial
build test (which I obviously expect it to do, since my final build
test is much more limited than what you guys do).

                   Linus