On Mon, Jul 3, 2017 at 12:23 PM, Thomas Gleixner tglx@linutronix.de wrote:
On Mon, 26 Jun 2017, Arnd Bergmann wrote:
On Mon, Jun 26, 2017 at 8:17 PM, Deepa Dinamani deepa.kernel@gmail.com wrote:
On Sun, Jun 25, 2017 at 7:35 PM, Al Viro viro@zeniv.linux.org.uk 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 :)
I really want to have all syscalls to use 64-bit time_t for the new API, otherwise we get into the really silly state where even for future architectures, glibc has to convert the 64-bit time_t coming from an application into a 32-bit timeval to pass it to the kernel, which then converts it back to an internal type (64-bit time_t or ktime_t).
In case of the itimer interfaces, this is really no question though, as Deepa said, since glibc can simply implement the new version by calling timer_create/timer_settime instead of calling the 32-bit setitimer. timer_settime() needs to take 64-bit arguments anyway because it can use either relative or absolute arguments.
Arnd