[Y2038] Re: RTC hctosys disabled for 32-bit systems

[Russell King (Oracle)]

On Thu, Sep 01, 2022 at 05:48:01PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 1, 2022, at 3:46 PM, Russell King (Oracle) wrote:
> > On Thu, Sep 01, 2022 at 03:12:57PM +0200, Arnd Bergmann wrote:
> >> Ah, I forgot that systemd actually needs it. So I guess there is
> >> currently no way to use systemd on 32-bit machines that are
> >> meant to survive 2038, regardless of whether systemd and glibc are
> >> built with a 64-bit time_t or not, right?
> >> 
> >> Is there perhaps a way to change the logic in a way that
> >> it does not depend on the current time but instead depends
> >> on a property of the RTC device itself, so we make systems
> >> break immediately instead of by surprise in 2038?
> >
> > Are you seriously suggesting to cause regressions on systems where
> > the RTC can send the kernel's timekeeping back to the early 1900s,
> > rather than printing a big fat warning message in the kernel log?
> 
> I think the systems that can send the timekeeping back into the early
> 1900s (or at least after 1970) are fine, the problem is the systems
> that can randomly send the timekeeping into the post-2038 future.

I believe Armada 388 systems can do that - and since Armada 388 systems
are involved in my connectivity, I would very much prefer it if someone
doesn't patch stuff that causes them to explode when I decide to
upgrade the kernel.

(Yes, I've run into the broken systemd issue with them when the RTC
was not correctly set on platform delivery.)

> What kind of warning would you suggest to print here? I don't see
> how warning about broken hardware at every boot would help, since
> there is no way for users to react to that warning. Similarly,
> warning about a time_t value past 2038 does not help because
> at that time one either has a bricked system (if using a systemd
> with 32-bit time_t)  or it is actually 2038 and the system
> reverts back to 1970.
> 
> What might work is to have all drivers for broken RTC devices
> default to a 1902-2037 (or 1970-2037) date range to ensure
> that only those devices are broken in 2038, but still allow
> overriding the "start-year" property in DT for machines that
> don't use the broken systemd.

I don't care too much how it's handled, but my objection is purely
against the intentional breaking of platforms such that they cause
people pain.

Sure, they will break in 2038, but that's no reason to break them
in 2022/3.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!