public inbox for linuxppc-dev@ozlabs.org
 help / color / mirror / Atom feed
* [PATCH] powerpc/vdso: Provide clock_getres_time64()
@ 2026-01-14  7:26 Thomas Weißschuh
  2026-01-14  8:27 ` Christophe Leroy (CS GROUP)
  2026-01-22  9:39 ` Sverdlin, Alexander
  0 siblings, 2 replies; 14+ messages in thread
From: Thomas Weißschuh @ 2026-01-14  7:26 UTC (permalink / raw)
  To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
	Christophe Leroy (CS GROUP), Andy Lutomirski, Thomas Gleixner,
	Vincenzo Frascino
  Cc: linuxppc-dev, linux-kernel, Thomas Weißschuh

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@linutronix.de>
---
Based on tip/timers/vdso.

This was missed in the original vdso_getres_time64() series as powerpc
does not use include/vdso/gettime.h.
---
 arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
 arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
 arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
 arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
 4 files changed, 21 insertions(+)

diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
index ab3df12c8d94..8ea397e26ad0 100644
--- a/arch/powerpc/include/asm/vdso/gettimeofday.h
+++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
@@ -135,6 +135,8 @@ int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
 			       const struct vdso_time_data *vd);
 int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
 			    const struct vdso_time_data *vd);
+int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
+				   const struct vdso_time_data *vd);
 #endif
 int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
 			    const struct vdso_time_data *vd);
diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
index 79c967212444..1c8e51691bf8 100644
--- a/arch/powerpc/kernel/vdso/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso/gettimeofday.S
@@ -103,6 +103,18 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
 	cvdso_call __c_kernel_clock_getres
 V_FUNCTION_END(__kernel_clock_getres)
 
+/*
+ * Exact prototype of clock_getres_time64()
+ *
+ * int __kernel_clock_getres(clockid_t clock_id, struct __timespec64 *res);
+ *
+ */
+#ifndef __powerpc64__
+V_FUNCTION_BEGIN(__kernel_clock_getres_time64)
+	cvdso_call __c_kernel_clock_getres_time64
+V_FUNCTION_END(__kernel_clock_getres_time64)
+#endif
+
 
 /*
  * Exact prototype of time()
diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
index 72a1012b8a20..3f384a2526ae 100644
--- a/arch/powerpc/kernel/vdso/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
@@ -124,6 +124,7 @@ VERSION
 		__kernel_clock_gettime;
 		__kernel_clock_gettime64;
 		__kernel_clock_getres;
+		__kernel_clock_getres_time64;
 		__kernel_time;
 		__kernel_get_tbfreq;
 		__kernel_sync_dicache;
diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
index 6f5167d81af5..3c194e1ab562 100644
--- a/arch/powerpc/kernel/vdso/vgettimeofday.c
+++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
@@ -35,6 +35,12 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
 {
 	return __cvdso_clock_getres_time32_data(vd, clock_id, res);
 }
+
+int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
+				   const struct vdso_time_data *vd)
+{
+	return __cvdso_clock_getres_data(vd, clock_id, res);
+}
 #endif
 
 int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,

---
base-commit: 0e55e7636697077abceb2301d7d2718d75c34389
change-id: 20260113-vdso-powerpc-align-e8e93664da2b

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>



^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-14  7:26 [PATCH] powerpc/vdso: Provide clock_getres_time64() Thomas Weißschuh
@ 2026-01-14  8:27 ` Christophe Leroy (CS GROUP)
  2026-01-22  9:39 ` Sverdlin, Alexander
  1 sibling, 0 replies; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-14  8:27 UTC (permalink / raw)
  To: Thomas Weißschuh, Madhavan Srinivasan, Michael Ellerman,
	Nicholas Piggin, Andy Lutomirski, Thomas Gleixner,
	Vincenzo Frascino
  Cc: linuxppc-dev, linux-kernel



Le 14/01/2026 à 08:26, Thomas Weißschuh a écrit :
> 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@linutronix.de>

Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>

> ---
> Based on tip/timers/vdso.
> 
> This was missed in the original vdso_getres_time64() series as powerpc
> does not use include/vdso/gettime.h.
> ---
>   arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
>   arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
>   arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
>   arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
>   4 files changed, 21 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
> index ab3df12c8d94..8ea397e26ad0 100644
> --- a/arch/powerpc/include/asm/vdso/gettimeofday.h
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -135,6 +135,8 @@ int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
>   			       const struct vdso_time_data *vd);
>   int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>   			    const struct vdso_time_data *vd);
> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
> +				   const struct vdso_time_data *vd);
>   #endif
>   int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
>   			    const struct vdso_time_data *vd);
> diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
> index 79c967212444..1c8e51691bf8 100644
> --- a/arch/powerpc/kernel/vdso/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso/gettimeofday.S
> @@ -103,6 +103,18 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
>   	cvdso_call __c_kernel_clock_getres
>   V_FUNCTION_END(__kernel_clock_getres)
>   
> +/*
> + * Exact prototype of clock_getres_time64()
> + *
> + * int __kernel_clock_getres(clockid_t clock_id, struct __timespec64 *res);
> + *
> + */
> +#ifndef __powerpc64__
> +V_FUNCTION_BEGIN(__kernel_clock_getres_time64)
> +	cvdso_call __c_kernel_clock_getres_time64
> +V_FUNCTION_END(__kernel_clock_getres_time64)
> +#endif
> +
>   
>   /*
>    * Exact prototype of time()
> diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
> index 72a1012b8a20..3f384a2526ae 100644
> --- a/arch/powerpc/kernel/vdso/vdso32.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
> @@ -124,6 +124,7 @@ VERSION
>   		__kernel_clock_gettime;
>   		__kernel_clock_gettime64;
>   		__kernel_clock_getres;
> +		__kernel_clock_getres_time64;
>   		__kernel_time;
>   		__kernel_get_tbfreq;
>   		__kernel_sync_dicache;
> diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
> index 6f5167d81af5..3c194e1ab562 100644
> --- a/arch/powerpc/kernel/vdso/vgettimeofday.c
> +++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
> @@ -35,6 +35,12 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>   {
>   	return __cvdso_clock_getres_time32_data(vd, clock_id, res);
>   }
> +
> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
> +				   const struct vdso_time_data *vd)
> +{
> +	return __cvdso_clock_getres_data(vd, clock_id, res);
> +}
>   #endif
>   
>   int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
> 
> ---
> base-commit: 0e55e7636697077abceb2301d7d2718d75c34389
> change-id: 20260113-vdso-powerpc-align-e8e93664da2b
> 
> Best regards,



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-14  7:26 [PATCH] powerpc/vdso: Provide clock_getres_time64() Thomas Weißschuh
  2026-01-14  8:27 ` Christophe Leroy (CS GROUP)
@ 2026-01-22  9:39 ` Sverdlin, Alexander
  2026-01-22  9:50   ` Thomas Weißschuh
  2026-01-22  9:53   ` Christophe Leroy (CS GROUP)
  1 sibling, 2 replies; 14+ messages in thread
From: Sverdlin, Alexander @ 2026-01-22  9:39 UTC (permalink / raw)
  To: thomas.weissschuh@linutronix.de, npiggin@gmail.com,
	luto@kernel.org, chleroy@kernel.org, maddy@linux.ibm.com,
	tglx@kernel.org, mpe@ellerman.id.au, vincenzo.frascino@arm.com
  Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org

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

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

I'm using gcc-15.2.0 and binutils 2.45.1.

> ---
> Based on tip/timers/vdso.
> 
> This was missed in the original vdso_getres_time64() series as powerpc
> does not use include/vdso/gettime.h.
> ---
>  arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
>  arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
>  arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
>  arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
>  4 files changed, 21 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
> index ab3df12c8d94..8ea397e26ad0 100644
> --- a/arch/powerpc/include/asm/vdso/gettimeofday.h
> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
> @@ -135,6 +135,8 @@ int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
>  			       const struct vdso_time_data *vd);
>  int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>  			    const struct vdso_time_data *vd);
> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
> +				   const struct vdso_time_data *vd);
>  #endif
>  int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
>  			    const struct vdso_time_data *vd);
> diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
> index 79c967212444..1c8e51691bf8 100644
> --- a/arch/powerpc/kernel/vdso/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso/gettimeofday.S
> @@ -103,6 +103,18 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
>  	cvdso_call __c_kernel_clock_getres
>  V_FUNCTION_END(__kernel_clock_getres)
>  
> +/*
> + * Exact prototype of clock_getres_time64()
> + *
> + * int __kernel_clock_getres(clockid_t clock_id, struct __timespec64 *res);
> + *
> + */
> +#ifndef __powerpc64__
> +V_FUNCTION_BEGIN(__kernel_clock_getres_time64)
> +	cvdso_call __c_kernel_clock_getres_time64
> +V_FUNCTION_END(__kernel_clock_getres_time64)
> +#endif
> +
>  
>  /*
>   * Exact prototype of time()
> diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
> index 72a1012b8a20..3f384a2526ae 100644
> --- a/arch/powerpc/kernel/vdso/vdso32.lds.S
> +++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
> @@ -124,6 +124,7 @@ VERSION
>  		__kernel_clock_gettime;
>  		__kernel_clock_gettime64;
>  		__kernel_clock_getres;
> +		__kernel_clock_getres_time64;
>  		__kernel_time;
>  		__kernel_get_tbfreq;
>  		__kernel_sync_dicache;
> diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
> index 6f5167d81af5..3c194e1ab562 100644
> --- a/arch/powerpc/kernel/vdso/vgettimeofday.c
> +++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
> @@ -35,6 +35,12 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>  {
>  	return __cvdso_clock_getres_time32_data(vd, clock_id, res);
>  }
> +
> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
> +				   const struct vdso_time_data *vd)
> +{
> +	return __cvdso_clock_getres_data(vd, clock_id, res);
> +}
>  #endif
>  
>  int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
> 
> ---
> base-commit: 0e55e7636697077abceb2301d7d2718d75c34389
> change-id: 20260113-vdso-powerpc-align-e8e93664da2b
> 
> Best regards,

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22  9:39 ` Sverdlin, Alexander
@ 2026-01-22  9:50   ` Thomas Weißschuh
  2026-01-22 10:00     ` Sverdlin, Alexander
  2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
  2026-01-22  9:53   ` Christophe Leroy (CS GROUP)
  1 sibling, 2 replies; 14+ messages in thread
From: Thomas Weißschuh @ 2026-01-22  9:50 UTC (permalink / raw)
  To: Sverdlin, Alexander
  Cc: npiggin@gmail.com, luto@kernel.org, chleroy@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org

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@linutronix.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://cdn.kernel.org/pub/tools/crosstool/ ?
Could you also share your configuration?

> > ---
> > Based on tip/timers/vdso.
> > 
> > This was missed in the original vdso_getres_time64() series as powerpc
> > does not use include/vdso/gettime.h.
> > ---
> >  arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
> >  arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
> >  arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
> >  arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
> >  4 files changed, 21 insertions(+)

(...)


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22  9:39 ` Sverdlin, Alexander
  2026-01-22  9:50   ` Thomas Weißschuh
@ 2026-01-22  9:53   ` Christophe Leroy (CS GROUP)
  1 sibling, 0 replies; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22  9:53 UTC (permalink / raw)
  To: Sverdlin, Alexander, thomas.weissschuh@linutronix.de,
	npiggin@gmail.com, luto@kernel.org, chleroy@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com
  Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org

Hi Alexandre,

Le 22/01/2026 à 10:39, Sverdlin, Alexander a écrit :
> 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@linutronix.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
> 
> Does it ring any bells? What could I try/test?
> 
> I'm using gcc-15.2.0 and binutils 2.45.1.

Can you share your defconfig ?

I don't have such a problem with mpc885_ads_defconfig using same 
gcc/binutils as you.

Christophe

> 
>> ---
>> Based on tip/timers/vdso.
>>
>> This was missed in the original vdso_getres_time64() series as powerpc
>> does not use include/vdso/gettime.h.
>> ---
>>   arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
>>   arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
>>   arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
>>   arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
>>   4 files changed, 21 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/vdso/gettimeofday.h b/arch/powerpc/include/asm/vdso/gettimeofday.h
>> index ab3df12c8d94..8ea397e26ad0 100644
>> --- a/arch/powerpc/include/asm/vdso/gettimeofday.h
>> +++ b/arch/powerpc/include/asm/vdso/gettimeofday.h
>> @@ -135,6 +135,8 @@ int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
>>   			       const struct vdso_time_data *vd);
>>   int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>>   			    const struct vdso_time_data *vd);
>> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
>> +				   const struct vdso_time_data *vd);
>>   #endif
>>   int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
>>   			    const struct vdso_time_data *vd);
>> diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
>> index 79c967212444..1c8e51691bf8 100644
>> --- a/arch/powerpc/kernel/vdso/gettimeofday.S
>> +++ b/arch/powerpc/kernel/vdso/gettimeofday.S
>> @@ -103,6 +103,18 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
>>   	cvdso_call __c_kernel_clock_getres
>>   V_FUNCTION_END(__kernel_clock_getres)
>>   
>> +/*
>> + * Exact prototype of clock_getres_time64()
>> + *
>> + * int __kernel_clock_getres(clockid_t clock_id, struct __timespec64 *res);
>> + *
>> + */
>> +#ifndef __powerpc64__
>> +V_FUNCTION_BEGIN(__kernel_clock_getres_time64)
>> +	cvdso_call __c_kernel_clock_getres_time64
>> +V_FUNCTION_END(__kernel_clock_getres_time64)
>> +#endif
>> +
>>   
>>   /*
>>    * Exact prototype of time()
>> diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
>> index 72a1012b8a20..3f384a2526ae 100644
>> --- a/arch/powerpc/kernel/vdso/vdso32.lds.S
>> +++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
>> @@ -124,6 +124,7 @@ VERSION
>>   		__kernel_clock_gettime;
>>   		__kernel_clock_gettime64;
>>   		__kernel_clock_getres;
>> +		__kernel_clock_getres_time64;
>>   		__kernel_time;
>>   		__kernel_get_tbfreq;
>>   		__kernel_sync_dicache;
>> diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
>> index 6f5167d81af5..3c194e1ab562 100644
>> --- a/arch/powerpc/kernel/vdso/vgettimeofday.c
>> +++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
>> @@ -35,6 +35,12 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
>>   {
>>   	return __cvdso_clock_getres_time32_data(vd, clock_id, res);
>>   }
>> +
>> +int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
>> +				   const struct vdso_time_data *vd)
>> +{
>> +	return __cvdso_clock_getres_data(vd, clock_id, res);
>> +}
>>   #endif
>>   
>>   int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
>>
>> ---
>> base-commit: 0e55e7636697077abceb2301d7d2718d75c34389
>> change-id: 20260113-vdso-powerpc-align-e8e93664da2b
>>
>> Best regards,
> 



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22  9:50   ` Thomas Weißschuh
@ 2026-01-22 10:00     ` Sverdlin, Alexander
  2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
  1 sibling, 0 replies; 14+ messages in thread
From: Sverdlin, Alexander @ 2026-01-22 10:00 UTC (permalink / raw)
  To: thomas.weissschuh@linutronix.de
  Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	chleroy@kernel.org

Thanks for the quick reply, Thomas!

On Thu, 2026-01-22 at 10:50 +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@linutronix.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://cdn.kernel.org/pub/tools/crosstool/ ?

It's actually yocto master toolchain as of 6145837147dc2a6d54a221f9cd7fe90d6895ff90 (openembedded-core).

> Could you also share your configuration?

Do you mean kernel config? I'll send it privately in a minute not to overload the lists...

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22  9:50   ` Thomas Weißschuh
  2026-01-22 10:00     ` Sverdlin, Alexander
@ 2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
  2026-01-22 10:49       ` Thomas Weißschuh
  2026-01-22 10:49       ` Christophe Leroy (CS GROUP)
  1 sibling, 2 replies; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22 10:27 UTC (permalink / raw)
  To: Thomas Weißschuh, Sverdlin, Alexander
  Cc: npiggin@gmail.com, luto@kernel.org, maddy@linux.ibm.com,
	tglx@kernel.org, mpe@ellerman.id.au, vincenzo.frascino@arm.com,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org

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@linutronix.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%7C03b93d2aa659407b3e5a08de599bb85e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046722536758587%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b9WoZvMR2V3RUpOwrJtm6kmXrpnLti%2BeMJ6zpyB%2Fv4k%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

   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

Christophe

> 
>>> ---
>>> Based on tip/timers/vdso.
>>>
>>> This was missed in the original vdso_getres_time64() series as powerpc
>>> does not use include/vdso/gettime.h.
>>> ---
>>>   arch/powerpc/include/asm/vdso/gettimeofday.h |  2 ++
>>>   arch/powerpc/kernel/vdso/gettimeofday.S      | 12 ++++++++++++
>>>   arch/powerpc/kernel/vdso/vdso32.lds.S        |  1 +
>>>   arch/powerpc/kernel/vdso/vgettimeofday.c     |  6 ++++++
>>>   4 files changed, 21 insertions(+)
> 
> (...)



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
@ 2026-01-22 10:49       ` Thomas Weißschuh
  2026-01-22 10:58         ` Christophe Leroy (CS GROUP)
  2026-01-22 10:49       ` Christophe Leroy (CS GROUP)
  1 sibling, 1 reply; 14+ messages in thread
From: Thomas Weißschuh @ 2026-01-22 10:49 UTC (permalink / raw)
  To: Christophe Leroy (CS GROUP), Sverdlin, Alexander
  Cc: npiggin@gmail.com, luto@kernel.org, maddy@linux.ibm.com,
	tglx@kernel.org, mpe@ellerman.id.au, vincenzo.frascino@arm.com,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org

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@linutronix.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%7C03b93d2aa659407b3e5a08de599bb85e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046722536758587%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=b9WoZvMR2V3RUpOwrJtm6kmXrpnLti%2BeMJ6zpyB%2Fv4k%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.

000007ac <__c_kernel_clock_getres>:
; __c_kernel_clock_getres():
; arch/powerpc/kernel/vdso/vgettimeofday.c:35
; {
     7ac: d0 ff 21 94   stwu 1, -48(1)
     7b0: a6 02 08 7c   mflr 0
     7b4: 30 00 61 39   addi 11, 1, 48
     7b8: 34 00 01 90   stw 0, 52(1)
     7bc: 01 00 00 48   bl 0x7bc <__c_kernel_clock_getres+0x10>
                        000007bc:  R_PPC_REL24  _savegpr_29
     7c0: 78 1b 7e 7c   mr      30, 3
     7c4: 78 2b bd 7c   mr      29, 5
     7c8: 78 23 9f 7c   mr      31, 4
; lib/vdso/gettimeofday.c:491
;       struct __kernel_timespec ts;
     7cc: 10 00 a0 38   li 5, 16
     7d0: 00 00 80 38   li 4, 0
     7d4: 08 00 61 38   addi 3, 1, 8
     7d8: 01 00 00 48   bl 0x7d8 <__c_kernel_clock_getres+0x2c>
                        000007d8:  R_PPC_REL24  memset
; lib/vdso/gettimeofday.c:494
;       ok = __cvdso_clock_getres_common(vd, clock, &ts);
     7dc: 78 f3 c4 7f   mr      4, 30
     7e0: 78 eb a3 7f   mr      3, 29
     7e4: 08 00 a1 38   addi 5, 1, 8
     7e8: 19 f8 ff 4b   bl 0x0 <__cvdso_clock_getres_common>
; lib/vdso/gettimeofday.c:496

(...)


Thomas


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
  2026-01-22 10:49       ` Thomas Weißschuh
@ 2026-01-22 10:49       ` Christophe Leroy (CS GROUP)
  1 sibling, 0 replies; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22 10:49 UTC (permalink / raw)
  To: Thomas Weißschuh, Sverdlin, Alexander
  Cc: npiggin@gmail.com, luto@kernel.org, maddy@linux.ibm.com,
	tglx@kernel.org, mpe@ellerman.id.au, vincenzo.frascino@arm.com,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org

Hi Again,

Le 22/01/2026 à 11:27, Christophe Leroy (CS GROUP) a écrit :
> Hi Thomas,
> 
> Le 22/01/2026 à 10:50, Thomas Weißschuh a écrit :
>> Hi Alexander,
>> Could you also share your configuration?
> 
> I've just been able to reproduce it with ppc64_defconfig + 
> CONFIG_CC_OPTIMIZE_FOR_SIZE
> 
>    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
> 

Comes from here, a call to memset():

000007c0 <__c_kernel_clock_getres>:
  7c0:   94 21 ff d0     stwu    r1,-48(r1)
  7c4:   7c 08 02 a6     mflr    r0
  7c8:   bf a1 00 24     stmw    r29,36(r1)
  7cc:   7c 7e 1b 78     mr      r30,r3
  7d0:   7c bd 2b 78     mr      r29,r5
  7d4:   7c 9f 23 78     mr      r31,r4
  7d8:   38 a0 00 10     li      r5,16
  7dc:   90 01 00 34     stw     r0,52(r1)
  7e0:   38 80 00 00     li      r4,0
  7e4:   38 61 00 08     addi    r3,r1,8
  7e8:   48 00 00 01     bl      7e8 <__c_kernel_clock_getres+0x28>
                         7e8: R_PPC_REL24        memset
  7ec:   7f c4 f3 78     mr      r4,r30
  7f0:   7f a3 eb 78     mr      r3,r29
  7f4:   38 a1 00 08     addi    r5,r1,8
  7f8:   4b ff f8 09     bl      0 <__cvdso_clock_getres_common>
  7fc:   2c 03 00 00     cmpwi   r3,0
  800:   40 82 00 24     bne     824 <__c_kernel_clock_getres+0x64>
  804:   38 00 00 f7     li      r0,247
  808:   7f c3 f3 78     mr      r3,r30
  80c:   7f e4 fb 78     mr      r4,r31
  810:   44 00 00 02     sc
  814:   40 e3 00 08     bns+    81c <__c_kernel_clock_getres+0x5c>
  818:   7c 63 00 d0     neg     r3,r3
  81c:   39 61 00 30     addi    r11,r1,48
  820:   48 00 00 00     b       820 <__c_kernel_clock_getres+0x60>
                         820: R_PPC_REL24        _restgpr_29_x
  824:   2c 1f 00 00     cmpwi   r31,0
  828:   41 82 00 14     beq     83c <__c_kernel_clock_getres+0x7c>
  82c:   81 21 00 0c     lwz     r9,12(r1)
  830:   91 3f 00 00     stw     r9,0(r31)
  834:   81 21 00 14     lwz     r9,20(r1)
  838:   91 3f 00 04     stw     r9,4(r31)
  83c:   38 60 00 00     li      r3,0
  840:   4b ff ff dc     b       81c <__c_kernel_clock_getres+0x5c>



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 10:49       ` Thomas Weißschuh
@ 2026-01-22 10:58         ` Christophe Leroy (CS GROUP)
  2026-01-22 11:07           ` Thomas Weißschuh
  0 siblings, 1 reply; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22 10:58 UTC (permalink / raw)
  To: Thomas Weißschuh, Sverdlin, Alexander
  Cc: npiggin@gmail.com, luto@kernel.org, maddy@linux.ibm.com,
	tglx@kernel.org, mpe@ellerman.id.au, vincenzo.frascino@arm.com,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org



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@linutronix.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%7C937051154ddf479721f708de59a3e01c%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046757528646789%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qkl4zNfg2j%2F24vZV7nQ7LLDtxG0WbgaJc30kjHQZqpk%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()")

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


Christophe


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 10:58         ` Christophe Leroy (CS GROUP)
@ 2026-01-22 11:07           ` Thomas Weißschuh
  2026-01-22 11:31             ` Christophe Leroy (CS GROUP)
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Weißschuh @ 2026-01-22 11:07 UTC (permalink / raw)
  To: Christophe Leroy (CS GROUP)
  Cc: Sverdlin, Alexander, npiggin@gmail.com, luto@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org

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@linutronix.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%7C937051154ddf479721f708de59a3e01c%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639046757528646789%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qkl4zNfg2j%2F24vZV7nQ7LLDtxG0WbgaJc30kjHQZqpk%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'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.


Thomas


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 11:07           ` Thomas Weißschuh
@ 2026-01-22 11:31             ` Christophe Leroy (CS GROUP)
  2026-01-22 11:41               ` Thomas Weißschuh
  0 siblings, 1 reply; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22 11:31 UTC (permalink / raw)
  To: Thomas Weißschuh
  Cc: Sverdlin, Alexander, npiggin@gmail.com, luto@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org



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

With the fix, the function is stackless:

00000728 <__c_kernel_clock_getres>:
  728:	28 03 00 17 	cmplwi  r3,23
  72c:	41 81 00 50 	bgt     77c <__c_kernel_clock_getres+0x54>
  730:	81 45 00 04 	lwz     r10,4(r5)
  734:	6d 49 80 00 	xoris   r9,r10,32768
  738:	2c 09 ff ff 	cmpwi   r9,-1
  73c:	40 82 00 08 	bne     744 <__c_kernel_clock_getres+0x1c>
  740:	3c a5 00 01 	addis   r5,r5,1
  744:	39 20 00 01 	li      r9,1
  748:	7d 29 18 30 	slw     r9,r9,r3
  74c:	71 2a 08 93 	andi.   r10,r9,2195
  750:	41 82 00 18 	beq     768 <__c_kernel_clock_getres+0x40>
  754:	81 25 08 c8 	lwz     r9,2248(r5)
  758:	2c 04 00 00 	cmpwi   r4,0
  75c:	40 82 00 40 	bne     79c <__c_kernel_clock_getres+0x74>
  760:	38 60 00 00 	li      r3,0
  764:	4e 80 00 20 	blr
  768:	71 2a 00 60 	andi.   r10,r9,96
  76c:	40 82 00 24 	bne     790 <__c_kernel_clock_getres+0x68>
  770:	75 29 00 ff 	andis.  r9,r9,255
  774:	39 20 00 01 	li      r9,1
  778:	40 82 ff e0 	bne     758 <__c_kernel_clock_getres+0x30>
  77c:	38 00 00 f7 	li      r0,247
  780:	44 00 00 02 	sc
  784:	40 e3 00 08 	bns+    78c <__c_kernel_clock_getres+0x64>
  788:	7c 63 00 d0 	neg     r3,r3
  78c:	4e 80 00 20 	blr
  790:	3d 20 00 0f 	lis     r9,15
  794:	61 29 42 40 	ori     r9,r9,16960
  798:	4b ff ff c0 	b       758 <__c_kernel_clock_getres+0x30>
  79c:	39 40 00 00 	li      r10,0
  7a0:	91 24 00 04 	stw     r9,4(r4)
  7a4:	91 44 00 00 	stw     r10,0(r4)
  7a8:	4b ff ff b8 	b       760 <__c_kernel_clock_getres+0x38>

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.

00000000 <__cvdso_clock_getres_common>:
    0:	28 04 00 17 	cmplwi  r4,23
    4:	41 81 00 8c 	bgt     90 <__cvdso_clock_getres_common+0x90>
    8:	81 43 00 04 	lwz     r10,4(r3)
    c:	6d 49 80 00 	xoris   r9,r10,32768
   10:	2c 09 ff ff 	cmpwi   r9,-1
   14:	40 82 00 08 	bne     1c <__cvdso_clock_getres_common+0x1c>
   18:	3c 63 00 01 	addis   r3,r3,1
   1c:	39 20 00 01 	li      r9,1
   20:	7d 24 20 30 	slw     r4,r9,r4
   24:	70 89 08 93 	andi.   r9,r4,2195
   28:	41 82 00 34 	beq     5c <__cvdso_clock_getres_common+0x5c>
   2c:	81 23 08 c8 	lwz     r9,2248(r3)
   30:	39 40 00 00 	li      r10,0
   34:	2c 05 00 00 	cmpwi   r5,0
   38:	41 82 00 1c 	beq     54 <__cvdso_clock_getres_common+0x54>
   3c:	38 c0 00 00 	li      r6,0
   40:	38 e0 00 00 	li      r7,0
   44:	91 45 00 08 	stw     r10,8(r5)
   48:	91 25 00 0c 	stw     r9,12(r5)
   4c:	90 c5 00 00 	stw     r6,0(r5)
   50:	90 e5 00 04 	stw     r7,4(r5)
   54:	38 60 00 01 	li      r3,1
   58:	48 00 00 20 	b       78 <__cvdso_clock_getres_common+0x78>
   5c:	70 89 00 60 	andi.   r9,r4,96
   60:	40 82 00 20 	bne     80 <__cvdso_clock_getres_common+0x80>
   64:	74 84 00 ff 	andis.  r4,r4,255
   68:	38 60 00 00 	li      r3,0
   6c:	39 40 00 00 	li      r10,0
   70:	39 20 00 01 	li      r9,1
   74:	40 82 ff c0 	bne     34 <__cvdso_clock_getres_common+0x34>
   78:	54 63 07 fe 	clrlwi  r3,r3,31
   7c:	4e 80 00 20 	blr
   80:	3d 20 00 0f 	lis     r9,15
   84:	39 40 00 00 	li      r10,0
   88:	61 29 42 40 	ori     r9,r9,16960
   8c:	4b ff ff a8 	b       34 <__cvdso_clock_getres_common+0x34>
   90:	38 60 00 00 	li      r3,0
   94:	4b ff ff e4 	b       78 <__cvdso_clock_getres_common+0x78>

000007c0 <__c_kernel_clock_getres>:
  7c0:	94 21 ff d0 	stwu    r1,-48(r1)
  7c4:	7c 08 02 a6 	mflr    r0
  7c8:	bf a1 00 24 	stmw    r29,36(r1)
  7cc:	7c 7e 1b 78 	mr      r30,r3
  7d0:	7c bd 2b 78 	mr      r29,r5
  7d4:	7c 9f 23 78 	mr      r31,r4
  7d8:	38 a0 00 10 	li      r5,16
  7dc:	90 01 00 34 	stw     r0,52(r1)
  7e0:	38 80 00 00 	li      r4,0
  7e4:	38 61 00 08 	addi    r3,r1,8
  7e8:	48 00 00 01 	bl      7e8 <__c_kernel_clock_getres+0x28>
			7e8: R_PPC_REL24	memset
  7ec:	7f c4 f3 78 	mr      r4,r30
  7f0:	7f a3 eb 78 	mr      r3,r29
  7f4:	38 a1 00 08 	addi    r5,r1,8
  7f8:	4b ff f8 09 	bl      0 <__cvdso_clock_getres_common>
  7fc:	2c 03 00 00 	cmpwi   r3,0
  800:	40 82 00 24 	bne     824 <__c_kernel_clock_getres+0x64>
  804:	38 00 00 f7 	li      r0,247
  808:	7f c3 f3 78 	mr      r3,r30
  80c:	7f e4 fb 78 	mr      r4,r31
  810:	44 00 00 02 	sc
  814:	40 e3 00 08 	bns+    81c <__c_kernel_clock_getres+0x5c>
  818:	7c 63 00 d0 	neg     r3,r3
  81c:	39 61 00 30 	addi    r11,r1,48
  820:	48 00 00 00 	b       820 <__c_kernel_clock_getres+0x60>
			820: R_PPC_REL24	_restgpr_29_x
  824:	2c 1f 00 00 	cmpwi   r31,0
  828:	41 82 00 14 	beq     83c <__c_kernel_clock_getres+0x7c>
  82c:	81 21 00 0c 	lwz     r9,12(r1)
  830:	91 3f 00 00 	stw     r9,0(r31)
  834:	81 21 00 14 	lwz     r9,20(r1)
  838:	91 3f 00 04 	stw     r9,4(r31)
  83c:	38 60 00 00 	li      r3,0
  840:	4b ff ff dc 	b       81c <__c_kernel_clock_getres+0x5c>

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

Christophe


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 11:31             ` Christophe Leroy (CS GROUP)
@ 2026-01-22 11:41               ` Thomas Weißschuh
  2026-01-22 13:30                 ` Christophe Leroy (CS GROUP)
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Weißschuh @ 2026-01-22 11:41 UTC (permalink / raw)
  To: Christophe Leroy (CS GROUP)
  Cc: Sverdlin, Alexander, npiggin@gmail.com, luto@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] powerpc/vdso: Provide clock_getres_time64()
  2026-01-22 11:41               ` Thomas Weißschuh
@ 2026-01-22 13:30                 ` Christophe Leroy (CS GROUP)
  0 siblings, 0 replies; 14+ messages in thread
From: Christophe Leroy (CS GROUP) @ 2026-01-22 13:30 UTC (permalink / raw)
  To: Thomas Weißschuh
  Cc: Sverdlin, Alexander, npiggin@gmail.com, luto@kernel.org,
	maddy@linux.ibm.com, tglx@kernel.org, mpe@ellerman.id.au,
	vincenzo.frascino@arm.com, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org



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:
>> 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@linutronix.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%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.
>>>>>>
>>>>>>      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.

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


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2026-01-22 13:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-14  7:26 [PATCH] powerpc/vdso: Provide clock_getres_time64() Thomas Weißschuh
2026-01-14  8:27 ` Christophe Leroy (CS GROUP)
2026-01-22  9:39 ` Sverdlin, Alexander
2026-01-22  9:50   ` Thomas Weißschuh
2026-01-22 10:00     ` Sverdlin, Alexander
2026-01-22 10:27     ` Christophe Leroy (CS GROUP)
2026-01-22 10:49       ` Thomas Weißschuh
2026-01-22 10:58         ` Christophe Leroy (CS GROUP)
2026-01-22 11:07           ` Thomas Weißschuh
2026-01-22 11:31             ` Christophe Leroy (CS GROUP)
2026-01-22 11:41               ` Thomas Weißschuh
2026-01-22 13:30                 ` Christophe Leroy (CS GROUP)
2026-01-22 10:49       ` Christophe Leroy (CS GROUP)
2026-01-22  9:53   ` Christophe Leroy (CS GROUP)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox