Re: [PATCH v2 03/14] selftests: vDSO: Introduce vdso_syscalls.h

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Nov 18, 2025, at 15:22, Thomas Weißschuh wrote:
> On Fri, Nov 14, 2025 at 11:40:31AM +0100, Arnd Bergmann wrote:
>> On Fri, Nov 14, 2025, at 11:02, Thomas Weißschuh wrote:
>> > On Fri, Nov 14, 2025 at 10:16:01AM +0100, Arnd Bergmann wrote:
>> >
>> > I don't think it is important. For my SPARC vDSO series I even
>> > dropped the regular clock_getres() after your request. But because it
>> > doesn't exist we need to handle the presence of vdso_clock_getres() and
>> > the simultaneous absence of sys_clock_getres() in the test.
>> 
>> But that is the other way round, right? On sparc32 we have
>> (optionally) sys_clock_getres() but never vdso_clock_getres().
>
> Here SPARC was just an example to show that I don't really care about
> clock_getres() in the vDSO in general.
> But if it was present before for an architecture and we now drop it without a
> replacement, userspace developers might complain. Manually caching the value
> in userspace sounds ugly and brittle, as it could even change at some point.
> Introducing a time64 replacement on the other hand wouldn't make much
> difference as the values never would exceed the 32-bit range anyways.
>
> So I would keep vdso_clock_getres() where it exists today even with
> CONFIG_COMPAT_32BIT_TIME=n.

It is rather inconsistent with all the other interfaces though:
when we originally did the time64 conversion, there were a number
of interfaces that didn't really need a replacement, but we
deliberately made new interfaces wherever possible. For architectures
without time32 support, and for validating the time64 support,
it should be possible to build both kernel and userspace without
even defining the __kernel_old_time{_t,spec,val} types.

>> Right, but then I would make it return 'struct timespec', not
>> 'struct __kernel_timespec', because it's no longer the kernel
>> interface.
>
> 'struct timespec' might be only 32-bit, breaking the tests after y2038.
> While that shouldn't happen in actual y2038 it would be nice if we can
> validate the future behavior today without reconfiguring libc.
> Given that this is also no longer a libc interface, can't we just use
> the UAPI type?

It clearly works, it just feels a bit wrong to me as mixing up
the types and the interfaces is what caused the problem
originally.

> What is the general expectation for userspace using 32-bit interfaces
> after y2038 from the kernel's perspective?

I would hope that we'll end up turning off the fallback path
and eventually remove that code entirely as we get closer to
y2038, but not everyone agrees with that. An important
open question is whether we'd want to still support running
a 32-bit kernel from 2038+ with time32 userland but the RTC
backdated to 1970.

     Arnd