On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote:
> On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> > On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > > This patch sets a maximum value of the system time to prevent the system
> > > time from getting too close to the overflow. The time can't be set to a
> > > larger value. When the maximum is reached in normal time accumulation,
> > > the clock will be stepped back by one week.
> >
> > I can't see whether this is really a good idea: moving the time backwards
> > will break all sorts of drivers that (incorrectly) expect the real
> > time clock to have monotonic behavior, and quite often, file timestamps
>
> Well, do these drivers break when the clock is stepped back by ntpd?
Yes.
> Maybe it would be better to fix them.
We are in the process of doing that: All drivers that currently use
do_gettimeofday() or get_seconds() are being audited and converted
to one of ktime_get(), ktime_get_real(), ktime_get_ts64(),
ktime_get_real_ts64(), ktime_get_seconds() or ktime_get_real_seconds().
The 'real' versions should only be used when the driver wants to know
the wallclock but is ok with time going backwards.
> > are expected to be in the past in user space. A common example is
> > 'make', which goes nuts when it sees files in the future.
>
> Without the limit added by this patch make will go nuts just one week
> later when the 32-bit time_t overflows to Dec 13 1901 and the files
> will appear as 136 years in the future. How is that better?
Not better or worse at all, that was my point. The time is still
wrong either way, whether you step back by a week or 136 years.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
