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