Re: [v2 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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