linux-kernel - Re: [v2 PATCH 1/1] fs/proc: Expose mm

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: <175da76e-3f04-460b-8629-05062edd2d62@kernel.org>
Date: Tue, 6 Jan 2026 19:54:54 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: oleg@...hat.com, akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
 brauner@...nel.org, mingo@...nel.org, sean@...e.io,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [v2 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status

On 1/1/26 02:19, Aaron Tomlin wrote:
> On Tue, Dec 30, 2025 at 10:16:30PM +0100, David Hildenbrand (Red Hat) wrote:
>> Just a note: I have the faint recollection that there are some arch-specific
>> oddities around mm_cpumask().
>>
>> In particular, that some architectures never clear CPUs from the mask, while
>> others (e.g., x86) clear them one the TLB for them is clean.
>>
>> I'd assume that all architectures at least set the CPUs once they ever ran
>> an MM. But are we sure about that?
>>
>> $ git grep mm_cpumask | grep m68k
>>
>> gives me no results and I don't see common code to ever set a cpu in
>> the mm_cpumask.
>>
>> -- 
>> Cheers
>>
> Hi David,
> 
> You are correct; mm_cpumask semantics vary across architectures (e.g., arc)
> and are even unused on some (e.g., m68k).
> 
> Rather than attempting to standardise this across all architectures, I
> propose we restrict this information to those that follow the "Lazy" TLB
> model-specifically x86. In this model, the mask represents CPUs that might
> hold stale TLB entries for a given MM and thus require IPI-based TLB
> shootdowns to maintain coherency. Since this is the primary context where
> mm_cpumask provides actionable debug data for performance bottlenecks,
> showing it only for x86 (where it is reliably maintained) seems the most
> pragmatic path.

Yes, starting with a very restrictive set, and carefully documenting it 
sounds good to me.

One question is what would happen if these semantics one day change on 
x86. I guess best we can do is to ... document it very carefully.

> 
> I can document this arch-specific limitation in
> Documentation/filesystems/proc.rst and wrapped the implementation in
> CONFIG_X86 to avoid exposing "Best Effort" or zeroed-out data on
> architectures where the mask is not meaningful.
> 
> Please let me know your thoughts.

Something along these lines. Maybe we want an CONFIG_ARCH_* define to 
unlock this from arch code.

-- 
Cheers

David