linux-kernel - Re: [PATCH v6 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes

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: <5820b18ef0ba48c33a62553fcc444c47f963b907.camel@surriel.com>
Date: Wed, 22 Jan 2025 20:13:03 -0500
From: Rik van Riel <riel@...riel.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, bp@...en8.de, 
	dave.hansen@...ux.intel.com, zhengqi.arch@...edance.com,
 nadav.amit@...il.com, 	thomas.lendacky@....com, kernel-team@...a.com,
 linux-mm@...ck.org, 	akpm@...ux-foundation.org, jannh@...gle.com,
 mhklinux@...look.com, 	andrew.cooper3@...rix.com
Subject: Re: [PATCH v6 09/12] x86/mm: enable broadcast TLB invalidation for
 multi-threaded processes

On Wed, 2025-01-22 at 09:38 +0100, Peter Zijlstra wrote:
> 
> Looking at this more... I'm left wondering, did 'we' look at any
> other
> architecture code at all? 
> 
> For example, look at arch/arm64/mm/context.c and see how their reset
> works. Notably, they are not at all limited to reclaiming free'd
> ASIDs,
> but will very aggressively take back all ASIDs except for the current
> running ones.
> 
I did look at the ARM64 code, and while their reset
is much nicer, it looks like that comes at a cost on
each process at context switch time.

In new_context(), there is a call to check_update_reserved_asid(),
which will iterate over all CPUs to check whether this
process's ASID is part of the reserved list that got
carried over during the rollover.

I don't know if that would scale well enough to work
on systems with thousands of CPUs.

> If we want to move towards relying on broadcast TBLI, we'll need to
> go in that direction.

For single threaded processes, which are still very
common, a local flush would likely be faster than
broadcast flushes, even if multiple broadcast flushes
can be pending simultaneously.

For very large systems with a large number of processes,
I agree we want to move in that direction, but we may
need to figure out whether or not everybody taking the 
cpu_asid_lock at rollover time, and then scanning all
other CPUs from check_update_reserved_asid(), with the
lock held, would scale to systems with thousands of CPUs.

Everybody taking the cpu_asid_lock would probably be
fine, if they didn't all have to scan over all the
CPUs.

If we can figure out a more scalable way to do the
new_context() stuff, this would definitely be the
way to go.

-- 
All Rights Reversed.