[PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

The series is a preparation series for individual architectures
to use 64 bit time_t syscalls in compat and 32 bit emulation modes.

This is a follow up to the series Arnd Bergmann posted:
https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]

Big picture is as per the lwn article:
https://lwn.net/Articles/643234/ [2]

The series is directed at converting posix clock syscalls:
clock_gettime, clock_settime, clock_getres and clock_nanosleep
to use a new data structure __kernel_timespec at syscall boundaries.
__kernel_timespec maintains 64 bit time_t across all execution modes.

vdso will be handled as part of each architecture when they enable
support for 64 bit time_t.

The compat syscalls are repurposed to provide backward compatibility
by using them as native syscalls as well for 32 bit architectures.
They will continue to use timespec at syscall boundaries.

CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec
or timespec at syscall boundaries.

The series does the following:
1. Enable compat syscalls on 32 bit architectures.
2. Add a new __kernel_timespec type to be used as the data structure
   for all the new syscalls.
3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in
   [1] and [2] to switch to new definition of __kernel_timespec. It is
   the same as struct timespec otherwise.
4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls.

* Changes since v1:
 * Introduce CONFIG_32BIT_TIME
 * Fixed zeroing out of higher order bits of tv_nsec
 * Included Arnd's changes to fix up use of compat headers

I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
legacy time syscalls such as sys_nanosleep because this will need to
enclose compat_sys_nanosleep as well. So, defining it as 

config LEGACY_TIME_SYSCALLS
     def_bool 64BIT || !64BIT_TIME

will not include compat_sys_nanosleep. We will instead need a new config to
exclusively mark legacy syscalls.

Deepa Dinamani (10):
  compat: Make compat helpers independent of CONFIG_COMPAT
  include: Move compat_timespec/ timeval to compat_time.h
  compat: enable compat_get/put_timespec64 always
  arch: introduce CONFIG_64BIT_TIME
  arch: Introduce CONFIG_COMPAT_32BIT_TIME
  posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME
  include: Add new y2038 safe __kernel_timespec
  fix get_timespec64() for y2038 safe compat interfaces
  change time types to new y2038 safe __kernel_* types
  nanosleep: change time types to safe __kernel_* types

 arch/Kconfig                           | 18 +++++++
 arch/arm64/include/asm/compat.h        | 11 ----
 arch/arm64/include/asm/stat.h          |  1 +
 arch/arm64/kernel/hw_breakpoint.c      |  1 -
 arch/arm64/kernel/perf_regs.c          |  2 +-
 arch/arm64/kernel/process.c            |  1 -
 arch/mips/include/asm/compat.h         | 11 ----
 arch/mips/kernel/signal32.c            |  2 +-
 arch/parisc/include/asm/compat.h       | 11 ----
 arch/powerpc/include/asm/compat.h      | 11 ----
 arch/powerpc/kernel/asm-offsets.c      |  2 +-
 arch/powerpc/oprofile/backtrace.c      |  2 +-
 arch/s390/hypfs/hypfs_sprp.c           |  1 -
 arch/s390/include/asm/compat.h         | 11 ----
 arch/s390/include/asm/elf.h            |  3 +-
 arch/s390/kvm/priv.c                   |  1 -
 arch/s390/pci/pci_clp.c                |  1 -
 arch/sparc/include/asm/compat.h        | 11 ----
 arch/tile/include/asm/compat.h         | 11 ----
 arch/x86/events/core.c                 |  2 +-
 arch/x86/include/asm/compat.h          | 11 ----
 arch/x86/include/asm/ftrace.h          |  2 +-
 arch/x86/include/asm/sys_ia32.h        |  2 +-
 arch/x86/kernel/sys_x86_64.c           |  2 +-
 drivers/s390/block/dasd_ioctl.c        |  1 -
 drivers/s390/char/fs3270.c             |  1 -
 drivers/s390/char/sclp_ctl.c           |  1 -
 drivers/s390/char/vmcp.c               |  1 -
 drivers/s390/cio/chsc_sch.c            |  1 -
 drivers/s390/net/qeth_core_main.c      |  2 +-
 drivers/staging/pi433/pi433_if.c       |  2 +-
 include/linux/compat.h                 | 11 ++--
 include/linux/compat_time.h            | 23 +++++++++
 include/linux/restart_block.h          |  7 +--
 include/linux/syscalls.h               | 12 ++---
 include/linux/time.h                   |  4 +-
 include/linux/time64.h                 | 10 +++-
 include/uapi/asm-generic/posix_types.h |  1 +
 include/uapi/linux/time.h              |  7 +++
 kernel/Makefile                        |  2 +-
 kernel/compat.c                        | 92 ++++++++++++++++++----------------
 kernel/time/hrtimer.c                  | 10 ++--
 kernel/time/posix-stubs.c              | 12 +++--
 kernel/time/posix-timers.c             | 24 ++++++---
 kernel/time/time.c                     | 10 +++-
 45 files changed, 175 insertions(+), 190 deletions(-)
 create mode 100644 include/linux/compat_time.h

base-commit: b0a84f19a5161418d4360cd57603e94ed489915e
-- 
2.14.1

Cc: acme@kernel.org
Cc: benh@kernel.crashing.org
Cc: borntraeger@de.ibm.com
Cc: catalin.marinas@arm.com
Cc: cmetcalf@mellanox.com
Cc: cohuck@redhat.com
Cc: davem@davemloft.net
Cc: deller@gmx.de
Cc: devel@driverdev.osuosl.org
Cc: gerald.schaefer@de.ibm.com
Cc: gregkh@linuxfoundation.org
Cc: heiko.carstens@de.ibm.com
Cc: hoeppner@linux.vnet.ibm.com
Cc: hpa@zytor.com
Cc: jejb@parisc-linux.org
Cc: jwi@linux.vnet.ibm.com
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: mark.rutland@arm.com
Cc: mingo@redhat.com
Cc: mpe@ellerman.id.au
Cc: oberpar@linux.vnet.ibm.com
Cc: oprofile-list@lists.sf.net
Cc: paulus@samba.org
Cc: peterz@infradead.org
Cc: ralf@linux-mips.org
Cc: rostedt@goodmis.org
Cc: rric@kernel.org
Cc: schwidefsky@de.ibm.com
Cc: sebott@linux.vnet.ibm.com
Cc: sparclinux@vger.kernel.org
Cc: sth@linux.vnet.ibm.com
Cc: ubraun@linux.vnet.ibm.com
Cc: will.deacon@arm.com
Cc: x86@kernel.org

[PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

The series is a preparation series for individual architectures
to use 64 bit time_t syscalls in compat and 32 bit emulation modes.

This is a follow up to the series Arnd Bergmann posted:
https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]

Big picture is as per the lwn article:
https://lwn.net/Articles/643234/ [2]

The series is directed at converting posix clock syscalls:
clock_gettime, clock_settime, clock_getres and clock_nanosleep
to use a new data structure __kernel_timespec at syscall boundaries.
__kernel_timespec maintains 64 bit time_t across all execution modes.

vdso will be handled as part of each architecture when they enable
support for 64 bit time_t.

The compat syscalls are repurposed to provide backward compatibility
by using them as native syscalls as well for 32 bit architectures.
They will continue to use timespec at syscall boundaries.

CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec
or timespec at syscall boundaries.

The series does the following:
1. Enable compat syscalls on 32 bit architectures.
2. Add a new __kernel_timespec type to be used as the data structure
   for all the new syscalls.
3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in
   [1] and [2] to switch to new definition of __kernel_timespec. It is
   the same as struct timespec otherwise.
4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls.

* Changes since v1:
 * Introduce CONFIG_32BIT_TIME
 * Fixed zeroing out of higher order bits of tv_nsec
 * Included Arnd's changes to fix up use of compat headers

I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
legacy time syscalls such as sys_nanosleep because this will need to
enclose compat_sys_nanosleep as well. So, defining it as 

config LEGACY_TIME_SYSCALLS
     def_bool 64BIT || !64BIT_TIME

will not include compat_sys_nanosleep. We will instead need a new config to
exclusively mark legacy syscalls.

Deepa Dinamani (10):
  compat: Make compat helpers independent of CONFIG_COMPAT
  include: Move compat_timespec/ timeval to compat_time.h
  compat: enable compat_get/put_timespec64 always
  arch: introduce CONFIG_64BIT_TIME
  arch: Introduce CONFIG_COMPAT_32BIT_TIME
  posix-clocks: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME
  include: Add new y2038 safe __kernel_timespec
  fix get_timespec64() for y2038 safe compat interfaces
  change time types to new y2038 safe __kernel_* types
  nanosleep: change time types to safe __kernel_* types

 arch/Kconfig                           | 18 +++++++
 arch/arm64/include/asm/compat.h        | 11 ----
 arch/arm64/include/asm/stat.h          |  1 +
 arch/arm64/kernel/hw_breakpoint.c      |  1 -
 arch/arm64/kernel/perf_regs.c          |  2 +-
 arch/arm64/kernel/process.c            |  1 -
 arch/mips/include/asm/compat.h         | 11 ----
 arch/mips/kernel/signal32.c            |  2 +-
 arch/parisc/include/asm/compat.h       | 11 ----
 arch/powerpc/include/asm/compat.h      | 11 ----
 arch/powerpc/kernel/asm-offsets.c      |  2 +-
 arch/powerpc/oprofile/backtrace.c      |  2 +-
 arch/s390/hypfs/hypfs_sprp.c           |  1 -
 arch/s390/include/asm/compat.h         | 11 ----
 arch/s390/include/asm/elf.h            |  3 +-
 arch/s390/kvm/priv.c                   |  1 -
 arch/s390/pci/pci_clp.c                |  1 -
 arch/sparc/include/asm/compat.h        | 11 ----
 arch/tile/include/asm/compat.h         | 11 ----
 arch/x86/events/core.c                 |  2 +-
 arch/x86/include/asm/compat.h          | 11 ----
 arch/x86/include/asm/ftrace.h          |  2 +-
 arch/x86/include/asm/sys_ia32.h        |  2 +-
 arch/x86/kernel/sys_x86_64.c           |  2 +-
 drivers/s390/block/dasd_ioctl.c        |  1 -
 drivers/s390/char/fs3270.c             |  1 -
 drivers/s390/char/sclp_ctl.c           |  1 -
 drivers/s390/char/vmcp.c               |  1 -
 drivers/s390/cio/chsc_sch.c            |  1 -
 drivers/s390/net/qeth_core_main.c      |  2 +-
 drivers/staging/pi433/pi433_if.c       |  2 +-
 include/linux/compat.h                 | 11 ++--
 include/linux/compat_time.h            | 23 +++++++++
 include/linux/restart_block.h          |  7 +--
 include/linux/syscalls.h               | 12 ++---
 include/linux/time.h                   |  4 +-
 include/linux/time64.h                 | 10 +++-
 include/uapi/asm-generic/posix_types.h |  1 +
 include/uapi/linux/time.h              |  7 +++
 kernel/Makefile                        |  2 +-
 kernel/compat.c                        | 92 ++++++++++++++++++----------------
 kernel/time/hrtimer.c                  | 10 ++--
 kernel/time/posix-stubs.c              | 12 +++--
 kernel/time/posix-timers.c             | 24 ++++++---
 kernel/time/time.c                     | 10 +++-
 45 files changed, 175 insertions(+), 190 deletions(-)
 create mode 100644 include/linux/compat_time.h

