Re: [PATCH v3 0/7] Isolate time_t data types for clock/timer syscalls

[Thomas Gleixner]

On Mon, 26 Jun 2017, Arnd Bergmann wrote:
> On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani <deepa.kernel@xxxxxxxxx> wrote:
> > On Sun, Jun 25, 2017 at 7:35 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> >> On Sat, Jun 24, 2017 at 11:45:01AM -0700, Deepa Dinamani wrote:
> >>> The series aims at isolating data conversions of time_t based structures:
> >>> struct timespec and struct itimerspec at user space boundaries.
> >>> This helps to later change the underlying types to handle y2038 changes
> >>> to these.
> >>
> >> Nice...  A few questions:
> >>
> >> * what about setitimer(2)?  Right now that's the only remaining user of
> >> get_compat_itimerval(); similar for getitimer(2) and put_compat_itimerval().
> >
> > We do not plan to support these beyond y2038 on 32 bit systems.
> > timer_settime() and timer_gettime() are considered to be replacements
> > for these, respectively.
> >
> > There is also going to be a cleanup of timeval/ timespec/ time_t data
> > types and apis after the new syscalls are ready.
> > At that time I might choose to get rid of these itimerval apis. I'm
> > not sure yet.
> 
> I see that internally, alarm/getitimer/setitimer all use ktime_t, so
> one possible solution would be to push down the use of ktime_t
> into the callers and do both the conversion and range check in the
> user copy function.

We still can decide to not support the itimer API with the new y2038 ready
syscalls.

Actually there is no real need to do so because the itimer interfaces are
relative and never absolute. Keeping relative time limited to 68 years from
now should be good enough :)

Thanks,

	tglx