On 18/02/2025 17:05:23+0100, Arnd Bergmann wrote: > On Tue, Feb 18, 2025, at 16:40, Alexandre Belloni wrote: > > On 18/02/2025 15:51:24+0100, Arnd Bergmann wrote: > >> On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote: > >> > >> I don't know how many 32-bit machines are affected by the bug > >> where they return a random time, or if they are more or less > >> common than in the past. > > > > This is going to break some of the Marvell board that RMK uses because I > > guess he is not updating his userspace. > > > > Also, I'd note that OpenEmbedded switched to 64-bit time_t by default > > just last year. > > > > I'm not against removing the workaround but keeping it doesn't actually > > break anyone, it is still possible to set the time properly from > > userspace as it should be done anyway so I'm not sure about the urgency. > > The impact is mostly about messages timestamp in the boot log, before > > being able to run hwclock or any similar tool. > > > > Or am I missing anything? > > The main problem with the current approach is that it suddenly > breaks systems in the future (at the time_t overflow), which is > the opposite of how the rest of the time_t conversion worked. Yes, it will suddenly stop setting the time on boot which the platform can (and will) survive because it will probably then start NTP. However, without the workaround, systemd will just crash on boot, bricking the device. So as I see it, on one hand, I have mostly recoverable breakage and on the other breakage that mean going on the field and reflashing the device because the system will probably not be able to do any OTA anymore. > > We now have distros with systemd that advertize support [1], > and we know this breaks every single machine they run on that > uses an RTC to set the time. No, this breaks systems that only rely on RTC_HCTOSYS without a fallback. RTC_HCTOSYS alone is anyway pretty bad idea and no one interested in time should use it because it can be off up to a second which can take 4 to 7 days to resolve by selewing and not stepping. Anyone serious should use hwclock or similar to set the system time precisely after boot so the offset will be closer to a few ms. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
