Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1251472
| From | Jesper Nilsson <jesper.nilsson@axis.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts |
| Date | 2015-10-20 11:10 +0200 |
| Message-ID | <qlB5F-7z4-23@gated-at.bofh.it> (permalink) |
| References | <qhBdU-54V-23@gated-at.bofh.it> <qlnP4-4FP-3@gated-at.bofh.it> <qlAjf-6os-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts John Stultz <john.stultz@linaro.org> - 2015-10-19 21:00 +0200
Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Miroslav Lichvar <mlichvar@redhat.com> - 2015-10-20 09:40 +0200
Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Arnd Bergmann <arnd@arndb.de> - 2015-10-20 10:20 +0200
Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Jesper Nilsson <jesper.nilsson@axis.com> - 2015-10-20 11:10 +0200
Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Arnd Bergmann <arnd@arndb.de> - 2015-10-20 13:10 +0200
csiph-web