linux-kernel - Re: [v3 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2cab00c18ed7499e5ef143c7f3198c61d56ede25.camel@surriel.com>
Date: Thu, 15 Jan 2026 21:27:44 -0500
From: Rik van Riel <riel@...riel.com>
To: Aaron Tomlin <atomlin@...mlin.com>, Dave Hansen <dave.hansen@...el.com>
Cc: "David Hildenbrand (Red Hat)" <david@...nel.org>, oleg@...hat.com, 
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org, brauner@...nel.org, 
	mingo@...nel.org, neelx@...e.com, sean@...e.io,
 linux-kernel@...r.kernel.org, 	linux-fsdevel@...r.kernel.org, Dave Hansen
 <dave.hansen@...ux.intel.com>,  Andy Lutomirski	 <luto@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, "x86@...nel.org"	 <x86@...nel.org>
Subject: Re: [v3 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status

On Thu, 2026-01-15 at 20:53 -0500, Aaron Tomlin wrote:
> 
> Based on my reading of arch/x86/mm/tlb.c, the lifecycle of each bit
> in
> mm_cpumask appears to follow this logic:
> 
>     1. Schedule on (switch_mm): Bit set.
>     2. Schedule off: Bit remains set (CPU enters "Lazy" mode).
>     3. Remote TLB Flush (IPI):
>        - If Running: Flush TLB, bit remains set.
>        - If lazy (leave_mm): Switch to init_mm, bit clearing is
> deferred.
>        - If stale (mm != loaded_mm): bit is cleared immediately
>          (effectively the second IPI for a CPU that was previously
> lazy).
> 

You're close. When a process uses INVLPGB, no remote TLB
flushing IPIs will get sent, and CPUs never get cleared
from the mm_cpumask.

-- 
All Rights Reversed.