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

[Aaron Tomlin]

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

Attachment: signature.asc
Description: PGP signature