Re: [PATCH v2 12/13] sparc64: vdso: Implement clock_getres()

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

On Mon, Aug 18, 2025, at 07:50, Thomas Weißschuh wrote:
> On Fri, Aug 15, 2025 at 10:09:23PM +0200, Arnd Bergmann wrote:
>> On Fri, Aug 15, 2025, at 14:34, Thomas Weißschuh wrote:
>> > On Fri, Aug 15, 2025 at 02:13:46PM +0200, Arnd Bergmann wrote:
>> >> On Fri, Aug 15, 2025, at 12:41, Thomas Weißschuh wrote:
>
>> On 32-bit, we decided against adding a clock_getres_time64()
>> syscall when we added clock_gettime64() because of this.
>
> My assumption was that clock_getres_time64() wouldn't make sense in the
> first place, as no clock would have a resolution this big.

While the type conversion is trivial, the general approach has
been to use the new types consistently, so this would be an odd
place to make an exception and require an explicit conversion
from __kernel_old_timespec32 back to __kernel_timespec or the
libc timespec.

>> For time64 userspace, this means that glibc always calls
>> the system call instead of the vdso, and old time32
>> userspace wouldn't use the clock_getres() vdso because
>> there was no vdso implementation when it was compiled.
>
> Is this paragraph meant to be specific for SPARC? Glibc does use the
> clock_getres() vdso fastpath on time64 architectures. But on SPARC no
> application would ever use clock_getres() through the vdso today,
> as it doesn't exist yet.

The glibc code has a weird mixup of the time32 and time64
function names, but from what I can tell, it only ever sets
dl_vdso_clock_getres_time64 on 64-bit architectures, where it
gets set to the normal clock_getres vdso symbol. On 32-bit,
glibc always skips vdso_clock_getres_time64() since it
does not exist, and then it always calls clock_getres_time64()
through the syscall interface, unless it runs on pre-5.6
kernels that fall back to the time32 vdso or syscall.

From the kernel's perspective there is no such thing as a
'time64 architecture', all 32-bit architectures (except x32)
implement the time64 syscalls, most 32-bit architectures also
have the old syscalls, and all 64-bit architectures (plus x32)
only have the old syscalls.

glibc introduced a different view of the same thing, the
internal names on some 32-bit architectures (rv32, arc) get
redirected so they look more like x32. However, those
architectures don't use vdso.

> In any case, I have no strong opinions about this patch and am happy to drop it or support only SPARC64. Most likely nobody will bother to update glibc anyways.

Agreed, I think the only real concern is maintainability here, so
if you think it helps to have __vdso_clock_getres(), please keep
that for sparc64, but let's leave it out for 32-bit altogether.

Two related points:

- something we could add on all 32-bit architectures after
  everything uses the generic vdso implementation is
  vdso_gettimeofday_time64(), this can shave off a few cycles
  because it avoids a division that may be expensive on some
  architectures, making it marginally more useful than
  vdso_clock_getres_time64().

- there is one catch on sparc64 in the way it defines
  __kernel_old_timeval with a 32-bit __kernel_suseconds_t,
  unlike all other 64-bit architectures. This is incompatible
  with glibc's __timeval64 definition on sparc32, so there
  would need to be a special case for sparc32 somewhere,
  either in the kernel or in glibc.

       Arnd