[PATCH v2 03/10] um: vdso: Implement __vdso_getcpu() via syscall

[Thomas Weißschuh]

On 2025-09-22 19:07:27+0200, Johannes Berg wrote:
> On Mon, 2025-09-22 at 18:04 +0200, Thomas Weißschuh wrote:

(...)

> > > > > I mean ... on the one hand, sure, it doesn't really do much after this,
> > > > > but OTOH it lets userspace actually use that path? So might be useful.
> > > > 
> > > > What advantage does userspace have from it?
> > > 
> > > Right now, none? But it's easier to play with if you have the
> > > infrastructure, and I'm not convinced there's a _disadvantage_?
> > 
> > So far that hasn't happened. The disadvantages are the ones from above,
> > nothing critical. But of course it is your subsystem and your call to make.
> 
> Yeah, kind of agree, though I'd like to actually use it - especially in
> time-travel mode - but haven't really gotten time to add it. Having it
> maintained in-tree is a bit nicer in case of global updates, but yeah,
> ultimately it's not really all that important either way.
> 
> I guess we could get getrandom() pretty easily by taking the x86 one.

Yeah, the only architecture-specific part there is the assembly chacha
implementation. And that will be the same one as used by regular x86.

> I actually have half a patch somewhere that rejiggers the UM vDSO to be
> more like normal architectures, using lib/vdso/gettimeofday.c and making
> the build more regular etc. Maybe I should dig that up and try to make
> it work entirely - it was part of a previous attempt of adding the time-
> travel thing I mentioned.

Sounds good. And let me know if you want me to look at it.
Using the generic vDSO library and datastore is mandatory nowadays for
"real" vDSOs.

> > > Huh, hm, yeah I forgot about that ... 32-bit. Yeah, agree we should just
> > > kill that. I'm not even sure it works with the host kernel trapping
> > > there? Oh well.
> > 
> > Ack, do you want me to send a patch? This was my real gripe with the UM
> > vDSO. I want to enable time namespaces for all architectures but these
> > need to be handled in the vDSO properly. For the 64-bit stub vDSO it's
> > not a problem as the syscalls will work correctly.
> > But the interaction with the weird 32-bit logic on the other hand...
> 
> I guess? But I'm confused by what you say about it being related to time
> namespaces, the vsyscall stuff doesn't really _do_ anything, assuming it
> works at all? It's not like the host actually could be doing anything
> other than syscalls there, which are intercepted? If it were doing
> anything else, it wouldn't work in UML in the first place?

In emulation mode the trapping kernel will not actually trigger a
syscall but calculate the time in kernel space and write the results to
the respective registers. If I understand correctly the trap is handled
by the host kernel, so that would bypass UML completely.
My wording was a bit wonky. I stumbled upon this while looking for
potential time namespace compatibility issues. And with time namespaces
the chance for a clock mismatch between UML and the host are higher.


Thomas