lkml.org 
[lkml]   [2015]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2015-10-20 11:21    [W:0.063 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site