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