[PATCH v2 0/7] Introduce struct __kernel_timex

[PATCH v2 0/7] Introduce struct __kernel_timex

[Deepa Dinamani]

The series introduces struct __kernel_timex as a substitute for
the non y2038 safe struct timex.

The series is based on the original series posted by Arnd Bergmann
in [1].

The overview of the series is as below:
1. Prepare for the compat timex interfaces to be used unconditionally.
2. Introduce struct __kernel_timex.
3. Use struct __kernel_timex in place of struct timex.
4. Switch syscalls to use struct __kernel_timex.

[1] https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html

Changes since v1:
* Fix riscv asm/compat.h to pick up generic compat types

Deepa Dinamani (7):
  arm64: Make basic compat_* types always available
  sparc: Make thread_info.h available directly
  riscv: Include asm-generic/compat.h
  timex: prepare compat helpers for y2038 changes
  time: Add struct __kernel_timex
  timex: use __kernel_timex internally
  timex: change syscalls to use struct __kernel_timex

 arch/alpha/kernel/osf_sys.c     |  2 +-
 arch/arm64/include/asm/compat.h | 22 ++++-----
 arch/riscv/include/asm/compat.h |  3 ++
 arch/sparc/include/asm/compat.h |  2 +
 drivers/ptp/ptp_clock.c         |  2 +-
 include/asm-generic/compat.h    |  8 +++-
 include/linux/compat.h          | 33 --------------
 include/linux/compat_time.h     | 34 ++++++++++++++
 include/linux/posix-clock.h     |  2 +-
 include/linux/syscalls.h        |  5 +--
 include/linux/timex.h           |  9 +++-
 include/uapi/linux/timex.h      | 41 +++++++++++++++++
 kernel/compat.c                 | 63 --------------------------
 kernel/time/ntp.c               | 12 ++---
 kernel/time/ntp_internal.h      |  2 +-
 kernel/time/posix-clock.c       |  2 +-
 kernel/time/posix-timers.c      | 14 ++----
 kernel/time/posix-timers.h      |  2 +-
 kernel/time/time.c              | 80 ++++++++++++++++++++++++++++++---
 kernel/time/timekeeping.c       |  4 +-
 20 files changed, 201 insertions(+), 141 deletions(-)


base-commit: e30b8745c892204095c0a8b69405868f63ddcce1
-- 
2.17.1

Cc: catalin.marinas at arm.com
Cc: davem at davemloft.net
Cc: linux-alpha at vger.kernel.org
Cc: linux-api at vger.kernel.org
Cc: linux-arch at vger.kernel.org
Cc: linux-riscv at lists.infradead.org
Cc: netdev at vger.kernel.org
Cc: palmer at sifive.com

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Deepa Dinamani]

riscv does not enable CONFIG_COMPAT in default configurations:
defconfig, allmodconfig and nomodconfig.
And hence does not inlude definitions for compat data types.

Now that time syscalls are being reused in non CONFIG_COMPAT
modes, include asm-generic definitions for riscv.

Alternative would be to make compat_time.h to be conditional on
CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
asm/compat.h include the generic version instead.

Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: palmer at sifive.com
Cc: linux-riscv at lists.infradead.org
---
 arch/riscv/include/asm/compat.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/riscv/include/asm/compat.h b/arch/riscv/include/asm/compat.h
index 044aecff8854..e78c5054e178 100644
--- a/arch/riscv/include/asm/compat.h
+++ b/arch/riscv/include/asm/compat.h
@@ -15,6 +15,9 @@
  */
 #ifndef __ASM_COMPAT_H
 #define __ASM_COMPAT_H
+
+#include <asm-generic/compat.h>
+
 #ifdef CONFIG_COMPAT
 
 #if defined(CONFIG_64BIT)
-- 
2.17.1

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Christoph Hellwig]

On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
> defconfig, allmodconfig and nomodconfig.
> And hence does not inlude definitions for compat data types.
> 
> Now that time syscalls are being reused in non CONFIG_COMPAT
> modes, include asm-generic definitions for riscv.
> 
> Alternative would be to make compat_time.h to be conditional on
> CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
> asm/compat.h include the generic version instead.

Two comments here:

