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

[Arnd Bergmann]

On Thu, Sep 1, 2022, at 6:02 PM, Russell King (Oracle) wrote:
> On Thu, Sep 01, 2022 at 05:48:01PM +0200, Arnd Bergmann wrote:
>
>> 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.)

Ok, good to know. I wonder if this patch would be sufficient for
this particular driver:

diff --git a/drivers/rtc/rtc-armada38x.c b/drivers/rtc/rtc-armada38x.c
index cc542e6b1d5b..f2bbb8efed18 100644
--- a/drivers/rtc/rtc-armada38x.c
+++ b/drivers/rtc/rtc-armada38x.c
@@ -219,7 +219,7 @@ static int armada38x_rtc_read_time(struct device *dev, struct rtc_time *tm)
 	time = rtc->data->read_rtc_reg(rtc, RTC_TIME);
 	spin_unlock_irqrestore(&rtc->lock, flags);
 
-	rtc_time64_to_tm(time, tm);
+	rtc_time64_to_tm((s32)time, tm);
 
 	return 0;
 }
@@ -541,7 +541,8 @@ static __init int armada38x_rtc_probe(struct platform_device *pdev)
 	rtc->data->update_mbus_timing(rtc);
 
 	rtc->rtc_dev->ops = &armada38x_rtc_ops;
-	rtc->rtc_dev->range_max = U32_MAX;
+	rtc->rtc_dev->range_min = S32_MIN;
+	rtc->rtc_dev->range_max = S32_MAX;
 
 	return devm_rtc_register_device(rtc->rtc_dev);
 }

The effect of this is to interpret the RTC values as range
1902...2038 instead of 1970...2106, which should make
systemd not crash any more on random input, but have no
other side-effects within the 1970...2038 range.

Users that care about running systems beyond 2038 and
run a time64 userland can then set the wrap-around point
in DT e.g. to 2022...2156 using the 'start-year=<2022>;'
property, or any other value they like. If we can do the
equivalent for all RTC drivers that may suffer from the
same problem, the HCTOSYS hack for the S32_MAX value
can just get removed.

      Arnd

[I accidentally dropped Rainier from Cc, adding him back now. For
reference, the other mail are archived at
https://lore.kernel.org/linux-arm-kernel/CAKYb531CyL8XRVRcRN30cC3xRgsd-1FzXUeS7o2LiZqALJ42qw@mail.gmail.com/]