linux-kernel - Re: [PATCH 05/11] smp: Enable preemption early in smp_call_function_many

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: <fcea1d58-74c5-41ac-9880-48e4202f78af@bytedance.com>
Date: Fri, 6 Feb 2026 19:45:14 +0800
From: "Chuyi Zhou" <zhouchuyi@...edance.com>
To: "Peter Zijlstra" <peterz@...radead.org>
Cc: <tglx@...utronix.de>, <mingo@...hat.com>, <luto@...nel.org>, 
	<paulmck@...nel.org>, <muchun.song@...ux.dev>, <bp@...en8.de>, 
	<dave.hansen@...ux.intel.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/11] smp: Enable preemption early in smp_call_function_many_cond

Hello,

在 2026/2/6 17:47, Peter Zijlstra 写道:
> On Fri, Feb 06, 2026 at 04:43:48PM +0800, Chuyi Zhou wrote:
> 
>> However, 99% of callers have preemption disabled, some of them even
>> invoking it within spin_locks (for example, we might trigger a TLB flush
>> while holding pte spinlocks).
> 
> Then 99% of the callers don't benefit from this and won't see your
> latency reduction -- and will be broken on PREEMPT_RT, no?

Once we make the preemption logic self-contained within smp_call, the 
disabling of preemption by most callers becomes unnecessary and can 
therefore be removed. We can preserve the few instances where it is 
still meaningful or apply special optimizations to them, much like the 
subsequent patch does for arch_tlbbatch_flush/flush_tlb_mm_range.

Consequently, the vast majority of callers stand to benefit. For the RT 
kernel, this optimization provides additional benefits when smp_call is 
invoked within spinlocks, as it reduces the length of non-preemptible 
critical sections.

We can invoke alloc_cpumask_var only when CONFIG_CPUMASK_OFFSTACK is 
disabled, thereby avoiding broken on RT.

However, using cpus_read_lock requires us to absolutely guarantee that 
the current context is sleepable, which is difficult to ensure.