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: <20250818141851-c185a57d-3081-479c-a32a-add4e5600f3e@linutronix.de>
Date: Mon, 18 Aug 2025 15:00:27 +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 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:
> >> 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:

(...)

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

Ack.

So with 'time64 userspace', you mean '32-bit, time64 userspace', correct?
This was my misunderstanding.

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

Ack.

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

Let's drop it altogether; the code is out there if anybody ever cares.

> 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)?

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


Thomas