On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote:
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.
This is still my plan but systemd mandates RTC_HCTOSYS and I couldn't convince Lennart otherwise.