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] [day] [month] [year] [list]

Message-Id: <5309ef99-9ae7-4525-8d58-f954c13797bc@app.fastmail.com>
Date: Fri, 15 Aug 2025 22:09:23 +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 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:
>> > 
>> 
>> Something doesn't quite line up here: I think the check for
>> CONFIG_SPARC64 needs to be for "#ifndef BUILD_VDSO32", since
>> sparc32 kernels don't have a vdso at all yet.
>
> arch/sparc/vdso/vdso32/vclock_gettime.c translates BUILD_VDSO32 into more
> "standard" defines, CONFIG_SPARC64 in this case. I have a follow-up series
> to get rid of this pattern in all architectures.

Ok

>> On sparc64 kernels, I think you only need the
>> clock_getres_fallback() for 64-bit userspace, while
>> the compat path probably doesn't care about getres, neither
>> the time32 nor time64 variant.
>
> Why?

The clock_getres() vdso call is questionable even on 64-bit
systems, though we appear to have ended up with one on all
the major ones. Realistically if an application needs the
resolution often enough to want a fast way to get it, it can
just store it in a variable.

On 32-bit, we decided against adding a clock_getres_time64()
syscall when we added clock_gettime64() because of this.

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.

     Arnd