RTC hctosys disabled for 32-bit systems

[Arnd Bergmann]

On Thu, Sep 1, 2022, at 1:31 PM, Reinier Kuipers wrote:
>
> I'm working to fix the y2038 issue for an existing sama5d3-based
> product. This involves updating the kernel and glibc to appropriate
> versions (5.10 and 2.35.1 respectively) and I got things running up to
> a state where, from userspace, both date and hwclock commands have no
> issue accepting dates beyond 2038. However, even with the RTC_HCTOSYS
> and RTC_HCTOSYS_DEVICE options configured correctly, the RTC driver
> fails to initialize the system clock at bootup.
>
> Some digging in rtc/class.c::rtc_hctosys() indicates that
> do_settimeofday64() is deliberately not executed on systems with
> BITS_PER_LONG==32 and a second counter higher than INT_MAX. I assumed
> that the work on 64-bits timestamps was already fully implemented for
> 32-bit systems as well, so my gut feel is that this
> BITS_PER_LONG/INT_MAX check has become unnecessary. A test build with
> these checks disabled results in correct time initialization at bootup
> with, at a glance, no adverse effects. Does anybody here know whether
> do_settimeofday64()  is robust on 32-bit systems or that the checks
> are still required to prevent further breakage?

Please see commit b3a5ac42ab18 ("rtc: hctosys: Ensure system time
doesn't overflow time_t") and  https://github.com/systemd/systemd/issues/1143
for the problem that originally caused this to be added.

Removing this check would probably break systemd again for machines
that return a post-y2038 time with systemd built on 32-bit time_t.

The only reliable fix I can see would be to disable
CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan
for the long run anyway, but I don't know if there has been any
progress in convincing distros to turn it off.

      Arnd