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: <b4ggvwwbxn3a4i3pyt6j27yl56yqyjlhylm57kjcgfr3esim7y@5l3mygsbfuqo>
Date: Fri, 16 Jan 2026 09:31:15 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Rik van Riel <riel@...riel.com>
Cc: Dave Hansen <dave.hansen@...el.com>, 
	"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, Jan 15, 2026 at 09:27:44PM -0500, Rik van Riel wrote:
> 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.

Hi Rik,

Not close enough :)

It is good to hear from you, and thank you for the clarification regarding
X86_FEATURE_INVLPGB.

You are quite right; as flush_tlb_func() serves as the sole mechanism for
clearing bits from the mm_cpumask, bypassing IPIs inherently bypasses the
cleanup logic. Consequently, in this scenario, the bit is set upon
scheduling but never cleared, as the hardware-broadcast invalidations
circumvent the software handler responsible for maintaining the mask.


Kind regards,
-- 
Aaron Tomlin

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)