First I think the current riscv compat.h is completely bogus.
As you mentioned riscv does not actually have a compat mode, so
having a compat.h makes no sensse at all, and the COMPAT_UTS_MACHINE
override which is the only thing implemented is included in that
statement.

Second I think abusing compat.h for old syscall compatibility of any
form is a really bad idea.  I think you need to split that part out,
and preferably not using compat in the name, but something like
old-time.h or time32.h for the name.

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Deepa Dinamani]

On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
>> defconfig, allmodconfig and nomodconfig.
>> And hence does not inlude definitions for compat data types.
>>
>> Now that time syscalls are being reused in non CONFIG_COMPAT
>> modes, include asm-generic definitions for riscv.
>>
>> Alternative would be to make compat_time.h to be conditional on
>> CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
>> asm/compat.h include the generic version instead.
>
> Two comments here:
>
> First I think the current riscv compat.h is completely bogus.
> As you mentioned riscv does not actually have a compat mode, so
> having a compat.h makes no sensse at all, and the COMPAT_UTS_MACHINE
> override which is the only thing implemented is included in that
> statement.

I was leaving the decision on how to clean up compat mode to the
architecture maintainers.
I wasn't sure if they were still in the middle of implementing it.

> Second I think abusing compat.h for old syscall compatibility of any
> form is a really bad idea.  I think you need to split that part out,
> and preferably not using compat in the name, but something like
> old-time.h or time32.h for the name.

Are you talking about just the header file or the way we are reusing
compat syscalls?
Either way, we have merged quite a few patches this way already.
I agree that having something like time32.h might be less confusing.
But, if you are worried about the former, then maybe we should propose
a cleanup after we finish what we are doing or back out the merged
patches.
For instance, posix_clock apis have already been changed this way.

-Deepa

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Arnd Bergmann]

On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
>>> defconfig, allmodconfig and nomodconfig.
>>> And hence does not inlude definitions for compat data types.
>>>
>>> Now that time syscalls are being reused in non CONFIG_COMPAT
>>> modes, include asm-generic definitions for riscv.
>>>
>>> Alternative would be to make compat_time.h to be conditional on
>>> CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
>>> asm/compat.h include the generic version instead.
>>
>> Two comments here:
>>
>> First I think the current riscv compat.h is completely bogus.
>> As you mentioned riscv does not actually have a compat mode, so
>> having a compat.h makes no sensse at all, and the COMPAT_UTS_MACHINE
>> override which is the only thing implemented is included in that
>> statement.
>
> I was leaving the decision on how to clean up compat mode to the
> architecture maintainers.
> I wasn't sure if they were still in the middle of implementing it.

If we only need it for 32 bit time_t, we can probably just use the
asm-generic/compat.h for now.

>> Second I think abusing compat.h for old syscall compatibility of any
>> form is a really bad idea.  I think you need to split that part out,
>> and preferably not using compat in the name, but something like
>> old-time.h or time32.h for the name.
>
> Are you talking about just the header file or the way we are reusing
> compat syscalls?
> Either way, we have merged quite a few patches this way already.
> I agree that having something like time32.h might be less confusing.
> But, if you are worried about the former, then maybe we should propose
> a cleanup after we finish what we are doing or back out the merged
> patches.
> For instance, posix_clock apis have already been changed this way.

It would be easy to rename compat_time_t, compat_timespec and
compat_timeval to something else if we could come up with a good
name for them (we already have too many variants of each of
them though, otherwise we end up being more confusing rather
than less).

We can also rename all the compat syscalls that are now shared
with 32-bit, e.g. using sys_waitid_time32() instead of
compat_sys_waitid(), and that would be consistent with the
new _time64() naming that we are introducing for some of them.
Right now, this affects around 30 syscalls; with my test tree on
ARM, I have this set of calls, the exact set is architecture
dependent of course:

