RTC hctosys disabled for 32-bit systems
Alexandre Belloni
alexandre.belloni at bootlin.com
Thu Sep 1 05:49:54 PDT 2022
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.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
More information about the linux-arm-kernel
mailing list