Re: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts

[Arnd Bergmann]

On Tuesday 20 October 2015 10:59:34 Jesper Nilsson wrote:
> 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.

I thought about it some more and unfortunately fail to see a long-term
strategy here. In the future, a kernel will support user space with
either 32-bit or 64-bit time_t, in different tasks.

Going back to the wraparound means that the 64-bit time_t based
tasks won't work beyond 2038 either, but as you say the current
code breaks things that used to work.

I would like to introduce a Kconfig symbol like CONFIG_Y2038_UNSAFE
defaults to on, but can be disabled on 32-bit architectures in order
to leave out all known unsafe code from the kernel (including the
existing system calls that pass a time argument). We could possibly
use that as a guard here as well, to only use the 64-bit time
variant if CONFIG_Y2038_UNSAFE is disabled, but it would be nice
to have a kernel that can run the old binaries and that is also
working beyond 2038 when used with new binaries.

Note that the same problem you see now also exists on all 64-bit
architectures running 32-bit user space, and has been like that
since the start.

> 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?

It's basically NAKed.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/