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

From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org,
	Reinier Kuipers <kuipers.reinier@gmail.com>
Subject: Re: [Y2038] Re: RTC hctosys disabled for 32-bit systems
Date: Thu, 1 Sep 2022 23:11:02 +0200	[thread overview]
Message-ID: <YxEf5pUfwQsFyuNL@mail.local> (raw)
In-Reply-To: <316a07b5-bfd6-480f-b5a3-2d5fc9991252@www.fastmail.com>

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-1FzXUeS7o2LiZqALJ42qw@mail.gmail.com/]

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel