On 01/09/2022 22:33:46+0200, Arnd Bergmann wrote:
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:
I'm pretty sure we don't want to play whack-a-mole with all the drivers, especially with those for RTCs that are available on both 32b and 64b systems.
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);
You may as well just clamp the value here, the RTC subsystem specifically considers a timestamp to be positive and this is why it is not affected by y2038 with 32bit second counters.
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-1FzXU...]