base-commit: b0a84f19a5161418d4360cd57603e94ed489915e
-- 
2.14.1

Cc: acme@kernel.org
Cc: benh@kernel.crashing.org
Cc: borntraeger@de.ibm.com
Cc: catalin.marinas@arm.com
Cc: cmetcalf@mellanox.com
Cc: cohuck@redhat.com
Cc: davem@davemloft.net
Cc: deller@gmx.de
Cc: devel@driverdev.osuosl.org
Cc: gerald.schaefer@de.ibm.com
Cc: gregkh@linuxfoundation.org
Cc: heiko.carstens@de.ibm.com
Cc: hoeppner@linux.vnet.ibm.com
Cc: hpa@zytor.com
Cc: jejb@parisc-linux.org
Cc: jwi@linux.vnet.ibm.com
Cc: linux-api@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: mark.rutland@arm.com
Cc: mingo@redhat.com
Cc: mpe@ellerman.id.au
Cc: oberpar@linux.vnet.ibm.com
Cc: oprofile-list@lists.sf.net
Cc: paulus@samba.org
Cc: peterz@infradead.org
Cc: ralf@linux-mips.org
Cc: rostedt@goodmis.org
Cc: rric@kernel.org
Cc: schwidefsky@de.ibm.com
Cc: sebott@linux.vnet.ibm.com
Cc: sparclinux@vger.kernel.org
Cc: sth@linux.vnet.ibm.com
Cc: ubraun@linux.vnet.ibm.com
Cc: will.deacon@arm.com
Cc: x86@kernel.org

[PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Deepa Dinamani]

The new struct __kernel_timespec is similar to current
internal kernel struct timespec64 on 64 bit architecture.
The compat structure however is similar to below on little
endian systems (padding and tv_nsec are switched for big
endian systems):

typedef s32            compat_long_t;
typedef s64            compat_kernel_time64_t;

struct compat_kernel_timespec {
       compat_kernel_time64_t  tv_sec;
       compat_long_t           tv_nsec;
       compat_long_t           padding;
};

This allows for both the native and compat representations to
be the same and syscalls using this type as part of their ABI
can have a single entry point to both.

Note that the compat define is not included anywhere in the
kernel explicitly to avoid confusion.

These types will be used by the new syscalls that will be
introduced in the consequent patches.
Most of the new syscalls are just an update to the existing
native ones with this new type. Hence, put this new type under
an ifdef so that the architectures can define CONFIG_64BIT_TIME
when they are ready to handle this switch.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
 include/linux/time64.h                 | 10 +++++++++-
 include/uapi/asm-generic/posix_types.h |  1 +
 include/uapi/linux/time.h              |  7 +++++++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/linux/time64.h b/include/linux/time64.h
index 93d39499838e..0d96887ba4e0 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -2,12 +2,20 @@
 #ifndef _LINUX_TIME64_H
 #define _LINUX_TIME64_H
 
-#include <uapi/linux/time.h>
 #include <linux/math64.h>
 
 typedef __s64 time64_t;
 typedef __u64 timeu64_t;
 
+/* CONFIG_64BIT_TIME enables new 64 bit time_t syscalls in the compat path
+ * and 32-bit emulation.
+ */
+#ifndef CONFIG_64BIT_TIME
+#define __kernel_timespec timespec
+#endif
+
+#include <uapi/linux/time.h>
+
 #if __BITS_PER_LONG == 64
 /* this trick allows us to optimize out timespec64_to_timespec */
 # define timespec64 timespec
diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
index 5e6ea22bd525..f0733a26ebfc 100644
--- a/include/uapi/asm-generic/posix_types.h
+++ b/include/uapi/asm-generic/posix_types.h
@@ -87,6 +87,7 @@ typedef struct {
 typedef __kernel_long_t	__kernel_off_t;
 typedef long long	__kernel_loff_t;
 typedef __kernel_long_t	__kernel_time_t;
+typedef long long __kernel_time64_t;
 typedef __kernel_long_t	__kernel_clock_t;
 typedef int		__kernel_timer_t;
 typedef int		__kernel_clockid_t;
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
index 53f8dd84beb5..0ad4510884b0 100644
--- a/include/uapi/linux/time.h
+++ b/include/uapi/linux/time.h
@@ -42,6 +42,13 @@ struct itimerval {
 	struct timeval it_value;	/* current value */
 };
 
+#ifndef __kernel_timespec
+struct __kernel_timespec {
+	__kernel_time64_t       tv_sec;                 /* seconds */
+	long long               tv_nsec;                /* nanoseconds */
+};
+#endif
+
 /*
  * The IDs of the various system clocks (for POSIX.1b interval timers):
  */
-- 
2.14.1

[PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Deepa Dinamani]

The new struct __kernel_timespec is similar to current
internal kernel struct timespec64 on 64 bit architecture.
The compat structure however is similar to below on little
endian systems (padding and tv_nsec are switched for big
endian systems):

typedef s32            compat_long_t;
typedef s64            compat_kernel_time64_t;

struct compat_kernel_timespec {
       compat_kernel_time64_t  tv_sec;
       compat_long_t           tv_nsec;
       compat_long_t           padding;
};

This allows for both the native and compat representations to
be the same and syscalls using this type as part of their ABI
can have a single entry point to both.

Note that the compat define is not included anywhere in the
kernel explicitly to avoid confusion.

These types will be used by the new syscalls that will be
introduced in the consequent patches.
Most of the new syscalls are just an update to the existing
native ones with this new type. Hence, put this new type under
an ifdef so that the architectures can define CONFIG_64BIT_TIME
when they are ready to handle this switch.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
 include/linux/time64.h                 | 10 +++++++++-
 include/uapi/asm-generic/posix_types.h |  1 +
 include/uapi/linux/time.h              |  7 +++++++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/linux/time64.h b/include/linux/time64.h
index 93d39499838e..0d96887ba4e0 100644
--- a/include/linux/time64.h
+++ b/include/linux/time64.h
@@ -2,12 +2,20 @@
 #ifndef _LINUX_TIME64_H
 #define _LINUX_TIME64_H
 
-#include <uapi/linux/time.h>
 #include <linux/math64.h>
 
 typedef __s64 time64_t;
 typedef __u64 timeu64_t;
 
+/* CONFIG_64BIT_TIME enables new 64 bit time_t syscalls in the compat path
+ * and 32-bit emulation.
+ */
+#ifndef CONFIG_64BIT_TIME
+#define __kernel_timespec timespec
+#endif
+
+#include <uapi/linux/time.h>
+
 #if __BITS_PER_LONG == 64
 /* this trick allows us to optimize out timespec64_to_timespec */
 # define timespec64 timespec
diff --git a/include/uapi/asm-generic/posix_types.h b/include/uapi/asm-generic/posix_types.h
index 5e6ea22bd525..f0733a26ebfc 100644
--- a/include/uapi/asm-generic/posix_types.h
+++ b/include/uapi/asm-generic/posix_types.h
@@ -87,6 +87,7 @@ typedef struct {
 typedef __kernel_long_t	__kernel_off_t;
 typedef long long	__kernel_loff_t;
 typedef __kernel_long_t	__kernel_time_t;
+typedef long long __kernel_time64_t;
 typedef __kernel_long_t	__kernel_clock_t;
 typedef int		__kernel_timer_t;
 typedef int		__kernel_clockid_t;
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
index 53f8dd84beb5..0ad4510884b0 100644
--- a/include/uapi/linux/time.h
+++ b/include/uapi/linux/time.h
@@ -42,6 +42,13 @@ struct itimerval {
 	struct timeval it_value;	/* current value */
 };
 
+#ifndef __kernel_timespec
+struct __kernel_timespec {
+	__kernel_time64_t       tv_sec;                 /* seconds */
+	long long               tv_nsec;                /* nanoseconds */
+};
+#endif
+
 /*
  * The IDs of the various system clocks (for POSIX.1b interval timers):
  */
-- 
2.14.1

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Mon, Nov 27, 2017 at 8:30 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> The series is a preparation series for individual architectures
> to use 64 bit time_t syscalls in compat and 32 bit emulation modes.
>
> This is a follow up to the series Arnd Bergmann posted:
> https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]
>
> Big picture is as per the lwn article:
> https://lwn.net/Articles/643234/ [2]
>
> The series is directed at converting posix clock syscalls:
> clock_gettime, clock_settime, clock_getres and clock_nanosleep
> to use a new data structure __kernel_timespec at syscall boundaries.
> __kernel_timespec maintains 64 bit time_t across all execution modes.
>
> vdso will be handled as part of each architecture when they enable
> support for 64 bit time_t.
>
> The compat syscalls are repurposed to provide backward compatibility
> by using them as native syscalls as well for 32 bit architectures.
> They will continue to use timespec at syscall boundaries.
>
> CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec
> or timespec at syscall boundaries.
>
> The series does the following:
> 1. Enable compat syscalls on 32 bit architectures.
> 2. Add a new __kernel_timespec type to be used as the data structure
>    for all the new syscalls.
> 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in
>    [1] and [2] to switch to new definition of __kernel_timespec. It is
>    the same as struct timespec otherwise.
> 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls.
>
> * Changes since v1:
>  * Introduce CONFIG_32BIT_TIME
>  * Fixed zeroing out of higher order bits of tv_nsec
>  * Included Arnd's changes to fix up use of compat headers

Very nice. I think it would be good to get this into linux-next soon so we
can build on top of this. I have submitted most other y2038 patches today
that don't depend on either this or one of my other patches.

There is one patch that I want to do but haven't imlpemented yet, to merge
get_timespec64() and compat_get_timespec() into one function that
take a bunch of flags (check nanosecond, nano/microsecond,
zero upper half of nanoseconds, 32-bit or 64-bit wide), since I found
a few functions that need more than one of these, and they don't
all need the same combinations. My patch will certainly conflict
with yours, as your touch the same functions, but that's fine.

If you end up doing another version of the series though, it might
be better to move the compat accessors into kernel/time/time.c
along with the native functions, that should make it easier to
consolidate them later.

> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
> legacy time syscalls such as sys_nanosleep because this will need to
> enclose compat_sys_nanosleep as well. So, defining it as
>
> config LEGACY_TIME_SYSCALLS
>      def_bool 64BIT || !64BIT_TIME
>
> will not include compat_sys_nanosleep. We will instead need a new config to
> exclusively mark legacy syscalls.

Do you mean we would need to do this separately for native and compat
syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

       Arnd

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Mon, Nov 27, 2017 at 8:30 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> The series is a preparation series for individual architectures
> to use 64 bit time_t syscalls in compat and 32 bit emulation modes.
>
> This is a follow up to the series Arnd Bergmann posted:
> https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]
>
> Big picture is as per the lwn article:
> https://lwn.net/Articles/643234/ [2]
>
> The series is directed at converting posix clock syscalls:
> clock_gettime, clock_settime, clock_getres and clock_nanosleep
> to use a new data structure __kernel_timespec at syscall boundaries.
> __kernel_timespec maintains 64 bit time_t across all execution modes.
>
> vdso will be handled as part of each architecture when they enable
> support for 64 bit time_t.
>
> The compat syscalls are repurposed to provide backward compatibility
> by using them as native syscalls as well for 32 bit architectures.
> They will continue to use timespec at syscall boundaries.
>
> CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec
> or timespec at syscall boundaries.
>
> The series does the following:
> 1. Enable compat syscalls on 32 bit architectures.
> 2. Add a new __kernel_timespec type to be used as the data structure
>    for all the new syscalls.
> 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in
>    [1] and [2] to switch to new definition of __kernel_timespec. It is
>    the same as struct timespec otherwise.
> 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls.
>
> * Changes since v1:
>  * Introduce CONFIG_32BIT_TIME
>  * Fixed zeroing out of higher order bits of tv_nsec
>  * Included Arnd's changes to fix up use of compat headers

