linux-kernel - Re: [PATCH] x86/mm: Inline mm_mangle_tif_spec_bits() and l1d_flush

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: <23ac331b-1492-480c-9207-21d631b07caf@intel.com>
Date: Mon, 23 Jun 2025 10:55:03 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Khalid Ali <khaliidcaliy@...il.com>, dave.hansen@...ux.intel.com,
 luto@...nel.org, peterz@...radead.org, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de
Cc: x86@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/mm: Inline mm_mangle_tif_spec_bits() and
 l1d_flush_evaluate()

On 6/23/25 10:43, Khalid Ali wrote:
> These two functions are called from performance critical path like context
> switch.
> 
> So make sure the compiler optimizes out by inlining. This won't result
> increase of size because these functions only have one call site.

Khalid,

The compiler is currently given the latitude to choose an inlining
strategy for these functions. Generally, I'd assume that it's doing
something sane unless there's a specific compiler making suboptimal
decisions.

Do you have some evidence that compilers are doing the wrong thing?
Perhaps some generated code that looks wrong to you or some evidence
that the proposed change improves performance?