compat_sys_time
compat_sys_stime
compat_sys_utime
compat_sys_gettimeofday
compat_sys_settimeofday
compat_sys_old_select
compat_sys_setitimer
compat_sys_getitimer
compat_sys_select
compat_sys_sched_rr_get_interval
compat_sys_nanosleep
compat_sys_rt_sigtimedwait
compat_sys_futex
compat_sys_io_getevents
compat_sys_timer_settime
compat_sys_timer_gettime
compat_sys_clock_settime
compat_sys_clock_gettime
compat_sys_clock_getres
compat_sys_clock_nanosleep
compat_sys_utimes
compat_sys_mq_timedsend
compat_sys_mq_timedreceive
compat_sys_futimesat
compat_sys_pselect6
compat_sys_ppoll
compat_sys_utimensat
compat_sys_timerfd_settime
compat_sys_timerfd_gettime
compat_sys_recvmmsg
compat_sys_io_pgetevents

Completely separating them from the compat code
would add further complexity though, as some of the
system calls take another argument that is different
between 32-bit and 64-bit kernels, in particular
pselect6, ppoll, io_pgetevents, recvmmsg, and waitid.

       Arnd

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Deepa Dinamani]

On Fri, Jul 6, 2018 at 4:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <hch@infradead.org> wrote:
>>> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
>>>> defconfig, allmodconfig and nomodconfig.
>>>> And hence does not inlude definitions for compat data types.
>>>>
>>>> Now that time syscalls are being reused in non CONFIG_COMPAT
>>>> modes, include asm-generic definitions for riscv.
>>>>
>>>> Alternative would be to make compat_time.h to be conditional on
>>>> CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
>>>> asm/compat.h include the generic version instead.
>>>
>>> Two comments here:
>>>
>>> First I think the current riscv compat.h is completely bogus.
>>> As you mentioned riscv does not actually have a compat mode, so
>>> having a compat.h makes no sensse at all, and the COMPAT_UTS_MACHINE
>>> override which is the only thing implemented is included in that
>>> statement.
>>
>> I was leaving the decision on how to clean up compat mode to the
>> architecture maintainers.
>> I wasn't sure if they were still in the middle of implementing it.
>
> If we only need it for 32 bit time_t, we can probably just use the
> asm-generic/compat.h for now.

Ok. Will send out a v3 with asm/compat.h removed. Thanks.

-Deepa

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Christoph Hellwig]

On Fri, Jul 06, 2018 at 01:42:46PM +0200, Arnd Bergmann wrote:
> We can also rename all the compat syscalls that are now shared
> with 32-bit, e.g. using sys_waitid_time32() instead of
> compat_sys_waitid(), and that would be consistent with the
> new _time64() naming that we are introducing for some of them.

Yes, please.  You'll need to touch the syscall tables anyway to refer to
some new name, so it really isn't that much more work.

> Completely separating them from the compat code
> would add further complexity though, as some of the
> system calls take another argument that is different
> between 32-bit and 64-bit kernels, in particular
> pselect6, ppoll, io_pgetevents, recvmmsg, and waitid.

Why would that create further complexity?  IFF those calls need compat
work other than the time structures you will need additional variants of
them anyway.  If the only compat handling is the time structures they
will stay the same independent of the name.

> 
>        Arnd
---end quoted text---

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Arnd Bergmann]

On Thu, Jul 12, 2018 at 10:32 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Fri, Jul 06, 2018 at 01:42:46PM +0200, Arnd Bergmann wrote:
>> We can also rename all the compat syscalls that are now shared
>> with 32-bit, e.g. using sys_waitid_time32() instead of
>> compat_sys_waitid(), and that would be consistent with the
>> new _time64() naming that we are introducing for some of them.
>
> Yes, please.  You'll need to touch the syscall tables anyway to refer to
> some new name, so it really isn't that much more work.

Ok. The downside is that we probably have to change the existing
architectures using those compat syscalls together, with one patch
renaming them in x86, powerpc, s390, mips, sparc and parisc, but
at least that is a fairly simple rename.

For the tables that are used on native 32-bit architectures
(asm-generic, arm, m68k, microblaze, mips, parisc, powerpc,
sh, sparc, x86 and xtensa), I'd still prefer following the plan of
changing them one architecture at a time in a separate patch,
but hopefully all in the same merge window.

>> Completely separating them from the compat code
>> would add further complexity though, as some of the
>> system calls take another argument that is different
>> between 32-bit and 64-bit kernels, in particular
>> pselect6, ppoll, io_pgetevents, recvmmsg, and waitid.
>
> Why would that create further complexity?  IFF those calls need compat
> work other than the time structures you will need additional variants of
> them anyway.  If the only compat handling is the time structures they
> will stay the same independent of the name.