Very nice. I think it would be good to get this into linux-next soon so we
can build on top of this. I have submitted most other y2038 patches today
that don't depend on either this or one of my other patches.

There is one patch that I want to do but haven't imlpemented yet, to merge
get_timespec64() and compat_get_timespec() into one function that
take a bunch of flags (check nanosecond, nano/microsecond,
zero upper half of nanoseconds, 32-bit or 64-bit wide), since I found
a few functions that need more than one of these, and they don't
all need the same combinations. My patch will certainly conflict
with yours, as your touch the same functions, but that's fine.

If you end up doing another version of the series though, it might
be better to move the compat accessors into kernel/time/time.c
along with the native functions, that should make it easier to
consolidate them later.

> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
> legacy time syscalls such as sys_nanosleep because this will need to
> enclose compat_sys_nanosleep as well. So, defining it as
>
> config LEGACY_TIME_SYSCALLS
>      def_bool 64BIT || !64BIT_TIME
>
> will not include compat_sys_nanosleep. We will instead need a new config to
> exclusively mark legacy syscalls.

Do you mean we would need to do this separately for native and compat
syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

       Arnd

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>> legacy time syscalls such as sys_nanosleep because this will need to
>> enclose compat_sys_nanosleep as well. So, defining it as
>>
>> config LEGACY_TIME_SYSCALLS
>>      def_bool 64BIT || !64BIT_TIME
>>
>> will not include compat_sys_nanosleep. We will instead need a new config to
>> exclusively mark legacy syscalls.
>
> Do you mean we would need to do this separately for native and compat
> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.

I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
along with other compat syscalls.
So, if we define the LEGACY_TIME_SYSCALLS as


        "This controls the compilation of the following system calls:
        time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
        setitimer, select, utime, utimes, futimesat, and
{old,new}{l,f,}stat{,64}.
        These all pass 32-bit time_t arguments on 32-bit architectures and
        are replaced by other interfaces (e.g. posix timers and clocks, statx).
        C libraries implementing 64-bit time_t in 32-bit architectures have to
        implement the handles by wrapping around the newer interfaces.
        New architectures should not explicitly enable this."

This would not be really true as compat interfaces have nothing to do
with this config.

I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
then have all these "deprecated" syscalls be enclosed within this,
compat or not.
This will also mean that we will have to come up representing these
syscalls in the syscall header files.
This can be a separate patch and this series can be merged as is if
everyone agrees.

-Deepa

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>>> legacy time syscalls such as sys_nanosleep because this will need to
>>> enclose compat_sys_nanosleep as well. So, defining it as
>>>
>>> config LEGACY_TIME_SYSCALLS
>>>      def_bool 64BIT || !64BIT_TIME
>>>
>>> will not include compat_sys_nanosleep. We will instead need a new config to
>>> exclusively mark legacy syscalls.
>>
>> Do you mean we would need to do this separately for native and compat
>> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
>> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
>> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
>> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
>
> I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
> compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
> along with other compat syscalls.
> So, if we define the LEGACY_TIME_SYSCALLS as
>
>
>         "This controls the compilation of the following system calls:
>         time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> alarm, getitimer,
>         setitimer, select, utime, utimes, futimesat, and
> {old,new}{l,f,}stat{,64}.
>         These all pass 32-bit time_t arguments on 32-bit architectures and
>         are replaced by other interfaces (e.g. posix timers and clocks, statx).
>         C libraries implementing 64-bit time_t in 32-bit architectures have to
>         implement the handles by wrapping around the newer interfaces.
>         New architectures should not explicitly enable this."
>
> This would not be really true as compat interfaces have nothing to do
> with this config.
>
> I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
> then have all these "deprecated" syscalls be enclosed within this,
> compat or not.
> This will also mean that we will have to come up representing these
> syscalls in the syscall header files.
> This can be a separate patch and this series can be merged as is if
> everyone agrees.

I think doing this separately  would be good, I don't see any interdependency
with the other patches, we just need to decide what we want in the long
run.

