linux-kernel - Re: [PATCH] x86/aperfmperf: Don't disable scheduler APERF/MPERF on bad samples

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: <20251205161052.GH2528459@noisy.programming.kicks-ass.net>
Date: Fri, 5 Dec 2025 17:10:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, ggherdovich@...e.cz,
	rafael.j.wysocki@...el.com
Subject: Re: [PATCH] x86/aperfmperf: Don't disable scheduler APERF/MPERF on
 bad samples

On Thu, Dec 04, 2025 at 10:09:14AM -0800, Andi Kleen wrote:
> The APERF and MPERF MSRs get read together and the ratio
> between the two is used to scale the scheduler capacity with frequency.
> 
> Since e2b0d619b400 when there is ever an over/underflow of
> the APERF/MPERF computation the sampling gets completely
> disabled, under the assumption that there is a problem with
> the hardware.
> 
> However this can happen without any malfunction when there is
> a long enough interruption between the two MSR reads, for
> example due to an unlucky NMI or SMI or other system event
> causing delays. We saw it when a delay resulted in
> Acnt_Delta << Mcnt_Delta (about ~4k for acnt_delta and
> 2M for MCnt_Delta)
> 
> In this case the ratio computation underflows, which is detected,
> but then APERF/MPERF usage gets incorrectly disabled forever.
> 
> Remove the code to completely disable APERF/MPERF on
> a bad sample. Instead when any over/underflow happens
> return the fallback full capacity.

So what systems are actually showing this bad behaviour and what are we
doing to cure the problem rather than fight the symptom?

Also, a system where this is systematically buggered would really be
better off disabling it, no?