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

[Miroslav Lichvar <mlichvar@redhat.com>]

On Mon, Oct 19, 2015 at 11:53:25AM -0700, John Stultz wrote:
> On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson <jesper.nilsson@axis.com> wrote:
> > Of course, the proposed patch only allows the setting of relative
> > timeouts with TFD_TIMER_CANCEL_ON_SET, any application using
> > it would also need to be patched to use the relative timer
> > for this solve the described problem.
> 
> So is this not more of a workaround? Basically just allows
> applications on systems that can't handle y2038 to be able to use
> different interfaces to maybe allow the system to crawl onward to the
> next problem?

Right, any absolute timer set on the system time is a problem when it
overflows.

> Miroslav had a patch recently to try to keep 32bit systems from
> getting into a week near y2038 to try to stave off some of these ugly
> problems. While I'm not totally against such patches (Miroslav's
> concern of a DoS vector is reasonable), I also want to avoid giving
> folks a false sense of confidence that the problems are resolved.

Not all of the problems can be resolved, but current time overflowing
32-bit time_t can be prevented in the kernel, reliably.

Applications using 32-bit time_t shouldn't be expected to handle a
case when it's not really Oct 20 2015, but rather Nov 26 2151, should
they?

That would be like implicitly opening files with O_LARGEFILE, even for
applications not compiled with 64-bit off_t. The difference to the
large file support is that there is only one file (the system time)
and it's shared between all applications.

I think as long as there is anything with 32-bit time_t running on the
machine, the system time must not be allowed to overflow. If you don't
like the idea of stepping the clock back one week sooner to prevent
also time_t overflowing in majority of the user-space code, it could
be moved closer to the actual overflow. I don't see the benefit
though.

Similar applies to KTIME_MAX and the kernel code.

-- 
Miroslav Lichvar