linux-kernel - Re: [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yu+VV8xFTYRh0D0a@zn.tnic>
Date:   Sun, 7 Aug 2022 12:35:03 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Dave Hansen <dave.hansen@...el.com>, ira.weiny@...el.com,
        Rik van Riel <riel@...riel.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry

On Sun, Aug 07, 2022 at 12:02:41PM +0200, Ingo Molnar wrote:
> * Borislav Petkov <bp@...en8.de> wrote:
> > With the amount of logical cores ever increasing and how CPU packages
> > (nodes, L3 sharing, you name it) get more and more complex topology,
> > I'd say the 2 insns to show the CPU number in every exception is a good
> > thing to do.
> 
> We can show it - I'm arguing against extracting it too early, which costs

Not early - more correct. We can say which CPU executed the exception
handler *exactly*. Not which CPU executed the exception handler *maybe*.

> us 2 instructions in the exception fast path

2 insns? They don't matter at all. FWIW, they'll pull in the per-CPU
cacheline earlier which should be a net win later, for code which does
smp_processor_id().

> - while in 99.999999999% of the cases we don't use that field at all ...

See my text above about the ever-increasing complexity of CPU topology.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette