[PATCH 0/7] vDSO: Respect COMPAT_32BIT_TIME

[PATCH 0/7] vDSO: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

I also tried to introduce some helpers to avoid much of the ifdeffery,
but due to the high variance in the architecture-specific glue code
these would need to handle they ended up being worse than the current
proposal.

As a side-effect this will make the self-tests more reliable,
as there is now always a matching syscall available for each vDSO function.

clock_gettime_time64() was only introduced in v6.19, so libc implementations
are likely not using it yet.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (7):
      x86/vdso: Respect COMPAT_32BIT_TIME
      ARM: VDSO: Respect COMPAT_32BIT_TIME
      arm64: vdso32: Respect COMPAT_32BIT_TIME
      powerpc/vdso: Respect COMPAT_32BIT_TIME
      MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL
      MIPS: VDSO: Respect COMPAT_32BIT_TIME
      vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions

 arch/arm/vdso/vdso.lds.S                    |  4 +++-
 arch/arm/vdso/vgettimeofday.c               | 14 ++++++------
 arch/arm64/kernel/vdso32/vdso.lds.S         |  4 +++-
 arch/arm64/kernel/vdso32/vgettimeofday.c    | 14 ++++++------
 arch/mips/Kconfig                           |  3 ---
 arch/mips/vdso/vdso.lds.S                   |  6 +++---
 arch/mips/vdso/vgettimeofday.c              | 33 +++++++----------------------
 arch/powerpc/kernel/vdso/gettimeofday.S     |  6 ++++++
 arch/powerpc/kernel/vdso/vdso32.lds.S       | 10 +++++----
 arch/powerpc/kernel/vdso/vgettimeofday.c    | 16 ++++++++------
 arch/x86/entry/vdso/common/vclock_gettime.c | 20 ++++++++++-------
 arch/x86/entry/vdso/vdso32/vdso32.lds.S     |  4 +++-
 lib/vdso/gettimeofday.c                     |  8 +++++++
 13 files changed, 78 insertions(+), 64 deletions(-)
---
base-commit: 328b128e8fe2ae981900c1f38b3b9c75c586455e
change-id: 20260113-vdso-compat_32bit_time-e808763e976a

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

[PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/x86/entry/vdso/common/vclock_gettime.c | 20 ++++++++++++--------
 arch/x86/entry/vdso/vdso32/vdso32.lds.S     |  4 +++-
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/x86/entry/vdso/common/vclock_gettime.c b/arch/x86/entry/vdso/common/vclock_gettime.c
index 027b7e88d753..664d91437f45 100644
--- a/arch/x86/entry/vdso/common/vclock_gettime.c
+++ b/arch/x86/entry/vdso/common/vclock_gettime.c
@@ -23,12 +23,14 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
 int gettimeofday(struct __kernel_old_timeval *, struct timezone *)
 	__attribute__((weak, alias("__vdso_gettimeofday")));
 
+#if defined(__x86_64__) || defined(CONFIG_COMPAT_32BIT_TIME)
 __kernel_old_time_t __vdso_time(__kernel_old_time_t *t)
 {
 	return __cvdso_time(t);
 }
 
 __kernel_old_time_t time(__kernel_old_time_t *t)	__attribute__((weak, alias("__vdso_time")));
+#endif /* CONFIG_COMPAT_32BIT_TIME */
 
 
 #if defined(CONFIG_X86_64) && !defined(BUILD_VDSO32_64)
@@ -51,6 +53,7 @@ int clock_getres(clockid_t, struct __kernel_timespec *)
 
 #else
 /* i386 only */
+#ifdef CONFIG_COMPAT_32BIT_TIME
 int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
 {
 	return __cvdso_clock_gettime32(clock, ts);
@@ -59,14 +62,6 @@ int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
 int clock_gettime(clockid_t, struct old_timespec32 *)
 	__attribute__((weak, alias("__vdso_clock_gettime")));
 
-int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts)
-{
-	return __cvdso_clock_gettime(clock, ts);
-}
-
-int clock_gettime64(clockid_t, struct __kernel_timespec *)
-	__attribute__((weak, alias("__vdso_clock_gettime64")));
-
 int __vdso_clock_getres(clockid_t clock, struct old_timespec32 *res)
 {
 	return __cvdso_clock_getres_time32(clock, res);
@@ -74,6 +69,15 @@ int __vdso_clock_getres(clockid_t clock, struct old_timespec32 *res)
 
 int clock_getres(clockid_t, struct old_timespec32 *)
 	__attribute__((weak, alias("__vdso_clock_getres")));
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+
+int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts)
+{
+	return __cvdso_clock_gettime(clock, ts);
+}
+
+int clock_gettime64(clockid_t, struct __kernel_timespec *)
+	__attribute__((weak, alias("__vdso_clock_gettime64")));
 
 int __vdso_clock_getres_time64(clockid_t clock, struct __kernel_timespec *ts)
 {
diff --git a/arch/x86/entry/vdso/vdso32/vdso32.lds.S b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
index 55554f80d930..012bc3a62aca 100644
--- a/arch/x86/entry/vdso/vdso32/vdso32.lds.S
+++ b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
@@ -23,10 +23,12 @@ VERSION
 {
 	LINUX_2.6 {
 	global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
 		__vdso_clock_gettime;
-		__vdso_gettimeofday;
 		__vdso_time;
 		__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+		__vdso_gettimeofday;
 		__vdso_clock_gettime64;
 		__vdso_clock_getres_time64;
 		__vdso_getcpu;

-- 
2.53.0

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 09:51, Arnd Bergmann wrote:
> On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
>> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
>> provide any 32-bit time related functionality. This is the intended
>> effect of the kconfig option and also the fallback system calls would
>> also not be implemented.
>>
>> Currently the kconfig option does not affect the gettimeofday() syscall,
>> so also keep that in the vDSO.
>>
>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Actually, I need to revise that. I think gettimeofday() should be
guarded by CONFIG_COMPAT_32BIT_TIME for both the syscall and the
vdso. Looking back at the history, I see that we added the #ifdef
for each syscall we modified to have both time32 and time64 version.

The thing about gettimeofday() and time() is that they don't have
a 64-bit version and libc implementations are expected to call
clock_gettime() instead. The result was that there was never a
patch to turn the off either.

     Arnd

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Fri, Feb 27, 2026 at 09:58:35AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 27, 2026, at 09:51, Arnd Bergmann wrote:
> > On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> >> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> >> provide any 32-bit time related functionality. This is the intended
> >> effect of the kconfig option and also the fallback system calls would
> >> also not be implemented.
> >>
> >> Currently the kconfig option does not affect the gettimeofday() syscall,
> >> so also keep that in the vDSO.
> >>
> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> >
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> Actually, I need to revise that. I think gettimeofday() should be
> guarded by CONFIG_COMPAT_32BIT_TIME for both the syscall and the
> vdso. Looking back at the history, I see that we added the #ifdef
> for each syscall we modified to have both time32 and time64 version.
> 
> The thing about gettimeofday() and time() is that they don't have
> a 64-bit version and libc implementations are expected to call
> clock_gettime() instead. The result was that there was never a
> patch to turn the off either.

gettimeofday() is currently the only way to get the timezone of the kernel.
But I guess this is a legacy thing anyways. If you say we should drop it,
let's drop it.


Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On 2026-02-27 01:34, Thomas Weißschuh wrote:
>>>
>> The thing about gettimeofday() and time() is that they don't have
>> a 64-bit version and libc implementations are expected to call
>> clock_gettime() instead. The result was that there was never a
>> patch to turn the off either.
> 
> gettimeofday() is currently the only way to get the timezone of the kernel.
> But I guess this is a legacy thing anyways. If you say we should drop it,
> let's drop it.
> 

The time zone in the kernel has never worked anyway, as it would require the
kernel to contain at least the forward portion of the zoneinfo/tzdata table in
order to actually work correctly. The only plausible use of it would be for
local time-based filesystems like FAT, but I don't think we bother.

A bigger question is whether or not we should omit these from the vDSO
completely (potentially causing link failures) or replace them with stubs
returning -ENOSYS.

	-hpa

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
> On 2026-02-27 01:34, Thomas Weißschuh wrote:
>>>>
>>> The thing about gettimeofday() and time() is that they don't have
>>> a 64-bit version and libc implementations are expected to call
>>> clock_gettime() instead. The result was that there was never a
>>> patch to turn the off either.
>> 
>> gettimeofday() is currently the only way to get the timezone of the kernel.
>> But I guess this is a legacy thing anyways. If you say we should drop it,
>> let's drop it.
>> 
>
> The time zone in the kernel has never worked anyway, as it would require the
> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
> order to actually work correctly. The only plausible use of it would be for
> local time-based filesystems like FAT, but I don't think we bother.
>
> A bigger question is whether or not we should omit these from the vDSO
> completely (potentially causing link failures) or replace them with stubs
> returning -ENOSYS.

I see no harm in keeping gettimeofday() in the vdso when
COMPAT_32BIT_TIME is turned on, as existing code will call it
no matter whether it's in the vdso or the syscall.

Equally, I see no point in having either version of
gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
disabled, as clearly anything calling it would pass incorrect
data for times past 2038.

Neither glibc nor musl support actually returning the kernel
timezone to callers of gettimeofday in modern versions that
support time64 syscalls.

      Arnd

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On March 3, 2026 12:50:33 PM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
>> On 2026-02-27 01:34, Thomas Weißschuh wrote:
>>>>>
>>>> The thing about gettimeofday() and time() is that they don't have
>>>> a 64-bit version and libc implementations are expected to call
>>>> clock_gettime() instead. The result was that there was never a
>>>> patch to turn the off either.
>>> 
>>> gettimeofday() is currently the only way to get the timezone of the kernel.
>>> But I guess this is a legacy thing anyways. If you say we should drop it,
>>> let's drop it.
>>> 
>>
>> The time zone in the kernel has never worked anyway, as it would require the
>> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
>> order to actually work correctly. The only plausible use of it would be for
>> local time-based filesystems like FAT, but I don't think we bother.
>>
>> A bigger question is whether or not we should omit these from the vDSO
>> completely (potentially causing link failures) or replace them with stubs
>> returning -ENOSYS.
>
>I see no harm in keeping gettimeofday() in the vdso when
>COMPAT_32BIT_TIME is turned on, as existing code will call it
>no matter whether it's in the vdso or the syscall.
>
>Equally, I see no point in having either version of
>gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
>disabled, as clearly anything calling it would pass incorrect
>data for times past 2038.
>
>Neither glibc nor musl support actually returning the kernel
>timezone to callers of gettimeofday in modern versions that
>support time64 syscalls.
>
>      Arnd
>

That wasn't the point. The point was what kind of error behavior we want.

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Tue, Mar 3, 2026, at 22:00, H. Peter Anvin wrote:
> On March 3, 2026 12:50:33 PM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>>On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
>>> A bigger question is whether or not we should omit these from the vDSO
>>> completely (potentially causing link failures) or replace them with stubs
>>> returning -ENOSYS.
>>
>>I see no harm in keeping gettimeofday() in the vdso when
>>COMPAT_32BIT_TIME is turned on, as existing code will call it
>>no matter whether it's in the vdso or the syscall.
>
> That wasn't the point. The point was what kind of error behavior we want.

I see. I would argue here that a link failure is actually the best
case then: the entire point of CONFIG_COMPAT_32BIT_TIME=n is to
enforce the fail-early case, as opposed to silent data corruption
after (now) 12 years of operation.

I don't think there is an actual link failure here, as dl_vdso_vsym()
resolves it at runtime by glibc (when using time32), while musl
doesn't use __vdso_gettimeofday at all.

      Arnd

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On 2026-03-03 13:27, Arnd Bergmann wrote:
> 
> I see. I would argue here that a link failure is actually the best
> case then: the entire point of CONFIG_COMPAT_32BIT_TIME=n is to
> enforce the fail-early case, as opposed to silent data corruption
> after (now) 12 years of operation.
> 
> I don't think there is an actual link failure here, as dl_vdso_vsym()
> resolves it at runtime by glibc (when using time32), while musl
> doesn't use __vdso_gettimeofday at all.
> 

Well, the former is a link failure -- just one handled reasonably gracefully.
A library that really wants a fallback can presumably also avoid the problem
by provide a weak reference for the fallback.

	-hpa

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Tue, Mar 03, 2026 at 09:50:33PM +0100, Arnd Bergmann wrote:
> On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
> > On 2026-02-27 01:34, Thomas Weißschuh wrote:
> >>>>
> >>> The thing about gettimeofday() and time() is that they don't have
> >>> a 64-bit version and libc implementations are expected to call
> >>> clock_gettime() instead. The result was that there was never a
> >>> patch to turn the off either.
> >> 
> >> gettimeofday() is currently the only way to get the timezone of the kernel.
> >> But I guess this is a legacy thing anyways. If you say we should drop it,
> >> let's drop it.
> >> 
> >
> > The time zone in the kernel has never worked anyway, as it would require the
> > kernel to contain at least the forward portion of the zoneinfo/tzdata table in
> > order to actually work correctly. The only plausible use of it would be for
> > local time-based filesystems like FAT, but I don't think we bother.
> >
> > A bigger question is whether or not we should omit these from the vDSO
> > completely (potentially causing link failures) or replace them with stubs
> > returning -ENOSYS.
> 
> I see no harm in keeping gettimeofday() in the vdso when
> COMPAT_32BIT_TIME is turned on, as existing code will call it
> no matter whether it's in the vdso or the syscall.

We would still always keep them for 64-bit ABIs, right?

> Equally, I see no point in having either version of
> gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
> disabled, as clearly anything calling it would pass incorrect
> data for times past 2038.

Should we also drop the syscalls in these cases?
We will need to keep settimeofday() in some form to support the
timewarping call done by init.

Recap/Proposal:

* Keep the gettimeofday()/time() syscalls when they are y2038 safe or
  CONFIG_COMPAT_32BIT_TIME is set.
* Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
  set, reject passing any 'tv' argument where it may not be y2038 safe.
* The vDSO functions always mirror the systemcall availability.


Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Fri, Apr 10, 2026, at 09:24, Thomas Weißschuh wrote:
> On Tue, Mar 03, 2026 at 09:50:33PM +0100, Arnd Bergmann wrote:
>> On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
>> >
>> > The time zone in the kernel has never worked anyway, as it would require the
>> > kernel to contain at least the forward portion of the zoneinfo/tzdata table in
>> > order to actually work correctly. The only plausible use of it would be for
>> > local time-based filesystems like FAT, but I don't think we bother.
>> >
>> > A bigger question is whether or not we should omit these from the vDSO
>> > completely (potentially causing link failures) or replace them with stubs
>> > returning -ENOSYS.
>> 
>> I see no harm in keeping gettimeofday() in the vdso when
>> COMPAT_32BIT_TIME is turned on, as existing code will call it
>> no matter whether it's in the vdso or the syscall.
>
> We would still always keep them for 64-bit ABIs, right?

Yes, I think we can't easily change that now. It was probably
a mistake to keep them in the generic syscall table after
we dropped them for 32-bit non-time32 targets, so riscv64
and loongarch should have not had these in the first place.

>> Equally, I see no point in having either version of
>> gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
>> disabled, as clearly anything calling it would pass incorrect
>> data for times past 2038.
>
> Should we also drop the syscalls in these cases?
> We will need to keep settimeofday() in some form to support the
> timewarping call done by init.
>
> Recap/Proposal:
>
> * Keep the gettimeofday()/time() syscalls when they are y2038 safe or
>   CONFIG_COMPAT_32BIT_TIME is set.
> * The vDSO functions always mirror the systemcall availability.

These sound good.

> * Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
>   set, reject passing any 'tv' argument where it may not be y2038 safe.

This sounds wrong to me now: the case I'm worried about is a 32-bit
system calling settimeofday() based on the value of an RTC or NTP.
The idea of CONFIG_COMPAT_32BIT_TIME=n is to catch this by causing
an intentional ENOSYS error even for valid times, so it doesn't
suddenly start breaking in 2038.

     Arnd

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Mon, Apr 13, 2026 at 05:59:52PM +0200, Arnd Bergmann wrote:
> On Fri, Apr 10, 2026, at 09:24, Thomas Weißschuh wrote:

(...)

> > Recap/Proposal:

(...)

> > * Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
> >   set, reject passing any 'tv' argument where it may not be y2038 safe.
> 
> This sounds wrong to me now: the case I'm worried about is a 32-bit
> system calling settimeofday() based on the value of an RTC or NTP.
> The idea of CONFIG_COMPAT_32BIT_TIME=n is to catch this by causing
> an intentional ENOSYS error even for valid times, so it doesn't
> suddenly start breaking in 2038.

This is what I meant with "where it *may*" be not y2038 safe.
Even if the value fits, the call would be rejected.
My wording was crappy indeed, though.

In code:

if (tv && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME) && sizeof(tv->tv_sec) < 8) {
	pr_warn_once(...);
	return -EINVAL;
}

Or maybe drop the EINVAL but still emit a warning. That warning would be
useful for gettimeofday(), too.

Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Arnd Bergmann]

On Mon, Apr 13, 2026, at 18:13, Thomas Weißschuh wrote:
> On Mon, Apr 13, 2026 at 05:59:52PM +0200, Arnd Bergmann wrote:
>> On Fri, Apr 10, 2026, at 09:24, Thomas Weißschuh wrote:
>
>> > * Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
>> >   set, reject passing any 'tv' argument where it may not be y2038 safe.
>> 
>> This sounds wrong to me now: the case I'm worried about is a 32-bit
>> system calling settimeofday() based on the value of an RTC or NTP.
>> The idea of CONFIG_COMPAT_32BIT_TIME=n is to catch this by causing
>> an intentional ENOSYS error even for valid times, so it doesn't
>> suddenly start breaking in 2038.
>
> This is what I meant with "where it *may*" be not y2038 safe.
> Even if the value fits, the call would be rejected.

Ok, that's fine then.

> My wording was crappy indeed, though.
>
> In code:
>
> if (tv && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME) && sizeof(tv->tv_sec) < 8) {
> 	pr_warn_once(...);
> 	return -EINVAL;
> }
>
> Or maybe drop the EINVAL but still emit a warning. That warning would be
> useful for gettimeofday(), too.

We discussed this during the original y2038 work and decided
at the time to not have those warnings for syscalls. We could
bring that back, but I think I would want one level of abstraction
there and control this using a global Kconfig switch for all
syscalls as well as ioctl commands that could use such a check.

     Arnd

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Mon, Apr 13, 2026 at 06:57:57PM +0200, Arnd Bergmann wrote:
> On Mon, Apr 13, 2026, at 18:13, Thomas Weißschuh wrote:

(...)

> > if (tv && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME) && sizeof(tv->tv_sec) < 8) {
> > 	pr_warn_once(...);
> > 	return -EINVAL;
> > }
> >
> > Or maybe drop the EINVAL but still emit a warning. That warning would be
> > useful for gettimeofday(), too.
> 
> We discussed this during the original y2038 work and decided
> at the time to not have those warnings for syscalls. We could
> bring that back, but I think I would want one level of abstraction
> there and control this using a global Kconfig switch for all
> syscalls as well as ioctl commands that could use such a check.

I'd like to avoid another kconfig option. Linus doesn't sound too
excited about those [0].


Thomas

[0] https://lore.kernel.org/lkml/CAHk-=whigg3hvOy7c1j1MXFy6o6CHp0g4Tc3Y-MAk+XDssHU0A@mail.gmail.com/

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Tue, Mar 03, 2026 at 10:11:52AM -0800, H. Peter Anvin wrote:
> On 2026-02-27 01:34, Thomas Weißschuh wrote:
> >>>
> >> The thing about gettimeofday() and time() is that they don't have
> >> a 64-bit version and libc implementations are expected to call
> >> clock_gettime() instead. The result was that there was never a
> >> patch to turn the off either.
> > 
> > gettimeofday() is currently the only way to get the timezone of the kernel.
> > But I guess this is a legacy thing anyways. If you say we should drop it,
> > let's drop it.
> > 
> 
> The time zone in the kernel has never worked anyway, as it would require the
> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
> order to actually work correctly. The only plausible use of it would be for
> local time-based filesystems like FAT, but I don't think we bother.

sys_tz is currently used by a bunch of drivers and filesystems (including FAT).
It is also used when writing to the RTC.

> A bigger question is whether or not we should omit these from the vDSO
> completely (potentially causing link failures) or replace them with stubs
> returning -ENOSYS.

