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

From: "Arnd Bergmann" <arnd@arndb.de>
To: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
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: Fri, 02 Sep 2022 17:24:09 +0200	[thread overview]
Message-ID: <738bda0b-34db-4f58-8dab-5a0a71fc4c42@www.fastmail.com> (raw)
In-Reply-To: <YxEf5pUfwQsFyuNL@mail.local>

On Thu, Sep 1, 2022, at 11:11 PM, Alexandre Belloni wrote:
> 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.

If we want to address all drivers at the same time, this also affects
every architecture including x86: any 32-bit setup that relies on
RTC_HCTOSYS will break in 2038 unless we remove the INT_MAX hack,
but removing it everywhere immediately breaks setups that run
systemd when the RTC fails.

Note that this is not actually 32-bit specific, since the kernel
has no idea if it's running 32-bit or 64-bit userspace. I think we
are increasingly seeing users run 32-bit userland on arm64 and rv64
kernels as low-end SoCs are moving to 64-bit cores but remain
memory constrained.

>> 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.

Do you mean clamping to a non-negative value? That would break
the 'start-time' trick that I suggested. As far as I can tell,
the rtc_device_get_offset() function should work correctly and
not apply any translation when start-year is unset, but use a
translated range when it is set. If all negative values are
capped in the armada38x driver, that would make anything
break that is in the wrong half of the translated range.

        Arnd

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