Le 22/01/2026 à 12:41, Thomas Weißschuh a écrit :

On Thu, Jan 22, 2026 at 12:31:32PM +0100, Christophe Leroy (CS GROUP) wrote:

quoted

Le 22/01/2026 à 12:07, Thomas Weißschuh a écrit :

quoted

On Thu, Jan 22, 2026 at 11:58:04AM +0100, Christophe Leroy (CS GROUP) wrote:

quoted

Le 22/01/2026 à 11:49, Thomas Weißschuh a écrit :

quoted

On Thu, Jan 22, 2026 at 11:27:43AM +0100, Christophe Leroy (CS GROUP) wrote:

quoted

Hi Thomas,

Le 22/01/2026 à 10:50, Thomas Weißschuh a écrit :

quoted

Hi Alexander,

On Thu, Jan 22, 2026 at 09:39:09AM +0000, Sverdlin, Alexander wrote:

quoted

Hi Thomas, Christophe,

On Wed, 2026-01-14 at 08:26 +0100, Thomas Weißschuh wrote:

quoted

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

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!

quoted

Does it ring any bells? What could I try/test?

Not immediately, but I'll look into it.

quoted

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%7Cbd6434eab4334cea44fe08de59ab274e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046788822130060%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K7PlfBLHdNEBRgsPQ5aNBgu2v8DqDrhmzwoHrcOc5s8%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.

quoted

     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.

quoted

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.

quoted

With the fix, the function is stackless:

(...)

quoted

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.

(...)

quoted

quoted

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.

Well, that's only a "best effort", at the end we don't success in all 
cases, refer commit 08c18b63d965 ("powerpc/vdso32: Add missing 
_restgpr_31_x to fix build failure"), there are not enough volatile 
registers for __c_kernel_clock_gettime(), part of this function sets up 
a stack frame to save one non-volatile register and use it. But at least 
for time we can keep flat functions that don't have to suffer the 
overcost of saving volatile registers for calling subfunctions.

For __c_kernel_getrandom() that's different because it has to call 
__arch_chacha20_blocks_nostack() so a stack frame is definitely needed 
but at least we also avoid there to have multiple sub-function calls.

Christophe