I am a bit confused here. You mention 'link failures' and in another mail
'weak references as fallback'. Both are things that happen during linking
('link failures' could also be interpreted as failures during loading).
Somewhere else someone also mentioned the vDSO to be 'linkable'.
But as far as I understand, only libc interprets the vDSO, it completely
bypasses both the linker and the loader. And libc already does graceful
fallbacks to the regular systemcalls if the vDSO is missing completely or
lacks one of the functions, as both cases may happen on normal systems.

What am I missing?


Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On March 3, 2026 11:35:52 PM PST, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
>On Tue, Mar 03, 2026 at 10:11:52AM -0800, H. Peter Anvin wrote:
>> On 2026-02-27 01:34, Thomas Weißschuh wrote:
>> >>>
>> >> The thing about gettimeofday() and time() is that they don't have
>> >> a 64-bit version and libc implementations are expected to call
>> >> clock_gettime() instead. The result was that there was never a
>> >> patch to turn the off either.
>> > 
>> > gettimeofday() is currently the only way to get the timezone of the kernel.
>> > But I guess this is a legacy thing anyways. If you say we should drop it,
>> > let's drop it.
>> > 
>> 
>> The time zone in the kernel has never worked anyway, as it would require the
>> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
>> order to actually work correctly. The only plausible use of it would be for
>> local time-based filesystems like FAT, but I don't think we bother.
>
>sys_tz is currently used by a bunch of drivers and filesystems (including FAT).
>It is also used when writing to the RTC.
>
>> A bigger question is whether or not we should omit these from the vDSO
>> completely (potentially causing link failures) or replace them with stubs
>> returning -ENOSYS.
>
>I am a bit confused here. You mention 'link failures' and in another mail
>'weak references as fallback'. Both are things that happen during linking
>('link failures' could also be interpreted as failures during loading).
>Somewhere else someone also mentioned the vDSO to be 'linkable'.
>But as far as I understand, only libc interprets the vDSO, it completely
>bypasses both the linker and the loader. And libc already does graceful
>fallbacks to the regular systemcalls if the vDSO is missing completely or
>lacks one of the functions, as both cases may happen on normal systems.
>
>What am I missing?
>
>
>Thomas

Weak references would be a way to work around the link failures. 

At least in practice the RTC timezone should be managed from user space. 

As I said, managing time zone information in the kernel correctly (beyond "right now", which can be dealt with by an external daemon on discontinuities; maybe systemd does that) would require far more than settimeofday() provides.

Downloading a binary zoneinfo (TZif2) blob into the kernel certainly isn't out of the question and would solve this issue correctly once and for all; a single zoneinfo blob is (currently) slightly below 4K in size, and the stock interpreter is about 14K, which, even if we can't strip out any additional functionality we don't need, is more or less a drop in the bucket these days.

    -hpa

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Wed, Mar 04, 2026 at 10:30:34AM -0800, H. Peter Anvin wrote:
> On March 3, 2026 11:35:52 PM PST, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
> >On Tue, Mar 03, 2026 at 10:11:52AM -0800, H. Peter Anvin wrote:
> >> On 2026-02-27 01:34, Thomas Weißschuh wrote:
> >> >>>
> >> >> The thing about gettimeofday() and time() is that they don't have
> >> >> a 64-bit version and libc implementations are expected to call
> >> >> clock_gettime() instead. The result was that there was never a
> >> >> patch to turn the off either.
> >> > 
> >> > gettimeofday() is currently the only way to get the timezone of the kernel.
> >> > But I guess this is a legacy thing anyways. If you say we should drop it,
> >> > let's drop it.
> >> > 
> >> 
> >> The time zone in the kernel has never worked anyway, as it would require the
> >> kernel to contain at least the forward portion of the zoneinfo/tzdata table in
> >> order to actually work correctly. The only plausible use of it would be for
> >> local time-based filesystems like FAT, but I don't think we bother.
> >
> >sys_tz is currently used by a bunch of drivers and filesystems (including FAT).
> >It is also used when writing to the RTC.
> >
> >> A bigger question is whether or not we should omit these from the vDSO
> >> completely (potentially causing link failures) or replace them with stubs
> >> returning -ENOSYS.
> >
> >I am a bit confused here. You mention 'link failures' and in another mail
> >'weak references as fallback'. Both are things that happen during linking
> >('link failures' could also be interpreted as failures during loading).
> >Somewhere else someone also mentioned the vDSO to be 'linkable'.
> >But as far as I understand, only libc interprets the vDSO, it completely
> >bypasses both the linker and the loader. And libc already does graceful
> >fallbacks to the regular systemcalls if the vDSO is missing completely or
> >lacks one of the functions, as both cases may happen on normal systems.
> >
> >What am I missing?

> Weak references would be a way to work around the link failures. 

I am still not sure where "the link failures" should be coming from.
The only sense I can make out of it, is if somebody manually and directly links
to vdso.so. Like in the following example:

$ cat test.c 
#include <stdio.h>

#include <linux/time.h>

int __vdso_clock_gettime(__kernel_clockid_t clock, struct __kernel_timespec *ts);

int main(void)
{
	struct __kernel_timespec ts;
	int ret;

	printf("__vdso_clock_gettime=%p\n", __vdso_clock_gettime);

	ret = __vdso_clock_gettime(CLOCK_REALTIME, &ts);
	printf("ret=%d\n", ret);
}
$ gcc test.c /lib/modules/$(uname -r)/vdso/vdso64.so
$ ./a.out 
__vdso_clock_gettime=0x7ff6ba2eeb80
ret=0

This actually works on glibc (not on musl). But it is highly non-standard and
relies on multiple implementation details. Furthermore it can fail to run on
systems without a vDSO, as mentioned before.

Is this the usage pattern you have in mind?
Do you know of anybody doing things this way?


(...)


Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On 2026-03-05 01:24, Thomas Weißschuh wrote:
> 
>> Weak references would be a way to work around the link failures. 
> 
> I am still not sure where "the link failures" should be coming from.
> The only sense I can make out of it, is if somebody manually and directly links
> to vdso.so. Like in the following example:
> 
> $ cat test.c 
> #include <stdio.h>
> 
> #include <linux/time.h>
> 
> int __vdso_clock_gettime(__kernel_clockid_t clock, struct __kernel_timespec *ts);
> 
> int main(void)
> {
> 	struct __kernel_timespec ts;
> 	int ret;
> 
> 	printf("__vdso_clock_gettime=%p\n", __vdso_clock_gettime);
> 
> 	ret = __vdso_clock_gettime(CLOCK_REALTIME, &ts);
> 	printf("ret=%d\n", ret);
> }
> $ gcc test.c /lib/modules/$(uname -r)/vdso/vdso64.so
> $ ./a.out 
> __vdso_clock_gettime=0x7ff6ba2eeb80
> ret=0
> 
> This actually works on glibc (not on musl). But it is highly non-standard and
> relies on multiple implementation details. Furthermore it can fail to run on
> systems without a vDSO, as mentioned before.
> 
> Is this the usage pattern you have in mind?
> Do you know of anybody doing things this way?
> 

Yes, and yes, I do.

	-hpa

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

On Thu, Mar 05, 2026 at 03:57:59PM -0800, H. Peter Anvin wrote:
> On 2026-03-05 01:24, Thomas Weißschuh wrote:
> > 
> >> Weak references would be a way to work around the link failures. 
> > 
> > I am still not sure where "the link failures" should be coming from.
> > The only sense I can make out of it, is if somebody manually and directly links
> > to vdso.so. Like in the following example:

(...)

> > This actually works on glibc (not on musl). But it is highly non-standard and
> > relies on multiple implementation details. Furthermore it can fail to run on
> > systems without a vDSO, as mentioned before.
> > 
> > Is this the usage pattern you have in mind?
> > Do you know of anybody doing things this way?
> > 
> 
> Yes, and yes, I do.

Thanks.

Do you know why it is done this way? Are these applications public and
if so, could you point me to them?
In case we stub out the vDSO functions with ENOSYS, would these
applications be able to handle that error gracefully?

Personally I am still in favor of removing these functions completely
when !COMPAT_32BIT_TIME.


Thomas

Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME

[H. Peter Anvin]

On March 6, 2026 1:42:25 AM PST, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
>On Thu, Mar 05, 2026 at 03:57:59PM -0800, H. Peter Anvin wrote:
>> On 2026-03-05 01:24, Thomas Weißschuh wrote:
>> > 
>> >> Weak references would be a way to work around the link failures. 
>> > 
>> > I am still not sure where "the link failures" should be coming from.
>> > The only sense I can make out of it, is if somebody manually and directly links
>> > to vdso.so. Like in the following example:
>
>(...)
>
>> > This actually works on glibc (not on musl). But it is highly non-standard and
>> > relies on multiple implementation details. Furthermore it can fail to run on
>> > systems without a vDSO, as mentioned before.
>> > 
>> > Is this the usage pattern you have in mind?
>> > Do you know of anybody doing things this way?
>> > 
>> 
>> Yes, and yes, I do.
>
>Thanks.
>
>Do you know why it is done this way? Are these applications public and
>if so, could you point me to them?
>In case we stub out the vDSO functions with ENOSYS, would these
>applications be able to handle that error gracefully?
>
>Personally I am still in favor of removing these functions completely
>when !COMPAT_32BIT_TIME.
>
>
>Thomas

I think I agree with you (and sadly, no, I can't point at them directly.)

[PATCH 2/7] ARM: VDSO: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/arm/vdso/vdso.lds.S      |  4 +++-
 arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm/vdso/vdso.lds.S b/arch/arm/vdso/vdso.lds.S
index 74d8d8bc8a40..766aa632e16c 100644
--- a/arch/arm/vdso/vdso.lds.S
+++ b/arch/arm/vdso/vdso.lds.S
@@ -70,9 +70,11 @@ VERSION
 {
 	LINUX_2.6 {
 	global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
 		__vdso_clock_gettime;
-		__vdso_gettimeofday;
 		__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+		__vdso_gettimeofday;
 		__vdso_clock_gettime64;
 		__vdso_clock_getres_time64;
 	local: *;
diff --git a/arch/arm/vdso/vgettimeofday.c b/arch/arm/vdso/vgettimeofday.c
index f7a2f5dc2fdc..31702f2f0547 100644
--- a/arch/arm/vdso/vgettimeofday.c
+++ b/arch/arm/vdso/vgettimeofday.c
@@ -10,17 +10,19 @@
 #include <asm/unwind.h>
 #include <vdso/gettime.h>
 
+#ifdef CONFIG_COMPAT_32BIT_TIME
 int __vdso_clock_gettime(clockid_t clock,
 			 struct old_timespec32 *ts)
 {
 	return __cvdso_clock_gettime32(clock, ts);
 }
 
-int __vdso_clock_gettime64(clockid_t clock,
-			   struct __kernel_timespec *ts)
+int __vdso_clock_getres(clockid_t clock_id,
+			struct old_timespec32 *res)
 {
-	return __cvdso_clock_gettime(clock, ts);
+	return __cvdso_clock_getres_time32(clock_id, res);
 }
+#endif /* CONFIG_COMPAT_32BIT_TIME */
 
 int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 			struct timezone *tz)
@@ -28,10 +30,10 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 	return __cvdso_gettimeofday(tv, tz);
 }
 
-int __vdso_clock_getres(clockid_t clock_id,
-			struct old_timespec32 *res)
+int __vdso_clock_gettime64(clockid_t clock,
+			   struct __kernel_timespec *ts)
 {
-	return __cvdso_clock_getres_time32(clock_id, res);
+	return __cvdso_clock_gettime(clock, ts);
 }
 
 int __vdso_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res)

-- 
2.53.0

[PATCH 3/7] arm64: vdso32: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/arm64/kernel/vdso32/vdso.lds.S      |  4 +++-
 arch/arm64/kernel/vdso32/vgettimeofday.c | 14 ++++++++------
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/vdso32/vdso.lds.S b/arch/arm64/kernel/vdso32/vdso.lds.S
index c374fb0146f3..ea67f2dba431 100644
--- a/arch/arm64/kernel/vdso32/vdso.lds.S
+++ b/arch/arm64/kernel/vdso32/vdso.lds.S
@@ -82,9 +82,11 @@ VERSION
 {
 	LINUX_2.6 {
 	global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
 		__vdso_clock_gettime;
-		__vdso_gettimeofday;
 		__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+		__vdso_gettimeofday;
 		__vdso_clock_gettime64;
 		__vdso_clock_getres_time64;
 	local: *;
diff --git a/arch/arm64/kernel/vdso32/vgettimeofday.c b/arch/arm64/kernel/vdso32/vgettimeofday.c
index 0c6998ebe491..2e389c0a74df 100644
--- a/arch/arm64/kernel/vdso32/vgettimeofday.c
+++ b/arch/arm64/kernel/vdso32/vgettimeofday.c
@@ -8,17 +8,19 @@
 #define BUILD_VDSO32_64
 #include <vdso/gettime.h>
 
+#ifdef CONFIG_COMPAT_32BIT_TIME
 int __vdso_clock_gettime(clockid_t clock,
 			 struct old_timespec32 *ts)
 {
 	return __cvdso_clock_gettime32(clock, ts);
 }
 
-int __vdso_clock_gettime64(clockid_t clock,
-			   struct __kernel_timespec *ts)
+int __vdso_clock_getres(clockid_t clock_id,
+			struct old_timespec32 *res)
 {
-	return __cvdso_clock_gettime(clock, ts);
+	return __cvdso_clock_getres_time32(clock_id, res);
 }
+#endif /* CONFIG_COMPAT_32BIT_TIME */
 
 int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 			struct timezone *tz)
@@ -26,10 +28,10 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 	return __cvdso_gettimeofday(tv, tz);
 }
 
-int __vdso_clock_getres(clockid_t clock_id,
-			struct old_timespec32 *res)
+int __vdso_clock_gettime64(clockid_t clock,
+			   struct __kernel_timespec *ts)
 {
-	return __cvdso_clock_getres_time32(clock_id, res);
+	return __cvdso_clock_gettime(clock, ts);
 }
 
 int __vdso_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res)

