linux-kernel - Re: [RFC PATCH v7 30/31] x86/mm, mm/vmalloc: Defer kernel TLB flush IPIs under CONFIG_COALESCE

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: <292ebf6a-4a7a-43b2-a670-ea53728f2c06@app.fastmail.com>
Date: Wed, 19 Nov 2025 10:33:35 -0800
From: "Andy Lutomirski" <luto@...nel.org>
To: "Dave Hansen" <dave.hansen@...el.com>,
 "Valentin Schneider" <vschneid@...hat.com>,
 "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 linux-mm@...ck.org, rcu@...r.kernel.org,
 "the arch/x86 maintainers" <x86@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, loongarch@...ts.linux.dev,
 linux-riscv@...ts.infradead.org, linux-arch@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org
Cc: "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>,
 "Peter Zijlstra (Intel)" <peterz@...radead.org>,
 "Arnaldo Carvalho de Melo" <acme@...nel.org>,
 "Josh Poimboeuf" <jpoimboe@...nel.org>,
 "Paolo Bonzini" <pbonzini@...hat.com>, "Arnd Bergmann" <arnd@...db.de>,
 "Frederic Weisbecker" <frederic@...nel.org>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 "Jason Baron" <jbaron@...mai.com>,
 "Steven Rostedt" <rostedt@...dmis.org>,
 "Ard Biesheuvel" <ardb@...nel.org>,
 "Sami Tolvanen" <samitolvanen@...gle.com>,
 "David S. Miller" <davem@...emloft.net>,
 "Neeraj Upadhyay" <neeraj.upadhyay@...nel.org>,
 "Joel Fernandes" <joelagnelf@...dia.com>,
 "Josh Triplett" <josh@...htriplett.org>,
 "Boqun Feng" <boqun.feng@...il.com>,
 "Uladzislau Rezki" <urezki@...il.com>,
 "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com>,
 "Mel Gorman" <mgorman@...e.de>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Masahiro Yamada" <masahiroy@...nel.org>,
 "Han Shen" <shenhan@...gle.com>, "Rik van Riel" <riel@...riel.com>,
 "Jann Horn" <jannh@...gle.com>,
 "Dan Carpenter" <dan.carpenter@...aro.org>,
 "Oleg Nesterov" <oleg@...hat.com>, "Juri Lelli" <juri.lelli@...hat.com>,
 "Clark Williams" <williams@...hat.com>,
 "Yair Podemsky" <ypodemsk@...hat.com>,
 "Marcelo Tosatti" <mtosatti@...hat.com>,
 "Daniel Wagner" <dwagner@...e.de>, "Petr Tesarik" <ptesarik@...e.com>,
 "Shrikanth Hegde" <sshegde@...ux.ibm.com>
Subject: Re: [RFC PATCH v7 30/31] x86/mm, mm/vmalloc: Defer kernel TLB flush IPIs under
 CONFIG_COALESCE_TLBI=y

On Wed, Nov 19, 2025, at 10:31 AM, Dave Hansen wrote:
> On 11/14/25 07:14, Valentin Schneider wrote:
>> +static bool flush_tlb_kernel_cond(int cpu, void *info)
>> +{
>> +	return housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE) ||
>> +	       per_cpu(kernel_cr3_loaded, cpu);
>> +}
>
> Is it OK that 'kernel_cr3_loaded' can be be stale? Since it's not part
> of the instruction that actually sets CR3, there's a window between when
> 'kernel_cr3_loaded' is set (or cleared) and CR3 is actually written.
>
> Is that OK?
>
> It seems like it could lead to both unnecessary IPIs being sent and for
> IPIs to be missed.

I read the code earlier today and I *think* it’s maybe okay. It’s quite confusing that this thing is split among multiple patches, and the memory ordering issues need comments.

The fact that the big flush is basically unconditional at this point helps. The fact that it’s tangled up with CR3 even though the current implementation has nothing to do with CR3 does not help.

I’m kind of with dhansen though — the fact that the implementation is so nasty coupled with the fact that modern CPUs can do this in hardware makes the whole thing kind of unpalatable.

>
> I still _really_ wish folks would be willing to get newer CPUs to get
> this behavior rather than going through all this complexity. RAR in
> particular was *specifically* designed to keep TLB flushing IPIs from
> blipping userspace for too long.