linux-kernel - Re: [PATCH v2] vdso: Remove struct getcpu

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] [day] [month] [year] [list]

Message-ID: <lhu5xchq2u1.fsf@oldenburg.str.redhat.com>
Date: Tue, 14 Oct 2025 10:56:06 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: Dave Hansen <dave.hansen@...el.com>,  Thomas Weißschuh
 <thomas.weissschuh@...utronix.de>,  Huacai Chen <chenhuacai@...nel.org>,
  WANG Xuerui <kernel@...0n.name>,  Heiko Carstens <hca@...ux.ibm.com>,
  Vasily Gorbik <gor@...ux.ibm.com>,  Alexander Gordeev
 <agordeev@...ux.ibm.com>,  Christian Borntraeger
 <borntraeger@...ux.ibm.com>,  Sven Schnelle <svens@...ux.ibm.com>,  Thomas
 Gleixner <tglx@...utronix.de>,  Ingo Molnar <mingo@...hat.com>,  Borislav
 Petkov <bp@...en8.de>,  Dave Hansen <dave.hansen@...ux.intel.com>,
  x86@...nel.org,  "H. Peter Anvin" <hpa@...or.com>,  Richard Weinberger
 <richard@....at>,  Anton Ivanov <anton.ivanov@...bridgegreys.com>,
  Johannes Berg <johannes@...solutions.net>,  Vincenzo Frascino
 <vincenzo.frascino@....com>,  Shuah Khan <shuah@...nel.org>,
  loongarch@...ts.linux.dev,  linux-kernel@...r.kernel.org,
  linux-s390@...r.kernel.org,  linux-um@...ts.infradead.org,
  linux-api@...r.kernel.org,  linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2] vdso: Remove struct getcpu_cache

* Andy Lutomirski:

> The theory is that people thought that getcpu was going to be kind of
> slow, so userspace would allocate a little cache (IIRC per-thread) and
> pass it in, and the vDSO would do, well, something clever to return
> the right value.  The something clever was probably based on the idea
> that you can't actually tell (in general) if the return value from
> getcpu is stale, since you might well get migrated right as the
> function returns anyway, so the cache could be something silly like
> (jiffies, cpu).

It probably had to do something with per-CPU or per-node mappings of the
vDSO.  Or may some non-coherent cache line in the vDSO.  As far as I
understand it, the cache has zero chance of working with the way vDSO
data is currently implemented.

We have the CPU ID and node ID in the restartable sequences area now
(although glibc does not use the node ID yet).  It's not a cache.  So
this clearly supersedes whatever struct getcpu_cache tried to achieve.

Thanks,
Florian