Re: Y2038 related bug in rtc subsystem for 32 bit processors

Re: Y2038 related bug in rtc subsystem for 32 bit processors

[Alexandre Belloni]

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