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

["Arnd Bergmann" <arnd@arndb.de>]

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,

Thanks for revisiting this!

> Add RTC_HCTOSYS_TIME32_LIMIT for 32-bit kernels, defaulting to y to
> preserve the existing safeguard. Allow integrators to disable it once
> their entire userspace, including init, supports post-2038 dates.
> Warn on rejection with the RTC date and option name so users can
> identify the cause and find the setting.
>
> Keep the option independent of COMPAT_32BIT_TIME. Userspace with a
> 64-bit time_t may still need legacy syscalls for operations that do
> not represent post-2038 dates.

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

+config RTC_HCTOSYS_TIME32_LIMIT
+	bool "Reject RTC dates after the 2038 cutoff"
+	depends on RTC_HCTOSYS && !64BIT && !COMPAT_32BIT_TIME

[Technically it would also make sense to enable the option on 64-bit
kernels running 32-bit userspace, which some users do to reduce
memory usage. However, we never supported that case and I'd rather
not start now.]

      Arnd