Message-ID: <20260122123416-4e3cd7de-5aa0-4fcc-ba64-4b5f089ab83a@linutronix.de>
Date: Thu, 22 Jan 2026 12:41:09 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>
Cc: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>, 
	"npiggin@...il.com" <npiggin@...il.com>, "luto@...nel.org" <luto@...nel.org>, 
	"maddy@...ux.ibm.com" <maddy@...ux.ibm.com>, "tglx@...nel.org" <tglx@...nel.org>, 
	"mpe@...erman.id.au" <mpe@...erman.id.au>, "vincenzo.frascino@....com" <vincenzo.frascino@....com>, 
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()

On Thu, Jan 22, 2026 at 12:31:32PM +0100, Christophe Leroy (CS GROUP) wrote:
> Le 22/01/2026 à 12:07, Thomas Weißschuh a écrit :
> > On Thu, Jan 22, 2026 at 11:58:04AM +0100, Christophe Leroy (CS GROUP) wrote:
> > > 
> > > 
> > > Le 22/01/2026 à 11:49, Thomas Weißschuh a écrit :
> > > > On Thu, Jan 22, 2026 at 11:27:43AM +0100, Christophe Leroy (CS GROUP) wrote:
> > > > > Hi Thomas,
> > > > > 
> > > > > Le 22/01/2026 à 10:50, Thomas Weißschuh a écrit :
> > > > > > Hi Alexander,
> > > > > > 
> > > > > > On Thu, Jan 22, 2026 at 09:39:09AM +0000, Sverdlin, Alexander wrote:
> > > > > > > Hi Thomas, Christophe,
> > > > > > > 
> > > > > > > On Wed, 2026-01-14 at 08:26 +0100, Thomas Weißschuh wrote:
> > > > > > > > For consistency with __vdso_clock_gettime64() there should also be a
> > > > > > > > 64-bit variant of clock_getres(). This will allow the extension of
> > > > > > > > CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit
> > > > > > > > time types from the kernel and UAPI.
> > > > > > > > 
> > > > > > > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > > > > > > 
> > > > > > > I've bisected this patch to cause the following build failure on my side:
> > > > > > > 
> > > > > > >      LDS     arch/powerpc/kernel/vdso/vdso32.lds
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/sigtramp32-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/gettimeofday-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/datapage-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/cacheflush-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/note-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/getcpu-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/getrandom-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/vgetrandom-chacha-32.o
> > > > > > >      VDSO32C arch/powerpc/kernel/vdso/vgettimeofday-32.o
> > > > > > >      VDSO32C arch/powerpc/kernel/vdso/vgetrandom-32.o
> > > > > > >      VDSO32A arch/powerpc/kernel/vdso/crtsavres-32.o
> > > > > > >      VDSO32L arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > > > > > arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported
> > > > > > > make[2]: *** [arch/powerpc/kernel/vdso/Makefile:79: arch/powerpc/kernel/vdso/vdso32.so.dbg] Error 1
> > > > > > > make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2
> > > > > > 
> > > > > > Thanks for the report!
> > > > > > 
> > > > > > > Does it ring any bells? What could I try/test?
> > > > > > 
> > > > > > Not immediately, but I'll look into it.
> > > > > > 
> > > > > > > I'm using gcc-15.2.0 and binutils 2.45.1.
> > > > > > 
> > > > > > Is this a toolchain from https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcdn.kernel.org%2Fpub%2Ftools%2Fcrosstool%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C7f1accdfc7ef4d8ea82c08de59a664b8%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046768343248286%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7WB%2FCB2ZDhP9bD0GYwEftyRwfDCoRwuQ5uMA98JhfmE%3D&reserved=0 ?
> > > > > > Could you also share your configuration?
> > > > > 
> > > > > I've just been able to reproduce it with ppc64_defconfig +
> > > > > CONFIG_CC_OPTIMIZE_FOR_SIZE
> > > > 
> > > > Thanks for the hint, no I can reproduce it, too.
> > > > > 
> > > > >     VDSO32L arch/powerpc/kernel/vdso/vdso32.so.dbg
> > > > > arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not
> > > > > supported
> > > > > make[2]: *** [arch/powerpc/kernel/vdso/Makefile:79:
> > > > > arch/powerpc/kernel/vdso/vdso32.so.dbg] Error 1
> > > > > make[1]: *** [arch/powerpc/Makefile:388: vdso_prepare] Error 2
> > > > > make: *** [Makefile:248: __sub-make] Error 2
> > > > > 
> > > > > I'll investigate
> > > > 
> > > > It seems the compiler decides to call memset(), which is not valid from the
> > > > vDSO. We are are using -ffreestanding. Disabling CONFIG_INIT_STACK_ALL_ZERO
> > > > fixes the issue. So I guess we should a) figure out why -ffreestanding does
> > > > not seem to work here and b) exclude the vDSO from the stack initialization
> > > > logic.
> > > > 
> > > 
> > > Ah, ok.
> > > 
> > > Reminds me commit b91c8c42ffdd ("lib/vdso: Force inlining of
> > > __cvdso_clock_gettime_common()")
> > 
> > Good pointer.
> > 
> > > Problem fixed with:
> > > 
> > > diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
> > > index 95df0153f05ab..4399e143d43a5 100644
> > > --- a/lib/vdso/gettimeofday.c
> > > +++ b/lib/vdso/gettimeofday.c
> > > @@ -421,7 +421,7 @@ static __maybe_unused __kernel_old_time_t
> > > __cvdso_time(__kernel_old_time_t *time
> > >   #endif /* VDSO_HAS_TIME */
> > > 
> > >   #ifdef VDSO_HAS_CLOCK_GETRES
> > > -static __maybe_unused
> > > +static __always_inline
> > >   bool __cvdso_clock_getres_common(const struct vdso_time_data *vd, clockid_t
> > > clock,
> > >   				 struct __kernel_timespec *res)
> > >   {
> > 
> > Do you want to run the measurements for this one, too and submit a fix?
> > This should get us past the immediate breakage.
> 
> I'm travelling at the moment and won't be able to come with measurement
> before next month. But the performance degradation is obvious.

Ack, then I'll send a patch. Thanks for all the information.

> With the fix, the function is stackless:

(...)

> Without the fix, see below, __c_kernel_clock_getres() has to setup a stack
> in order to call __cvdso_clock_getres_common(), and in addition we see that
> __cvdso_clock_getres_common() is more or less the same size as
> __c_kernel_clock_getres() above, so time increase unquestionable.

(...)

> > I'll still try to get the stack initialization out of the vDSO.
> > It might bite us at any time in the future. As these options are meant
> > to prevent information leaks and the vDSO has no sensitive information in
> > the first place, we might as well filter them out.
> 
> Well, from the first day we converted powerpc to C time vdso, we've done our
> best in order to keep vdso stackless. So I'm not sure it is worth dealing
> with the above. Indeed if keeping it as is helps us detect everytime a
> change jeoperdises the stackless approach, that's not bad.

I was not aware about the stacklessness. Then this should be reason enough.
We should get a better system to detect these additional stacks though.
I'll think about it a bit more.

Note: -finline-stringops=memset would also avoid the issues.


Thomas

Powered by blists - more mailing lists