linux-kernel - Re: [PATCH v2 12/13] sparc64: vdso: Implement clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <b0acf633-ea94-4222-b5d8-12996b250e69@app.fastmail.com>
Date: Mon, 18 Aug 2025 15:17:53 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: "Andy Lutomirski" <luto@...nel.org>,
 "Thomas Gleixner" <tglx@...utronix.de>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>,
 "David S . Miller" <davem@...emloft.net>,
 "Andreas Larsson" <andreas@...sler.com>,
 "Nagarathnam Muthusamy" <nagarathnam.muthusamy@...cle.com>,
 "Nick Alcock" <nick.alcock@...cle.com>, "John Stultz" <jstultz@...gle.com>,
 "Stephen Boyd" <sboyd@...nel.org>,
 "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
 linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH v2 12/13] sparc64: vdso: Implement clock_getres()

On Mon, Aug 18, 2025, at 15:00, Thomas Weißschuh wrote:
> On Mon, Aug 18, 2025 at 08:54:53AM +0200, Arnd Bergmann wrote:
>> 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:
>> 
>> 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.
>
> Ack.
>
> So with 'time64 userspace', you mean '32-bit, time64 userspace', correct?

Yes

>> 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().
>
> You mean this division in __cvdso_gettimeofday_data()?
>
> 	tv->tv_usec = (u32)ts.tv_nsec / NSEC_PER_USEC;
>
> Switching the subseconds field to nanoseconds to avoid the division and the
> seconds field to 64bit to avoid overflows brings us back to
> 'struct __kernel_timespec' again, no? What would be the advantage of this over
> vdso_clock_gettime(CLOCK_REALTIME, &ts)?

I misremembered what the current code does. As you point out,
there is a division by NSEC_PER_USEC in the vdso as well, so
there is no difference between libc calling vdso_clock_gettime()
and vdso_gettimeofday() in the number of divisions.

If we wanted to optimize this bit, the division would need
to be folded into vdso_calc_ns()/mul_u64_u32_add_u64_shr(),
which is nontrivial.

>> - 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.
>
> This is only a problem together with vdso_gettimeofday() from above, right?

Correct. I took a look at your sparc64 gettimeofday() to make
sure it uses the correct types and that seems fine since it
gets the __kernel_old_timeval structure definition from the
the sparc64 uapi headers.

     Arnd