From: "Arnd Bergmann" <arnd@arndb.de>
To: "Alexandre Belloni" <alexandre.belloni@bootlin.com>
Cc: linux-arm-kernel@lists.infradead.org, y2038@lists.linaro.org
Subject: Re: RTC hctosys disabled for 32-bit systems
Date: Thu, 01 Sep 2022 17:29:09 +0200 [thread overview]
Message-ID: <c08234ac-5c39-4324-b05b-a635d1cd70fb@www.fastmail.com> (raw)
In-Reply-To: <YxC6Y3MjLIBH/gha@mail.local>
On Thu, Sep 1, 2022, at 3:57 PM, Alexandre Belloni wrote:
> On 01/09/2022 15:12:57+0200, Arnd Bergmann wrote:
>> As far as I remember, the workaround was only needed for
>> certain devices that may set the time to something after 2038
>> on a depleted battery, but other devices would have a better
>> failure case, right?
>>
>
> Yes, this is the main cause, anything able to set the system time after
> 2038 with a 32bit userspace will cause that (and basically I think this
> is only hctosys). The issue is that many RTCs don't have a default value
> for the time registers after power failure. This is usually not an issue
> as there is also a bit allowing to detect whether the time is correct.
> note that this will also be an issue once we actually reach 2038 with a
> 32bit userspace.
The problem is that people are deploying systems already with the
expectation that they will survive y2038, and it is rather unlikely that
the developers that build these systems will be around to update the
systems anywhere close to that. glibc now has the 64-bit time_t support
(and musl has had it for a while), so even if you do unit tests on
your own software to check for bugs, you wouldn't necessarily run into
the issue unless you reboot the system with the RTC set to the future
as part of the testing.
In effect, whatever we will need in 2038, we also need to have today,
so the current code cannot remain unchanged, the question is just
about how to minimize the damage.
Is there any way to find out which RTC drivers are affected by this?
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2022-09-01 15:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 11:31 RTC hctosys disabled for 32-bit systems Reinier Kuipers
2022-09-01 11:55 ` Arnd Bergmann
2022-09-01 12:49 ` Alexandre Belloni
2022-09-01 13:12 ` Arnd Bergmann
2022-09-01 13:46 ` Russell King (Oracle)
2022-09-01 15:48 ` [Y2038] " Arnd Bergmann
2022-09-01 16:02 ` Russell King (Oracle)
2022-09-01 20:33 ` Arnd Bergmann
2022-09-01 21:11 ` Alexandre Belloni
2022-09-02 15:24 ` Arnd Bergmann
2022-09-01 13:57 ` Alexandre Belloni
2022-09-01 15:29 ` Arnd Bergmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c08234ac-5c39-4324-b05b-a635d1cd70fb@www.fastmail.com \
--to=arnd@arndb.de \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).