-- 
2.53.0

[PATCH 4/7] powerpc/vdso: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/powerpc/kernel/vdso/gettimeofday.S  |  6 ++++++
 arch/powerpc/kernel/vdso/vdso32.lds.S    | 10 ++++++----
 arch/powerpc/kernel/vdso/vgettimeofday.c | 16 ++++++++++------
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
index 1c8e51691bf8..c8fda56ac520 100644
--- a/arch/powerpc/kernel/vdso/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso/gettimeofday.S
@@ -77,9 +77,11 @@ V_FUNCTION_END(__kernel_gettimeofday)
  * int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp);
  *
  */
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
 V_FUNCTION_BEGIN(__kernel_clock_gettime)
 	cvdso_call __c_kernel_clock_gettime
 V_FUNCTION_END(__kernel_clock_gettime)
+#endif
 
 /*
  * Exact prototype of clock_gettime64()
@@ -99,9 +101,11 @@ V_FUNCTION_END(__kernel_clock_gettime64)
  * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
  *
  */
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
 V_FUNCTION_BEGIN(__kernel_clock_getres)
 	cvdso_call __c_kernel_clock_getres
 V_FUNCTION_END(__kernel_clock_getres)
+#endif
 
 /*
  * Exact prototype of clock_getres_time64()
@@ -122,6 +126,8 @@ V_FUNCTION_END(__kernel_clock_getres_time64)
  * time_t time(time *t);
  *
  */
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
 V_FUNCTION_BEGIN(__kernel_time)
 	cvdso_call __c_kernel_time call_time=1
 V_FUNCTION_END(__kernel_time)
+#endif
diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
index 3f384a2526ae..53fe3796a571 100644
--- a/arch/powerpc/kernel/vdso/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
@@ -119,13 +119,15 @@ VERSION
 {
 	VDSO_VERSION_STRING {
 	global:
-		__kernel_get_syscall_map;
-		__kernel_gettimeofday;
+#ifdef CONFIG_COMPAT_32BIT_TIME
 		__kernel_clock_gettime;
-		__kernel_clock_gettime64;
 		__kernel_clock_getres;
-		__kernel_clock_getres_time64;
 		__kernel_time;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+		__kernel_gettimeofday;
+		__kernel_get_syscall_map;
+		__kernel_clock_gettime64;
+		__kernel_clock_getres_time64;
 		__kernel_get_tbfreq;
 		__kernel_sync_dicache;
 		__kernel_sigtramp32;
diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
index 3c194e1ab562..dfefd13a19e1 100644
--- a/arch/powerpc/kernel/vdso/vgettimeofday.c
+++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
@@ -18,23 +18,25 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct __kernel_timespec *res,
 	return __cvdso_clock_getres_data(vd, clock_id, res);
 }
 #else
+#ifdef CONFIG_COMPAT_32BIT_TIME
 int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts,
 			     const struct vdso_time_data *vd)
 {
 	return __cvdso_clock_gettime32_data(vd, clock, ts);
 }
 
-int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
-			       const struct vdso_time_data *vd)
-{
-	return __cvdso_clock_gettime_data(vd, clock, ts);
-}
-
 int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
 			    const struct vdso_time_data *vd)
 {
 	return __cvdso_clock_getres_time32_data(vd, clock_id, res);
 }
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+
+int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
+			       const struct vdso_time_data *vd)
+{
+	return __cvdso_clock_gettime_data(vd, clock, ts);
+}
 
 int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
 				   const struct vdso_time_data *vd)
@@ -49,7 +51,9 @@ int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz
 	return __cvdso_gettimeofday_data(vd, tv, tz);
 }
 
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
 __kernel_old_time_t __c_kernel_time(__kernel_old_time_t *time, const struct vdso_time_data *vd)
 {
 	return __cvdso_time_data(vd, time);
 }
+#endif

-- 
2.53.0

[PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL

[Thomas Weißschuh]

This configuration option exists so "that we don't provide the symbol
when there's no possibility of there being a usable clocksource".
However it only covers __vdso_gettimeofday() and none of the other vDSO
functions which should be affected by the same circumstances.
As these are more widely used than gettimeofday() and nobody seems to
have had an issue with them so far, drop MIPS_CLOCK_VSYSCALL completely.

The removal of the ifdeffery will also make some upcomming changes
easier to read.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/mips/Kconfig              |  3 ---
 arch/mips/vdso/vdso.lds.S      |  2 --
 arch/mips/vdso/vgettimeofday.c | 20 --------------------
 3 files changed, 25 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index e48b62b4dc48..4c8592fd1556 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1137,9 +1137,6 @@ config CSRC_R4K
 config CSRC_SB1250
 	bool
 
-config MIPS_CLOCK_VSYSCALL
-	def_bool CSRC_R4K || CLKSRC_MIPS_GIC
-
 config GPIO_TXX9
 	select GPIOLIB
 	bool
diff --git a/arch/mips/vdso/vdso.lds.S b/arch/mips/vdso/vdso.lds.S
index 5d08be3a6b85..76b6ad898288 100644
--- a/arch/mips/vdso/vdso.lds.S
+++ b/arch/mips/vdso/vdso.lds.S
@@ -97,9 +97,7 @@ VERSION
 #ifndef CONFIG_MIPS_DISABLE_VDSO
 	global:
 		__vdso_clock_gettime;
-#ifdef CONFIG_MIPS_CLOCK_VSYSCALL
 		__vdso_gettimeofday;
-#endif
 		__vdso_clock_getres;
 #if _MIPS_SIM != _MIPS_SIM_ABI64
 		__vdso_clock_gettime64;
diff --git a/arch/mips/vdso/vgettimeofday.c b/arch/mips/vdso/vgettimeofday.c
index 1d236215e8f6..00f9fcfc327e 100644
--- a/arch/mips/vdso/vgettimeofday.c
+++ b/arch/mips/vdso/vgettimeofday.c
@@ -18,22 +18,12 @@ int __vdso_clock_gettime(clockid_t clock,
 	return __cvdso_clock_gettime32(clock, ts);
 }
 
-#ifdef CONFIG_MIPS_CLOCK_VSYSCALL
-
-/*
- * This is behind the ifdef so that we don't provide the symbol when there's no
- * possibility of there being a usable clocksource, because there's nothing we
- * can do without it. When libc fails the symbol lookup it should fall back on
- * the standard syscall path.
- */
 int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 			struct timezone *tz)
 {
 	return __cvdso_gettimeofday(tv, tz);
 }
 