I agree my text that you cited doesn't capture the situation correctly,
as this is really about the obsolete system calls that take 64-bit time_t
arguments on architectures that are converted to allow 64-bit time_t
for non-obsolete system calls.

Maybe it's better to just reword this to

      "This controls the compilation of the following system calls:
      time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
      setitimer, select, utime, utimes, futimesat, and {old,new}{l,f,}stat{,64}.
      These are all replaced by other interfaces (e.g. posix timers and clocks,
      statx) on architectures that got converted from 32-bit time_t to
64-bit time_t.
      C libraries implementing 64-bit time_t in 32-bit architectures have to
      implement the handles by wrapping around the newer interfaces.
      New architectures should not explicitly enable this."

That would clarify that it's not about the compat system calls, while
also allowing the two options to be set independently.

        Arnd

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>>> legacy time syscalls such as sys_nanosleep because this will need to
>>> enclose compat_sys_nanosleep as well. So, defining it as
>>>
>>> config LEGACY_TIME_SYSCALLS
>>>      def_bool 64BIT || !64BIT_TIME
>>>
>>> will not include compat_sys_nanosleep. We will instead need a new config to
>>> exclusively mark legacy syscalls.
>>
>> Do you mean we would need to do this separately for native and compat
>> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
>> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
>> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
>> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
>
> I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
> compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
> along with other compat syscalls.
> So, if we define the LEGACY_TIME_SYSCALLS as
>
>
>         "This controls the compilation of the following system calls:
>         time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> alarm, getitimer,
>         setitimer, select, utime, utimes, futimesat, and
> {old,new}{l,f,}stat{,64}.
>         These all pass 32-bit time_t arguments on 32-bit architectures and
>         are replaced by other interfaces (e.g. posix timers and clocks, statx).
>         C libraries implementing 64-bit time_t in 32-bit architectures have to
>         implement the handles by wrapping around the newer interfaces.
>         New architectures should not explicitly enable this."
>
> This would not be really true as compat interfaces have nothing to do
> with this config.
>
> I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
> then have all these "deprecated" syscalls be enclosed within this,
> compat or not.
> This will also mean that we will have to come up representing these
> syscalls in the syscall header files.
> This can be a separate patch and this series can be merged as is if
> everyone agrees.

I think doing this separately  would be good, I don't see any interdependency
with the other patches, we just need to decide what we want in the long
run.

I agree my text that you cited doesn't capture the situation correctly,
as this is really about the obsolete system calls that take 64-bit time_t
arguments on architectures that are converted to allow 64-bit time_t
for non-obsolete system calls.

Maybe it's better to just reword this to

      "This controls the compilation of the following system calls:
      time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
alarm, getitimer,
      setitimer, select, utime, utimes, futimesat, and {old,new}{l,f,}stat{,64}.
      These are all replaced by other interfaces (e.g. posix timers and clocks,
      statx) on architectures that got converted from 32-bit time_t to
64-bit time_t.
      C libraries implementing 64-bit time_t in 32-bit architectures have to
      implement the handles by wrapping around the newer interfaces.
      New architectures should not explicitly enable this."

That would clarify that it's not about the compat system calls, while
also allowing the two options to be set independently.

        Arnd

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>>>> legacy time syscalls such as sys_nanosleep because this will need to
>>>> enclose compat_sys_nanosleep as well. So, defining it as
>>>>
>>>> config LEGACY_TIME_SYSCALLS
>>>>      def_bool 64BIT || !64BIT_TIME
>>>>
>>>> will not include compat_sys_nanosleep. We will instead need a new config to
>>>> exclusively mark legacy syscalls.
>>>
>>> Do you mean we would need to do this separately for native and compat
>>> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
>>> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
>>> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
>>> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
>>
>> I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
>> compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
>> along with other compat syscalls.
>> So, if we define the LEGACY_TIME_SYSCALLS as
>>
>>
>>         "This controls the compilation of the following system calls:
>>         time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
>> alarm, getitimer,
>>         setitimer, select, utime, utimes, futimesat, and
>> {old,new}{l,f,}stat{,64}.
>>         These all pass 32-bit time_t arguments on 32-bit architectures and
>>         are replaced by other interfaces (e.g. posix timers and clocks, statx).
>>         C libraries implementing 64-bit time_t in 32-bit architectures have to
>>         implement the handles by wrapping around the newer interfaces.
>>         New architectures should not explicitly enable this."
>>
>> This would not be really true as compat interfaces have nothing to do
>> with this config.
>>
>> I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
>> then have all these "deprecated" syscalls be enclosed within this,
>> compat or not.
>> This will also mean that we will have to come up representing these
>> syscalls in the syscall header files.
>> This can be a separate patch and this series can be merged as is if
>> everyone agrees.
>
> I think doing this separately  would be good, I don't see any interdependency
> with the other patches, we just need to decide what we want in the long
> run.

Right. There are three options:

1. Use two configs to identify which syscalls need not be supported by
new architectures.
In this case it makes sense to say LEGACY_TIME_SYSCALLS and
COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
I can reword the config to what you mention below.

2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
mentioned below only.
In this case only the native and compat functions of the below
mentioned syscalls need to be identified by the config. I like this
option as this clearly identifies which syscalls are deprecated and do
not have a 64 bit counterpart. Not all architectures need to support
turning this off.

3. If we don't need either 1 or 2, then we could stick with what we
have today in the series as CONFIG_64BIT_TIME will be deleted and they
only need #ifdef CONFIG_64BIT.

Let me know if anyone prefers something else.

