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

2017-06-19 Thread Al Viro
On Mon, Jun 19, 2017 at 01:52:05PM -0700, Deepa Dinamani wrote: > On Mon, Jun 19, 2017 at 12:46 PM, Al Viro wrote: > > On Mon, Jun 19, 2017 at 12:31:00PM -0700, Deepa Dinamani wrote: > > > >> 3. I was also aiming for user pointers to be not touched by timer > >> specific code as it can get messy i

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

2017-06-19 Thread Deepa Dinamani
On Mon, Jun 19, 2017 at 12:46 PM, Al Viro wrote: > On Mon, Jun 19, 2017 at 12:31:00PM -0700, Deepa Dinamani wrote: > >> 3. I was also aiming for user pointers to be not touched by timer >> specific code as it can get messy if not handled properly with 2 >> compat time_t versions. > > So have one h

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

2017-06-19 Thread Al Viro
On Mon, Jun 19, 2017 at 12:31:00PM -0700, Deepa Dinamani wrote: > 3. I was also aiming for user pointers to be not touched by timer > specific code as it can get messy if not handled properly with 2 > compat time_t versions. So have one helper that deals with all copyout and have it used by all

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

2017-06-19 Thread Deepa Dinamani
> Check the stuff already in tip/timers/core; at the very least it overlaps > considerably with your series. And your variant is a lot more convoluted - > there's no need to have a separate compat restart, etc. Thanks, I see there were updates last week to the tree. For the nanosleep part, I see

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

2017-06-19 Thread Al Viro
On Sun, Jun 18, 2017 at 11:45:07PM -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. > > Th