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