> I agree my text that you cited doesn't capture the situation correctly,
> as this is really about the obsolete system calls that take 64-bit time_t
> arguments on architectures that are converted to allow 64-bit time_t
> for non-obsolete system calls.
>
> Maybe it's better to just reword this to
>
>       "This controls the compilation of the following system calls:
>       time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> alarm, getitimer,
>       setitimer, select, utime, utimes, futimesat, and {old,new}{l,f,}stat{,64}.
>       These are all replaced by other interfaces (e.g. posix timers and clocks,
>       statx) on architectures that got converted from 32-bit time_t to
> 64-bit time_t.
>       C libraries implementing 64-bit time_t in 32-bit architectures have to
>       implement the handles by wrapping around the newer interfaces.
>       New architectures should not explicitly enable this."
>
> That would clarify that it's not about the compat system calls, while
> also allowing the two options to be set independently.

-Deepa

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>>>> I decided against using LEGACY_TIME_SYSCALLS to conditionally compile
>>>> legacy time syscalls such as sys_nanosleep because this will need to
>>>> enclose compat_sys_nanosleep as well. So, defining it as
>>>>
>>>> config LEGACY_TIME_SYSCALLS
>>>>      def_bool 64BIT || !64BIT_TIME
>>>>
>>>> will not include compat_sys_nanosleep. We will instead need a new config to
>>>> exclusively mark legacy syscalls.
>>>
>>> Do you mean we would need to do this separately for native and compat
>>> syscalls, and have yet another option, like LEGACY_TIME_SYSCALLS
>>> and LEGACY_TIME_COMPAT_SYSCALLS, to cover all cases? I would
>>> think that CONFIG_COMPAT_32BIT_TIME handles all the compat versions,
>>> while CONFIG_LEGACY_TIME_SYSCALLS handles all the native ones.
>>
>> I meant sys_nanosleep would be covered by LEGACY_TIME_SYSCALLS, but
>> compat_sys_nanosleep would be covered by CONFIG_COMPAT_32BIT_TIME
>> along with other compat syscalls.
>> So, if we define the LEGACY_TIME_SYSCALLS as
>>
>>
>>         "This controls the compilation of the following system calls:
>>         time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
>> alarm, getitimer,
>>         setitimer, select, utime, utimes, futimesat, and
>> {old,new}{l,f,}stat{,64}.
>>         These all pass 32-bit time_t arguments on 32-bit architectures and
>>         are replaced by other interfaces (e.g. posix timers and clocks, statx).
>>         C libraries implementing 64-bit time_t in 32-bit architectures have to
>>         implement the handles by wrapping around the newer interfaces.
>>         New architectures should not explicitly enable this."
>>
>> This would not be really true as compat interfaces have nothing to do
>> with this config.
>>
>> I was proposing that we could have LEGACY_TIME_SYSCALLS config, but
>> then have all these "deprecated" syscalls be enclosed within this,
>> compat or not.
>> This will also mean that we will have to come up representing these
>> syscalls in the syscall header files.
>> This can be a separate patch and this series can be merged as is if
>> everyone agrees.
>
> I think doing this separately  would be good, I don't see any interdependency
> with the other patches, we just need to decide what we want in the long
> run.

Right. There are three options:

1. Use two configs to identify which syscalls need not be supported by
new architectures.
In this case it makes sense to say LEGACY_TIME_SYSCALLS and
COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
I can reword the config to what you mention below.

2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
mentioned below only.
In this case only the native and compat functions of the below
mentioned syscalls need to be identified by the config. I like this
option as this clearly identifies which syscalls are deprecated and do
not have a 64 bit counterpart. Not all architectures need to support
turning this off.

3. If we don't need either 1 or 2, then we could stick with what we
have today in the series as CONFIG_64BIT_TIME will be deleted and they
only need #ifdef CONFIG_64BIT.

Let me know if anyone prefers something else.

> I agree my text that you cited doesn't capture the situation correctly,
> as this is really about the obsolete system calls that take 64-bit time_t
> arguments on architectures that are converted to allow 64-bit time_t
> for non-obsolete system calls.
>
> Maybe it's better to just reword this to
>
>       "This controls the compilation of the following system calls:
>       time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> alarm, getitimer,
>       setitimer, select, utime, utimes, futimesat, and {old,new}{l,f,}stat{,64}.
>       These are all replaced by other interfaces (e.g. posix timers and clocks,
>       statx) on architectures that got converted from 32-bit time_t to
> 64-bit time_t.
>       C libraries implementing 64-bit time_t in 32-bit architectures have to
>       implement the handles by wrapping around the newer interfaces.
>       New architectures should not explicitly enable this."
>
> That would clarify that it's not about the compat system calls, while
> also allowing the two options to be set independently.

-Deepa

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

Re: [PATCH v2 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Wed, Nov 29, 2017 at 12:17 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 6:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Nov 27, 2017 at 11:29 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> Right. There are three options:
>
> 1. Use two configs to identify which syscalls need not be supported by
> new architectures.
> In this case it makes sense to say LEGACY_TIME_SYSCALLS and
> COMPAT_32BIT_TIME both need to be disabled for new architectures. And,
> I can reword the config to what you mention below.
>
> 2. Make the LEGACY_TIME_SYSCALLS eliminate non y2038 safe syscalls
> mentioned below only.
> In this case only the native and compat functions of the below
> mentioned syscalls need to be identified by the config. I like this
> option as this clearly identifies which syscalls are deprecated and do
> not have a 64 bit counterpart. Not all architectures need to support
> turning this off.
>
> 3. If we don't need either 1 or 2, then we could stick with what we
> have today in the series as CONFIG_64BIT_TIME will be deleted and they
> only need #ifdef CONFIG_64BIT.
>
> Let me know if anyone prefers something else.

I think I prefer to have both LEGACY_TIME_SYSCALLS to guard
the native deprecated syscalls (disabled on 32-bit architectures after
the conversion, and enabled on 64-bit architectures until
we merge the next one), and COMPAT_32BIT_TIME to guard the
compat versions of both the deprecated and the non-deprecated
syscalls (enabled on all existing 32-bit architectures after the
conversion, and on 64-bit architectures if they provide a compat
mode for the former).

Those two are not symmetric, but I think those are the most
common combinations, and the Kconfig symbol helps document
what they are.

There is one more category for things like io_getevents() and
rt_sigtimedwait that also need two separate compat versions,
one for 32-bit time_t and one for 64-bit time_t, but it seems better
to deal with those case-by-case rather than introducing another
Kconfig symbol.

        Arnd

Re: [Y2038] [PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Ben Hutchings]

On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
> The new struct __kernel_timespec is similar to current
> internal kernel struct timespec64 on 64 bit architecture.
> The compat structure however is similar to below on little
> endian systems (padding and tv_nsec are switched for big
> endian systems):
> 
> typedef s32            compat_long_t;
> typedef s64            compat_kernel_time64_t;
> 
> struct compat_kernel_timespec {
>        compat_kernel_time64_t  tv_sec;
>        compat_long_t           tv_nsec;
>        compat_long_t           padding;
> };
> 
> This allows for both the native and compat representations to
> be the same and syscalls using this type as part of their ABI
> can have a single entry point to both.
> 
> Note that the compat define is not included anywhere in the
> kernel explicitly to avoid confusion.

If I understand correctly, the intent here is that C libraries will be
allowed to define struct timespec like that when appropriate feature
macros are enabled.  Could you spell that out in the commit message,
and also the need to clear padding on the kernel side?

[...]
> --- a/include/uapi/linux/time.h
> +++ b/include/uapi/linux/time.h
> @@ -42,6 +42,13 @@ struct itimerval {
> > >  	struct timeval it_value;	/* current value */
>  };
>  
> +#ifndef __kernel_timespec
> +struct __kernel_timespec {
> +	__kernel_time64_t       tv_sec;                 /* seconds */
> +	long long               tv_nsec;                /* nanoseconds */
> +};
> +#endif

I wonder if it makes sense to override the alignment of this structure?
 (64-bit types are aligned differently on 32-bit vs 64-bit x86, but not
other compat cases.)  It might reduce the need for conversions in
compat code elsewhere later.

Ben.

>  /*
>   * The IDs of the various system clocks (for POSIX.1b interval timers):
>   */
-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Re: [PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Arnd Bergmann]

On Fri, Dec 15, 2017 at 1:11 AM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
>> --- a/include/uapi/linux/time.h
>> +++ b/include/uapi/linux/time.h
>> @@ -42,6 +42,13 @@ struct itimerval {
>> > >   struct timeval it_value;        /* current value */
>>  };
>>
>> +#ifndef __kernel_timespec
>> +struct __kernel_timespec {
>> +     __kernel_time64_t       tv_sec;                 /* seconds */
>> +     long long               tv_nsec;                /* nanoseconds */
>> +};
>> +#endif
>
> I wonder if it makes sense to override the alignment of this structure?
>  (64-bit types are aligned differently on 32-bit vs 64-bit x86, but not
> other compat cases.)  It might reduce the need for conversions in
> compat code elsewhere later.

I think the alignment here should be agreed with glibc so they use the
same alignment for their new timespec. I don't see a specific mention
of this at
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct___timespec64
so I'm adding Albert and libc-alpha to Cc for clarification.

I agree it would simplify things a bit to ensure that time64_t and
__timespec64/__kernel_timespec have a 64-bit alignment even on
x86-32, but I don't know if there is precedent for using gcc
__attribute__((aligned(8)) on POSIX data types, of if that might
cause problems e.g. for non-gnu compilers.

       Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

Re: [Y2038] [PATCH v2 07/10] include: Add new y2038 safe __kernel_timespec

[Arnd Bergmann]

On Fri, Dec 15, 2017 at 1:11 AM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Mon, 2017-11-27 at 11:30 -0800, Deepa Dinamani wrote:
>> --- a/include/uapi/linux/time.h
>> +++ b/include/uapi/linux/time.h
>> @@ -42,6 +42,13 @@ struct itimerval {
>> > >   struct timeval it_value;        /* current value */
>>  };
>>
>> +#ifndef __kernel_timespec
>> +struct __kernel_timespec {
>> +     __kernel_time64_t       tv_sec;                 /* seconds */
>> +     long long               tv_nsec;                /* nanoseconds */
>> +};
>> +#endif
>
> I wonder if it makes sense to override the alignment of this structure?
>  (64-bit types are aligned differently on 32-bit vs 64-bit x86, but not
> other compat cases.)  It might reduce the need for conversions in
> compat code elsewhere later.

I think the alignment here should be agreed with glibc so they use the
same alignment for their new timespec. I don't see a specific mention
of this at
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign#struct___timespec64
so I'm adding Albert and libc-alpha to Cc for clarification.

I agree it would simplify things a bit to ensure that time64_t and
__timespec64/__kernel_timespec have a 64-bit alignment even on
x86-32, but I don't know if there is precedent for using gcc
__attribute__((aligned(8)) on POSIX data types, of if that might
cause problems e.g. for non-gnu compilers.

       Arnd