linux-kernel - Re: [PATCH v2 0/4] x86/mtrr: Allow MTRR updates on multiple CPUs in parallel

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: <AD674B41-1280-4FAB-8C4D-393E72EAD8FB@zytor.com>
Date: Mon, 09 Feb 2026 10:37:25 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
CC: Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v2 0/4] x86/mtrr: Allow MTRR updates on multiple CPUs in parallel

On February 9, 2026 1:12:59 AM PST, Juergen Gross <jgross@...e.com> wrote:
>Ping?
>
>I'd really like to have this in 7.0, as it is fixing a real issue on
>some machines ...
>
>
>Juergen
>
>On 30.01.26 12:36, Juergen Gross wrote:
>> Today MTRR updates are serialized to not happen on multiple CPUs at the
>> same time, as the related coding is using global variables.
>> 
>> On huge machines with lots of CPUs this can result in problems, as such
>> updates are happening through stop_machine(), which will call the MTRR
>> update function with interrupts off on all CPUs at the same time. The
>> interrupts will be switched on only after the last CPU has finished
>> the MTRR update. As the update is required to run in uncached mode, it
>> can take easily several milliseconds on each CPU, resulting in the
>> whole process to need several seconds. This in turn can cause the
>> watchdog to trigger and to recognize a hard system lockup.
>> 
>> This series is changing the behavior by allowing the MTRR update to
>> happen on all CPUs in parallel.
>> 
>> Changes in V2:
>> - fix a function comment header in patch 2
>> 
>> Juergen Gross (4):
>>    x86/mtrr: Move cache_enable() and cache_disable() to mtrr/generic.c
>>    x86/mtrr: Introduce MTRR work state structure
>>    x86/mtrr: Add a prepare_set hook to mtrr_ops
>>    x86/mtrr: Drop cache_disable_lock
>> 
>>   arch/x86/include/asm/cacheinfo.h   |   2 -
>>   arch/x86/include/asm/mtrr.h        |   2 -
>>   arch/x86/kernel/cpu/cacheinfo.c    |  80 +----------------
>>   arch/x86/kernel/cpu/mtrr/generic.c | 139 ++++++++++++++++++++++++-----
>>   arch/x86/kernel/cpu/mtrr/mtrr.c    |   3 +
>>   arch/x86/kernel/cpu/mtrr/mtrr.h    |   2 +
>>   6 files changed, 122 insertions(+), 106 deletions(-)
>> 
>

First of all, what machines are even needing MTRR updates these days? 

This isn't a rhetorical question. It is important to understand what the underlying problem is.