Right now, each of the five syscalls has three variants in the current
implementation, e.g.

/* new native call using 64-bit time_t */
SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, unsigned int, nfds,
                struct __kernel_timespec __user *, tsp, const sigset_t
__user *, sigmask,
                size_t, sigsetsize)
...

/* handler for 32-bit time_t, both native and compat */
#ifdef CONFIG_COMPAT_32BIT_TIME
#ifndef CONFIG_COMPAT
/* ugly redirect to native types on 32-bit kernels */
#define compat_get_fd_set get_fd_set
#define compat_set_fd_set set_fd_set
#define compat_sigset_t sigset_t
#endif /* !CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds,
        unsigned int,  nfds, struct compat_timespec __user *, tsp,
        const compat_sigset_t __user *, sigmask, compat_size_t, sigsetsize)
...
#endif /* CONFIG_COMPAT_32BIT_TIME */

/* compat handler for 64-bit time_t on 64-bit kernel */
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE5(ppoll_time64, struct pollfd __user *, ufds,
        unsigned int,  nfds, struct __kernel_timespec __user *, tsp,
        const compat_sigset_t __user *, sigmask, compat_size_t, sigsetsize)
...
#endif

Avoiding that set of #defines as you suggest would definitely
make it cleaner, but then we need to have four variants instead
of three:

/* old native call using 32-bit time_t */
#if defined(CONFIG_COMPAT_32BIT_TIME) && !defined (CONFIG_64BIT)
SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, unsigned int, nfds,
                struct __kernel_old_timespec __user *, tsp, const
sigset_t __user *, sigmask,
                size_t, sigsetsize)
...
#endif

/* new native call using 64-bit time_t */
SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds, unsigned int, nfds,
                struct __kernel_timespec __user *, tsp, const sigset_t
__user *, sigmask,
                size_t, sigsetsize)
...

#ifdef CONFIG_COMPAT
#ifdef CONFIG_COMPAT_32BIT_TIME
/* handler for 32-bit time_t, both native and compat */
COMPAT_SYSCALL_DEFINE5(ppoll, struct pollfd __user *, ufds,
        unsigned int,  nfds, struct compat_timespec __user *, tsp,
        const compat_sigset_t __user *, sigmask, compat_size_t, sigsetsize)
...
#endif /* CONFIG_COMPAT_32BIT_TIME */

/* compat handler for 64-bit time_t on 64-bit kernel */
#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE5(ppoll_time64, struct pollfd __user *, ufds,
        unsigned int,  nfds, struct __kernel_timespec __user *, tsp,
        const compat_sigset_t __user *, sigmask, compat_size_t, sigsetsize)
...
#endif /* CONFIG_COMPAT


I prototyped that approach now and ended up with
(relative to my current tested version):

 fs/aio.c        |  70 ++++++++++++++++------
 fs/select.c     | 181 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
 kernel/signal.c |  35 ++++++++++-
 net/compat.c    |  31 ++++++++++
 net/socket.c    |  21 ++++---
 5 files changed, 293 insertions(+), 45 deletions(-)

Full diff is at https://pastebin.com/j8USJpLq. I've changed ppoll, pselect6,
recvmmsg, rt_sigtimedwait, and io_pgetevents here; waitid() was already
done with four entry points, which happened to be simpler there either
way. There are now around 270 lines of additional duplicated system call
definitions, but in return the code does make more sense that way. Some of
that duplication (in particular in fs/select.c) can probably be recovered by
rearranging the code. By fully decoupling the 32-bit time handling from
compat mode, we also need yet another timespec variant besides
timespec (long/long), timespec64 (kernel internal s64/long),
__kernel_timespec (uapi s64/s64), and compat_timespec (s32/s32),
or rename all instances of compat_timespec to __kernel_timespec32.

