Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 22/02/2016 at 17:18:03 +0100, Arnd Bergmann wrote :
> > > IIRC, the problem is that user space passes in TIME_T_MAX and the kernel
> > > is considering that to be in the past because the clock is set beyond 2038.
> > > 
> > > I find it hard to blame user space for that, but I don't have a good
> > > idea for solving this either.
> > > 
> > > In case of systemd, it is literally the first thing that runs on the kernel
> > > after booting, so we could fall back to setting the time to some known
> > > working state (1970 or 2016 or something), but that would be a rather
> > > bad default policy once the system has been running for a while.
> > > 
> > 
> > Also, how would you know that it is an invalid time, some RTC doesn't
> > provide that information. 
> 
> What I meant was encountering a time past the 2038 date, which is invalid
> as seen from current 32-bit user space, but not necessarily from the
> kernel.
> 

I'm not completely sure how this would be different from my current patch...

> > One other workaround is to asked distributions
> > using systemd to stop using HCTOSYS so userspace would be responsible to
> > set the system time and in that case we won't have the 32/64 discrepancy.
> 
> I'm missing a bit of background here. This seems like a fairly useful
> piece of infrastructure for the majority of the use cases (working RTC)
> 
> How would the time get set when this is disabled? Is systemd able
> to read the rtc and write it back to the kernel? That could in fact
> be a nicer workaround for the problem, if it just does this before
> setting up the timerfd.
> 

I didn't check other distribution but debian and poky have
/etc/init.d/hwclock.sh that reads the rtc and sets the system time at
startup. It also saves the time to the RTC on shutdown.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com