Messages in this thread | | | Date | Tue, 20 Oct 2015 10:59:34 +0200 | From | Jesper Nilsson <> | Subject | Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts |
| |
On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote: > On Monday 19 October 2015 11:53:25 John Stultz wrote: > > > > But yea. At the same time I get you want to avoid user-pain like in > > the case of the badly initialized RTC, but in that case would > > returning 0 for RTC reads greater then y2038 on 32 bit systems be a > > more sane fix? > > I like that idea. In theory we could go further and check that the RTC > is somewhere between 2015 and 2037 (or higher on 64-bit systems) but > return 0 (1970) for anything that is outside of that range. That might > have side-effects for users that have a legitimate reason to backdate > their clocks though.
This is how the RTC framework used to handle it before the referenced patch in my original mail, so a reversal (conditional on 32bit) would solve that part of the problem.
It also looks like Miroslav's patch will handle the other cases of a accidental user initiated set of a bad date or a maliciously set NTP. Though, from my point of view, a wrap-around to 1970 would be just as valid as a jump one week in the past.
What's the current status of that patch?
> Arnd
/^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nilsson@axis.com
| |