I'm not convinced that one way or another is better here, please let me know
what you think.

       Arnd

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Jul 6, 2018 at 1:43 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> > On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <hch@infradead.org> wrote:
> >> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
> >>> defconfig, allmodconfig and nomodconfig.
> >>> And hence does not inlude definitions for compat data types.
> >>>
> >>> Now that time syscalls are being reused in non CONFIG_COMPAT
> >>> modes, include asm-generic definitions for riscv.
> >>>
> >>> Alternative would be to make compat_time.h to be conditional on
> >>> CONFIG_COMPAT_32BIT_TIME. But, since riscv is already has an
> >>> asm/compat.h include the generic version instead.
> >>
> >> Two comments here:
> >>
> >> First I think the current riscv compat.h is completely bogus.
> >> As you mentioned riscv does not actually have a compat mode, so
> >> having a compat.h makes no sensse at all, and the COMPAT_UTS_MACHINE
> >> override which is the only thing implemented is included in that
> >> statement.
> >
> > I was leaving the decision on how to clean up compat mode to the
> > architecture maintainers.
> > I wasn't sure if they were still in the middle of implementing it.
>
> If we only need it for 32 bit time_t, we can probably just use the
> asm-generic/compat.h for now.
>
> >> Second I think abusing compat.h for old syscall compatibility of any
> >> form is a really bad idea.  I think you need to split that part out,
> >> and preferably not using compat in the name, but something like
> >> old-time.h or time32.h for the name.
> >
> > Are you talking about just the header file or the way we are reusing
> > compat syscalls?
> > Either way, we have merged quite a few patches this way already.
> > I agree that having something like time32.h might be less confusing.
> > But, if you are worried about the former, then maybe we should propose
> > a cleanup after we finish what we are doing or back out the merged
> > patches.
> > For instance, posix_clock apis have already been changed this way.
>
> It would be easy to rename compat_time_t, compat_timespec and
> compat_timeval to something else if we could come up with a good
> name for them (we already have too many variants of each of
> them though, otherwise we end up being more confusing rather
> than less).

legacy_time_t etc.?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH v2 3/7] riscv: Include asm-generic/compat.h

[Arnd Bergmann]

On Thu, Jul 12, 2018 at 2:42 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Jul 6, 2018 at 1:43 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Fri, Jul 6, 2018 at 1:56 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>> > On Thu, Jul 5, 2018 at 3:21 PM, Christoph Hellwig <hch@infradead.org> wrote:
>> >> On Thu, Jul 05, 2018 at 02:36:00PM -0700, Deepa Dinamani wrote:
>>
>> It would be easy to rename compat_time_t, compat_timespec and
>> compat_timeval to something else if we could come up with a good
>> name for them (we already have too many variants of each of
>> them though, otherwise we end up being more confusing rather
>> than less).
>
> legacy_time_t etc.?

I think it should have '32' in the name, otherwise it might lead to confusion
regarding the size, as we also need legacy types that use 'long' (either
32-bit or 64-bit) seconds, besides the modern types that are always
64-bit.

In the previous patches, we introduced in the uapi

__kernel_timespec:     always 64-bit (both seconds and nanoseconds)
__kernel_old_timeval: replaces timeval (variable 'long' seconds/nanoseconds)

The __kernel_ prefix here signifies structures that are used in the
uapi headers and are possibly included in user space but must not
conflict with user space defined types like 'timeval' that can use either
'long' or 'long long' seconds in user space.

I would suggest we use __kernel_old_timespec for the equivalent
timespec variant (long/long) for consistency. I originally thought we
wouldn't need that one, but now it looks more likely that we do.
I still think we won't need a 64-bit '__kernel_timeval' type, but
it depends on what we do about getrusage(), getitimer() and
adjtimex().

For the pure 32-bit types, I'd prefer 'old' over 'legacy', which is
similar to the existing  __kernel_old_dev_t, __kernel_gid_t, and
__kernel_old_uid_t types, but we don't need the __kernel_
prefix because we would not use them in uapi headers.

I don't see a need for replacing compat_time_t right now
(I may be missing something I had in mind earlier), but
for timespec/timeval/itimerspec, how about old_timespec32,
old_timeval32 and old_itimerspec32 to replace
compat_timespec, compat_timeval and compat_itimerspec?

For itimerval, we probably need a __kernel_old_itimerval,
but no __kernel_itimerval or old_itimerval, similar to what we
do for timeval.

      Arnd