Re: [PATCH] rtc: class: Make the time32 hctosys limit configurable

[Karl Mehltretter <kmehltretter@gmail.com>]

On Tue, Sep 15, 2026 at 07:48:12AM +0100, Arnd Bergmann wrote:
> On Mon, Sep 14, 2026, at 23:25, Karl Mehltretter wrote:
> > On 32-bit systems with RTC_HCTOSYS enabled, rtc_hctosys() rejects
> > RTC dates whose seconds value exceeds INT_MAX, even when userspace
> > uses a 64-bit time_t. This leaves system time uninitialized by the RTC.
> >
> > Commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow
> > time_t") introduced this limit to protect time32 userspace from future
> > RTC dates that can break boot. The same limit prevents systems with
> > time64 userspace from initializing the clock from valid post-2038 dates.
> 
> Hi Karl,
> 
> What about the reverse: if COMPAT_32BIT_TIME is disabled, I don't
> see why we'd want to allow turning this on, so maybe
> 

I tried this and found a case where the limit may still be useful
with COMPAT_32BIT_TIME=n. Glibc can use time64 kernel interfaces
for applications with a 32-bit time_t. Conversion to time32 fails
with EOVERFLOW when the date is out of range.

I tested a small clock_gettime() program using Debian glibc 2.41
on 32-bit ARM in QEMU, with identical kernel configurations and
initramfs. With RTC_HCTOSYS=y, COMPAT_32BIT_TIME=n and RTC in 2040:

  Kernel                 System year  time32 clock_gettime()
  ---------------------  -----------  ---------------------
  Baseline               1970         success
  Patch with dependency  2040         -1, errno=EOVERFLOW

The legacy clock_gettime syscall returned ENOSYS in both cases.
The same program built with a 64-bit time_t succeeded on both
kernels. Both builds also succeeded with the RTC in 2026. Both
kernels booted with time64 init.

Disabling legacy syscalls therefore does not establish that all
applications use a 64-bit time_t. The dependency would remove the
existing safeguard automatically and prevent restoring it without
re-enabling the legacy ABI.

I would prefer to preserve existing RTC date acceptance by default
and let integrators opt into later dates once their userspace is
ready. Keeping the posted settings would do that:

    depends on RTC_HCTOSYS && !64BIT
    default y

With RTC_HCTOSYS=y, for RTC dates beyond the cutoff:

D = don't care (y or n gives the same result).
Kernel denotes kernel bitness, regardless of userspace bitness.

With the patch as posted:

  Kernel  COMPAT_32BIT_TIME  RTC_HCTOSYS_TIME32_LIMIT  Allow past cutoff
  ------  -----------------  ------------------------  -----------------
  32-bit  D                  y (default)               n
  32-bit  D                  n                         y
  64-bit  D                  n (unavailable)           y

For reference, the baseline behaves as follows:

  Kernel  COMPAT_32BIT_TIME  Allow past cutoff
  ------  -----------------  -----------------
  32-bit  D                  n
  64-bit  D                  y

Karl