Thread (7 messages) 7 messages, 4 authors, 2025-10-13

Re: [PATCH v2] vdso: Remove struct getcpu_cache

From: Andy Lutomirski <luto@kernel.org>
Date: 2025-10-13 17:15:12
Also in: linux-kselftest, linux-s390, linux-um, lkml, loongarch

On Mon, Oct 13, 2025 at 7:07 AM Dave Hansen [off-list ref] wrote:
On 10/13/25 02:20, Thomas Weißschuh wrote:
quoted
-int __vdso_getcpu(unsigned int *cpu, unsigned int *node, struct getcpu_cache *unused);
-int __vdso_getcpu(unsigned int *cpu, unsigned int *node, struct getcpu_cache *unused)
+int __vdso_getcpu(unsigned int *cpu, unsigned int *node, void *unused);
+int __vdso_getcpu(unsigned int *cpu, unsigned int *node, void *unused)
 {
      int cpu_id;
It would ideally be nice to have a _bit_ more history on this about
how it became unused any why there is such high confidence that
userspace never tries to use it.
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).

I don't actually remember whether the kernel ever used this.  It's
possible that there are ancient kernels where passing a wild, non-null
pointer would blow up.  But it's certainly safe to pass null, and it's
certainly safe for the kernel to ignore the parameter.

--Andy
Let's say someone comes along in a few years and wants to use this
'unused' parameter. Could they?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help