On 22/11/2022 22:27:39+0000, Richard OGrady wrote: > While testing Y2038 compatibility on a 32 bit arm processor I came across this potential bug? in drivers/rtc/class.c (line 76 in v6.0.9) > > > tv64<https://elixir.bootlin.com/linux/latest/C/ident/tv64>.tv_sec<https://elixir.bootlin.com/linux/latest/C/ident/tv_sec> = rtc_tm_to_time64<https://elixir.bootlin.com/linux/latest/C/ident/rtc_tm_to_time64>(&tm<https://elixir.bootlin.com/linux/latest/C/ident/tm>); > > > > #if BITS_PER_LONG<https://elixir.bootlin.com/linux/latest/C/ident/BITS_PER_LONG> == 32 > > if (tv64<https://elixir.bootlin.com/linux/latest/C/ident/tv64>.tv_sec<https://elixir.bootlin.com/linux/latest/C/ident/tv_sec> > INT_MAX<https://elixir.bootlin.com/linux/latest/C/ident/INT_MAX>) { > > err = -ERANGE<https://elixir.bootlin.com/linux/latest/C/ident/ERANGE>; > > goto err_read; > > } > > #endif > > > > err = do_settimeofday64<https://elixir.bootlin.com/linux/latest/C/ident/do_settimeofday64>(&tv64<https://elixir.bootlin.com/linux/latest/C/ident/tv64>); > > > The #if/#endif block above causes the driver to not sync the system clock with the reading from the hwclock once the rtc reading reflects the Y2038 date and later. I certainly could be wrong but it would seem that the block is over-protective and unnecessary. We commented the block out and the system syncs fine with the rtc when the rtc is set to the year 2039. > You are right and this is a workaround for an issue in systemd. Honestly, the solution is to stop relying on rtc_hctosys and set the system time from userspace. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