-#endif /* CONFIG_MIPS_CLOCK_VSYSCALL */
-
 int __vdso_clock_getres(clockid_t clock_id,
 			struct old_timespec32 *res)
 {
@@ -59,22 +49,12 @@ int __vdso_clock_gettime(clockid_t clock,
 	return __cvdso_clock_gettime(clock, ts);
 }
 
-#ifdef CONFIG_MIPS_CLOCK_VSYSCALL
-
-/*
- * This is behind the ifdef so that we don't provide the symbol when there's no
- * possibility of there being a usable clocksource, because there's nothing we
- * can do without it. When libc fails the symbol lookup it should fall back on
- * the standard syscall path.
- */
 int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
 			struct timezone *tz)
 {
 	return __cvdso_gettimeofday(tv, tz);
 }
 
-#endif /* CONFIG_MIPS_CLOCK_VSYSCALL */
-
 int __vdso_clock_getres(clockid_t clock_id,
 			struct __kernel_timespec *res)
 {

-- 
2.53.0

Re: [PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> This configuration option exists so "that we don't provide the symbol
> when there's no possibility of there being a usable clocksource".
> However it only covers __vdso_gettimeofday() and none of the other vDSO
> functions which should be affected by the same circumstances.
> As these are more widely used than gettimeofday() and nobody seems to
> have had an issue with them so far, drop MIPS_CLOCK_VSYSCALL completely.
>
> The removal of the ifdeffery will also make some upcomming changes
> easier to read.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

The #ifdef was originally been added in commit 7d2aa4bb90f5 ("mips:
Fix gettimeofday() in the vdso library") as a bug fix. This may not
have been the correct fix because I don't see how it addressed the
case of a kernel with MIPS_CLOCK_VSYSCALL enabled running on a
CPU without the timer registers, but I think we should try to make
sure that there is no regression from reverting it now.

> -config MIPS_CLOCK_VSYSCALL
> -	def_bool CSRC_R4K || CLKSRC_MIPS_GIC
> -

An easy alternative might be to drop the entire VDSO in
configurations that turn off the gettimeofday vsyscall today:

diff --git a/arch/mips/vdso/Kconfig b/arch/mips/vdso/Kconfig
index 70140248da72..4f6fba9e108f 100644
--- a/arch/mips/vdso/Kconfig
+++ b/arch/mips/vdso/Kconfig
@@ -3,4 +3,4 @@
 # the lack of relocations. As such, we disable the VDSO for microMIPS builds.
 
 config MIPS_DISABLE_VDSO
-	def_bool CPU_MICROMIPS
+	def_bool CPU_MICROMIPS || !(CSRC_R4K || CLKSRC_MIPS_GIC)


    Arnd

Re: [PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL

[Thomas Weißschuh]

On Fri, Feb 27, 2026 at 09:46:23AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> > This configuration option exists so "that we don't provide the symbol
> > when there's no possibility of there being a usable clocksource".
> > However it only covers __vdso_gettimeofday() and none of the other vDSO
> > functions which should be affected by the same circumstances.
> > As these are more widely used than gettimeofday() and nobody seems to
> > have had an issue with them so far, drop MIPS_CLOCK_VSYSCALL completely.
> >
> > The removal of the ifdeffery will also make some upcomming changes
> > easier to read.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> The #ifdef was originally been added in commit 7d2aa4bb90f5 ("mips:
> Fix gettimeofday() in the vdso library") as a bug fix. This may not
> have been the correct fix because I don't see how it addressed the
> case of a kernel with MIPS_CLOCK_VSYSCALL enabled running on a
> CPU without the timer registers, but I think we should try to make
> sure that there is no regression from reverting it now.

I can't make sense out of this commit. The generic vDSO automatically falls
back to the syscall if it can not handle the current clocksource.
There is no explanation *why* this should be broken on MIPS.
It works correctly on my x86 machines.
I will try to reproduce this in QEMU by removing the vDSO capability from
the respective clocksources.

Also vdso_clock_gettime() uses the same codepaths as vdso_gettimeofday()
and apparently that is not broken.

> > -config MIPS_CLOCK_VSYSCALL
> > -	def_bool CSRC_R4K || CLKSRC_MIPS_GIC
> > -
> 
> An easy alternative might be to drop the entire VDSO in
> configurations that turn off the gettimeofday vsyscall today:
> 
> diff --git a/arch/mips/vdso/Kconfig b/arch/mips/vdso/Kconfig
> index 70140248da72..4f6fba9e108f 100644
> --- a/arch/mips/vdso/Kconfig
> +++ b/arch/mips/vdso/Kconfig
> @@ -3,4 +3,4 @@
>  # the lack of relocations. As such, we disable the VDSO for microMIPS builds.
>  
>  config MIPS_DISABLE_VDSO
> -	def_bool CPU_MICROMIPS
> +	def_bool CPU_MICROMIPS || !(CSRC_R4K || CLKSRC_MIPS_GIC)

That is an an independent optimization IMO.


Thomas

Re: [PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 10:31, Thomas Weißschuh wrote:
> On Fri, Feb 27, 2026 at 09:46:23AM +0100, Arnd Bergmann wrote:
>> On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
>> 
>> The #ifdef was originally been added in commit 7d2aa4bb90f5 ("mips:
>> Fix gettimeofday() in the vdso library") as a bug fix. This may not
>> have been the correct fix because I don't see how it addressed the
>> case of a kernel with MIPS_CLOCK_VSYSCALL enabled running on a
>> CPU without the timer registers, but I think we should try to make
>> sure that there is no regression from reverting it now.
>
> I can't make sense out of this commit. The generic vDSO automatically falls
> back to the syscall if it can not handle the current clocksource.
> There is no explanation *why* this should be broken on MIPS.
> It works correctly on my x86 machines.

Agreed, the explanation is incomplete at best. Maybe Vincenzo remembers
more details as he did the original patch.

Maybe the fallback logic didn't exist at the time of that fix?

> Also vdso_clock_gettime() uses the same codepaths as vdso_gettimeofday()
> and apparently that is not broken.

Not sure, maybe nobody noticed the bug yet, or maybe both 
vdso_gettimeofday() and vdso_clock_gettime() now work correctly
after another bugfix.

The condition is fairly rare, as almost all MIPS systems have
a working clocksource, the few exceptions I see in Kconfig are

- R3000 based DECstation
- Sibyte
- Ingenic Xburst
- Octeon

There are not many users left on R3000 and Sibyte platforms, but
Xburst and Octeon were reasonably common in the past, so it should
have come up at some point.

>>  config MIPS_DISABLE_VDSO
>> -	def_bool CPU_MICROMIPS
>> +	def_bool CPU_MICROMIPS || !(CSRC_R4K || CLKSRC_MIPS_GIC)
>
> That is an an independent optimization IMO.

The idea here was that doing this would save you the trouble
of figuring out exactly how it was broken in the past and
whether the #ifdef is still needed.

     Arnd

Re: [PATCH 5/7] MIPS: VDSO: Drop kconfig MIPS_CLOCK_VSYSCALL

[Thomas Weißschuh]

On Fri, Feb 27, 2026 at 11:03:30AM +0100, Arnd Bergmann wrote:
> On Fri, Feb 27, 2026, at 10:31, Thomas Weißschuh wrote:
> > On Fri, Feb 27, 2026 at 09:46:23AM +0100, Arnd Bergmann wrote:
> >> On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> >> 
> >> The #ifdef was originally been added in commit 7d2aa4bb90f5 ("mips:
> >> Fix gettimeofday() in the vdso library") as a bug fix. This may not
> >> have been the correct fix because I don't see how it addressed the
> >> case of a kernel with MIPS_CLOCK_VSYSCALL enabled running on a
> >> CPU without the timer registers, but I think we should try to make
> >> sure that there is no regression from reverting it now.
> >
> > I can't make sense out of this commit. The generic vDSO automatically falls
> > back to the syscall if it can not handle the current clocksource.
> > There is no explanation *why* this should be broken on MIPS.
> > It works correctly on my x86 machines.
> 
> Agreed, the explanation is incomplete at best. Maybe Vincenzo remembers
> more details as he did the original patch.

That would be great.

> Maybe the fallback logic didn't exist at the time of that fix?

It did, and as far as I can see it looks fine.

> > Also vdso_clock_gettime() uses the same codepaths as vdso_gettimeofday()
> > and apparently that is not broken.
> 
> Not sure, maybe nobody noticed the bug yet, or maybe both 
> vdso_gettimeofday() and vdso_clock_gettime() now work correctly
> after another bugfix.

This is my suspicion.

If I mark the R4K and GIC clocksources as not vDSO compatible,
the automatic syscall fallback works correctly in my tests.

> The condition is fairly rare, as almost all MIPS systems have
> a working clocksource, the few exceptions I see in Kconfig are
> 
> - R3000 based DECstation
> - Sibyte
> - Ingenic Xburst
> - Octeon
> 
> There are not many users left on R3000 and Sibyte platforms, but
> Xburst and Octeon were reasonably common in the past, so it should
> have come up at some point.
> 
> >>  config MIPS_DISABLE_VDSO
> >> -	def_bool CPU_MICROMIPS
> >> +	def_bool CPU_MICROMIPS || !(CSRC_R4K || CLKSRC_MIPS_GIC)
> >
> > That is an an independent optimization IMO.
> 
> The idea here was that doing this would save you the trouble
> of figuring out exactly how it was broken in the past and
> whether the #ifdef is still needed.

We would still have the problem that on modern systems the clocksource
can get marked as unstable which will trigger a switchover to another
clocksource. If that one is not vDSO compatible the systemcall fallback
will also be used. So we want to fix this properly in any case. And then
the config change is only an optimization.


Thomas

[PATCH 6/7] MIPS: VDSO: Respect COMPAT_32BIT_TIME

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.

Currently the kconfig option does not affect the gettimeofday() syscall,
so also keep that in the vDSO.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/mips/vdso/vdso.lds.S      |  4 +++-
 arch/mips/vdso/vgettimeofday.c | 15 +++++++++------
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/mips/vdso/vdso.lds.S b/arch/mips/vdso/vdso.lds.S
index 76b6ad898288..f60d66bb677d 100644
--- a/arch/mips/vdso/vdso.lds.S
+++ b/arch/mips/vdso/vdso.lds.S
@@ -96,9 +96,11 @@ VERSION
 	LINUX_2.6 {
 #ifndef CONFIG_MIPS_DISABLE_VDSO
 	global:
-		__vdso_clock_gettime;
 		__vdso_gettimeofday;
+#if _MIPS_SIM == _MIPS_SIM_ABI64 || defined(CONFIG_COMPAT_32BIT_TIME)
+		__vdso_clock_gettime;
 		__vdso_clock_getres;
+#endif
 #if _MIPS_SIM != _MIPS_SIM_ABI64
 		__vdso_clock_gettime64;
 		__vdso_clock_getres_time64;
diff --git a/arch/mips/vdso/vgettimeofday.c b/arch/mips/vdso/vgettimeofday.c
index 00f9fcfc327e..39bc7e55fec4 100644
--- a/arch/mips/vdso/vgettimeofday.c
+++ b/arch/mips/vdso/vgettimeofday.c
@@ -12,23 +12,26 @@
 #include <vdso/gettime.h>
 
 #if _MIPS_SIM != _MIPS_SIM_ABI64
+
+#ifdef CONFIG_COMPAT_32BIT_TIME
 int __vdso_clock_gettime(clockid_t clock,
 			 struct old_timespec32 *ts)
 {
 	return __cvdso_clock_gettime32(clock, ts);
 }
 
-int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
-			struct timezone *tz)
-{
-	return __cvdso_gettimeofday(tv, tz);
-}
-
 int __vdso_clock_getres(clockid_t clock_id,
 			struct old_timespec32 *res)
 {
 	return __cvdso_clock_getres_time32(clock_id, res);
 }
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+
+int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
+			struct timezone *tz)
+{
+	return __cvdso_gettimeofday(tv, tz);
+}
 
 int __vdso_clock_gettime64(clockid_t clock,
 			   struct __kernel_timespec *ts)

-- 
2.53.0

[PATCH 7/7] vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions

[Thomas Weißschuh]

If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality.

Add some build-time validations to make sure the architecture-specific
glue satisfies this requirement.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 lib/vdso/gettimeofday.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index 4399e143d43a..0d134ac3dd84 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -6,6 +6,8 @@
 #include <vdso/datapage.h>
 #include <vdso/helpers.h>
 
+#include <linux/build_bug.h>
+
 /* Bring in default accessors */
 #include <vdso/vsyscall.h>
 
@@ -340,6 +342,8 @@ __cvdso_clock_gettime32_data(const struct vdso_time_data *vd, clockid_t clock,
 	struct __kernel_timespec ts;
 	bool ok;
 
+	BUILD_BUG_ON(!IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
 	ok = __cvdso_clock_gettime_common(vd, clock, &ts);
 
 	if (unlikely(!ok))
@@ -400,6 +404,8 @@ __cvdso_time_data(const struct vdso_time_data *vd, __kernel_old_time_t *time)
 	const struct vdso_clock *vc = vd->clock_data;
 	__kernel_old_time_t t;
 
+	BUILD_BUG_ON(sizeof(*time) != 8 && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
 	if (IS_ENABLED(CONFIG_TIME_NS) &&
 	    vc->clock_mode == VDSO_CLOCKMODE_TIMENS) {
 		vd = __arch_get_vdso_u_timens_data(vd);
@@ -491,6 +497,8 @@ __cvdso_clock_getres_time32_data(const struct vdso_time_data *vd, clockid_t cloc
 	struct __kernel_timespec ts;
 	bool ok;
 
+	BUILD_BUG_ON(!IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
 	ok = __cvdso_clock_getres_common(vd, clock, &ts);
 
 	if (unlikely(!ok))

-- 
2.53.0

Re: [PATCH 7/7] vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions

[Arnd Bergmann]

On Fri, Feb 27, 2026, at 07:57, Thomas Weißschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality.
>
> Add some build-time validations to make sure the architecture-specific
> glue satisfies this requirement.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Good idea

Reviewed-by: Arnd Bergmann <arnd@arndb.de>