Re: [PATCH v2] posix-cpu-timers: Avoid undefined behaviour in timespec64_to_ns()

[Arnd Bergmann]

On Thu, Feb 28, 2019 at 11:35 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Thu, 28 Feb 2019, Arnd Bergmann wrote:
> > On Thu, Feb 28, 2019 at 5:25 AM Deepa Dinamani <deepa.kernel@xxxxxxxxx> wrote:
> > >
> > > On Tue, Feb 26, 2019 at 11:52 PM Xiongfeng Wang
> > > <wangxiongfeng2@xxxxxxxxxx> wrote:
> > I think returning EINVAL here is better than silently truncating, we
> > just need to
> > document it in the Linux man page.
> > Note that truncation would set the time to just before the overflow,
> > it bad things
> > start to happen the instant after it returns from the kernel. This is possibly
> > worse than setting a random value that may or may not crash the system.
>
> Not necessarily. On the hrtimer based side, we clamp the values to
> KTIME_MAX. That means in theory the overflow could happen when the timer
> expires and the interval is added. There are two things which prevent that:
>
> 1) The timer expires in about 292 years from now, which I really can't be
>    worried about
>
> 2) The rearming code prevents the overflow into undefined space as well.
>
> So, it's not unreasonable to do clamping as long as the handed in value is
> at least formally correct.
>
> Of course we need to look at the posix-cpu-timer side of affairs to ensure
> that the limits are handled correctly.

Ah right. I had misread timer_settime() for clock_settime(), which
would have a problem if it were lacking the timespec64_valid_strict()
check that it has.

However, I see that the man page for clock_settime() fails
to mention the EINVAL return code, so I suppose we should
add that. I still plan to update the man pages to mention
the time64 versions, and can do that at the same time.

      Arnd