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: <20250818073135-130dfc53-225c-48a3-b960-e982faa866bf@linutronix.de>
Date: Mon, 18 Aug 2025 07:50:47 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Arnd Bergmann <arnd@...db.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 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 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.

Agreed.

> 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.

> 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.

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.


Thomas