[PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[PATCH 0/9] 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

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

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 unconditionally.
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.

Arnd Bergmann (1):
  y2038: introduce CONFIG_64BIT_TIME

Deepa Dinamani (8):
  include: Move compat_timespec/ timeval to compat_time.h
  compat: Make compat helpers independent of CONFIG_COMPAT
  compat: enable compat_get/put_timespec64 always
  posix-clocks: Enable compat syscalls always
  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                           | 11 ++++
 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                 |  7 ++-
 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                  |  7 +--
 kernel/time/posix-stubs.c              | 12 ++---
 kernel/time/posix-timers.c             | 20 ++++----
 kernel/time/time.c                     | 10 +++-
 45 files changed, 152 insertions(+), 195 deletions(-)
 create mode 100644 include/linux/compat_time.h


base-commit: d9e0e63d9a6f88440eb201e1491fcf730272c706
-- 
2.11.0

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 8/9] change time types to new y2038 safe __kernel_* types

[Deepa Dinamani]

Change over clock_settime, clock_gettime and clock_getres
syscalls to use __kernel_timespec times. This will enable
changing over of these syscalls to use new y2038 safe syscalls
when the architectures define the CONFIG_64BIT_TIME.

Cc: linux-api@vger.kernel.org
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
---
 include/linux/syscalls.h   | 6 +++---
 kernel/time/posix-stubs.c  | 6 +++---
 kernel/time/posix-timers.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a78186d826d7..7ac1bb9ea7da 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -309,13 +309,13 @@ asmlinkage long sys_timer_settime(timer_t timer_id, int flags,
 				struct itimerspec __user *old_setting);
 asmlinkage long sys_timer_delete(timer_t timer_id);
 asmlinkage long sys_clock_settime(clockid_t which_clock,
-				const struct timespec __user *tp);
+				const struct __kernel_timespec __user *tp);
 asmlinkage long sys_clock_gettime(clockid_t which_clock,
-				struct timespec __user *tp);
+				struct __kernel_timespec __user *tp);
 asmlinkage long sys_clock_adjtime(clockid_t which_clock,
 				struct timex __user *tx);
 asmlinkage long sys_clock_getres(clockid_t which_clock,
-				struct timespec __user *tp);
+				struct __kernel_timespec __user *tp);
 asmlinkage long sys_clock_nanosleep(clockid_t which_clock, int flags,
 				const struct timespec __user *rqtp,
 				struct timespec __user *rmtp);
diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index b2dc97a39c35..684d470dba2c 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -49,7 +49,7 @@ SYS_NI(alarm);
  */
 
 SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
-		const struct timespec __user *, tp)
+		const struct __kernel_timespec __user *, tp)
 {
 	struct timespec64 new_tp;
 
@@ -80,7 +80,7 @@ int do_clock_gettime(clockid_t which_clock, struct timespec64 *tp)
 	return 0;
 }
 SYSCALL_DEFINE2(clock_gettime, const clockid_t, which_clock,
-		struct timespec __user *, tp)
+		struct __kernel_timespec __user *, tp)
 {
 	int ret;
 	struct timespec64 kernel_tp;
@@ -94,7 +94,7 @@ SYSCALL_DEFINE2(clock_gettime, const clockid_t, which_clock,
 	return 0;
 }
 
-SYSCALL_DEFINE2(clock_getres, const clockid_t, which_clock, struct timespec __user *, tp)
+SYSCALL_DEFINE2(clock_getres, const clockid_t, which_clock, struct __kernel_timespec __user *, tp)
 {
 	struct timespec64 rtn_tp = {
 		.tv_sec = 0,
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 0650ec27a673..d482359bce1b 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -1034,7 +1034,7 @@ void exit_itimers(struct signal_struct *sig)
 }
 
 SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
-		const struct timespec __user *, tp)
+		const struct __kernel_timespec __user *, tp)
 {
 	const struct k_clock *kc = clockid_to_kclock(which_clock);
 	struct timespec64 new_tp;
@@ -1049,7 +1049,7 @@ SYSCALL_DEFINE2(clock_settime, const clockid_t, which_clock,
 }
 
 SYSCALL_DEFINE2(clock_gettime, const clockid_t, which_clock,
-		struct timespec __user *,tp)
+		struct __kernel_timespec __user *, tp)
 {
 	const struct k_clock *kc = clockid_to_kclock(which_clock);
 	struct timespec64 kernel_tp;
@@ -1090,7 +1090,7 @@ SYSCALL_DEFINE2(clock_adjtime, const clockid_t, which_clock,
 }
 
 SYSCALL_DEFINE2(clock_getres, const clockid_t, which_clock,
-		struct timespec __user *, tp)
+		struct __kernel_timespec __user *, tp)
 {
 	const struct k_clock *kc = clockid_to_kclock(which_clock);
 	struct timespec64 rtn_tp;
-- 
2.11.0

[PATCH 9/9] nanosleep: change time types to safe __kernel_* types

[Deepa Dinamani]

Change over clock_nanosleep syscalls to use y2038 safe
__kernel_timespec times. This will enable changing over
of these syscalls to use new y2038 safe syscalls when
the architectures define the CONFIG_64BIT_TIME.

Note that nanosleep syscall is deprecated and does not have a
plan for making it y2038 safe. But, the syscall should work as
before on 64 bit machines and on 32 bit machines, the syscall
works correctly until y2038 as before using the existing compat
syscall version. There is no new syscall for supporting 64 bit
time_t on 32 bit architectures.

Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Deepa Dinamani <deepa.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 include/linux/restart_block.h | 7 ++-----
 include/linux/syscalls.h      | 6 +++---
 kernel/time/hrtimer.c         | 4 ++--
 kernel/time/posix-stubs.c     | 4 ++--
 kernel/time/posix-timers.c    | 4 ++--
 5 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/include/linux/restart_block.h b/include/linux/restart_block.h
index bcfdb918cd81..5d83d0c1d06c 100644
--- a/include/linux/restart_block.h
+++ b/include/linux/restart_block.h
@@ -7,6 +7,7 @@
 
 #include <linux/compiler.h>
 #include <linux/types.h>
+#include <linux/time64.h>
 
 struct timespec;
 struct compat_timespec;
@@ -15,9 +16,7 @@ struct pollfd;
 enum timespec_type {
 	TT_NONE		= 0,
 	TT_NATIVE	= 1,
-#ifdef CONFIG_COMPAT
 	TT_COMPAT	= 2,
-#endif
 };
 
 /*
@@ -40,10 +39,8 @@ struct restart_block {
 			clockid_t clockid;
 			enum timespec_type type;
 			union {
-				struct timespec __user *rmtp;
-#ifdef CONFIG_COMPAT
+				struct __kernel_timespec __user *rmtp;
 				struct compat_timespec __user *compat_rmtp;
-#endif
 			};
 			u64 expires;
 		} nanosleep;
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 7ac1bb9ea7da..4df16a70b0d7 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -254,7 +254,7 @@ asmlinkage long sys_adjtimex(struct timex __user *txc_p);
 asmlinkage long sys_times(struct tms __user *tbuf);
 
 asmlinkage long sys_gettid(void);
-asmlinkage long sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp);
+asmlinkage long sys_nanosleep(struct __kernel_timespec __user *rqtp, struct __kernel_timespec __user *rmtp);
 asmlinkage long sys_alarm(unsigned int seconds);
 asmlinkage long sys_getpid(void);
 asmlinkage long sys_getppid(void);
@@ -317,8 +317,8 @@ asmlinkage long sys_clock_adjtime(clockid_t which_clock,
 asmlinkage long sys_clock_getres(clockid_t which_clock,
 				struct __kernel_timespec __user *tp);
 asmlinkage long sys_clock_nanosleep(clockid_t which_clock, int flags,
-				const struct timespec __user *rqtp,
-				struct timespec __user *rmtp);
+				const struct __kernel_timespec __user *rqtp,
+				struct __kernel_timespec __user *rmtp);
 
 asmlinkage long sys_nice(int increment);
 asmlinkage long sys_sched_setscheduler(pid_t pid, int policy,
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index e7db66af5a23..ce6cbb687c47 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1541,8 +1541,8 @@ long hrtimer_nanosleep(const struct timespec64 *rqtp,
 	return ret;
 }
 
-SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp,
-		struct timespec __user *, rmtp)
+SYSCALL_DEFINE2(nanosleep, struct __kernel_timespec __user *, rqtp,
+		struct __kernel_timespec __user *, rmtp)
 {
 	struct timespec64 tu;
 
diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index 684d470dba2c..cdc5fed5f89b 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -114,8 +114,8 @@ SYSCALL_DEFINE2(clock_getres, const clockid_t, which_clock, struct __kernel_time
 }
 
 SYSCALL_DEFINE4(clock_nanosleep, const clockid_t, which_clock, int, flags,
-		const struct timespec __user *, rqtp,
-		struct timespec __user *, rmtp)
+		const struct __kernel_timespec __user *, rqtp,
+		struct __kernel_timespec __user *, rmtp)
 {
 	struct timespec64 t;
 
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index d482359bce1b..b8e1bf1aa00f 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -1197,8 +1197,8 @@ static int common_nsleep(const clockid_t which_clock, int flags,
 }
 
 SYSCALL_DEFINE4(clock_nanosleep, const clockid_t, which_clock, int, flags,
-		const struct timespec __user *, rqtp,
-		struct timespec __user *, rmtp)
+		const struct __kernel_timespec __user *, rqtp,
+		struct __kernel_timespec __user *, rmtp)
 {
 	const struct k_clock *kc = clockid_to_kclock(which_clock);
 	struct timespec64 t;
-- 
2.11.0

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Fri, Nov 10, 2017 at 11:42 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
>
> Big picture is as per the lwn article:
> https://lwn.net/Articles/643234/
>
> 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 unconditionally.
> 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.
>
> Arnd Bergmann (1):
>   y2038: introduce CONFIG_64BIT_TIME

The series looks good to me overall, and I've added it to my build-testing tree
to see if it shows any regressions in random configurations.

I had on concern about x32, maybe we should check
for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
bits.

Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
it help to just leave out that part for now and unconditionally
define '__kernel_timespec' as 'timespec' until we are ready to
convert the architectures?

       Arnd

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Deepa Dinamani]

> I had on concern about x32, maybe we should check
> for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
> bits.

Thanks, I think you are right. I had the check conditional on
CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)

> Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
> it help to just leave out that part for now and unconditionally
> define '__kernel_timespec' as 'timespec' until we are ready to
> convert the architectures?

Another approach would be to use separate configs:

1. To indicate 64 bit time_t syscall support. This will be dependent
on architectures as CONFIG_64BIT_TIME.
We can delete this once all architectures have provided support for this.

2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
which will compile out all syscalls/ features that use 32 bit time_t.
This can help build a y2038 safe kernel later.

Would this work for everyone?

-Deepa

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Thomas Gleixner]

On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> > I had on concern about x32, maybe we should check
> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
> > bits.
> 
> Thanks, I think you are right. I had the check conditional on
> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)
> 
> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
> > it help to just leave out that part for now and unconditionally
> > define '__kernel_timespec' as 'timespec' until we are ready to
> > convert the architectures?
> 
> Another approach would be to use separate configs:
> 
> 1. To indicate 64 bit time_t syscall support. This will be dependent
> on architectures as CONFIG_64BIT_TIME.
> We can delete this once all architectures have provided support for this.
> 
> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
> which will compile out all syscalls/ features that use 32 bit time_t.
> This can help build a y2038 safe kernel later.
> 
> Would this work for everyone?

Having extra config switches which are selectable by architectures and
removed when everything is converted is definitely the right way to go.

That allows you to gradually convert stuff w/o inflicting wreckage all over
the place.

Thanks,

	tglx

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org> wrote:
> On Wed, 15 Nov 2017, Deepa Dinamani wrote:
>> > I had on concern about x32, maybe we should check
>> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
>> > bits.
>>
>> Thanks, I think you are right. I had the check conditional on
>> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)
>>
>> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
>> > it help to just leave out that part for now and unconditionally
>> > define '__kernel_timespec' as 'timespec' until we are ready to
>> > convert the architectures?
>>
>> Another approach would be to use separate configs:
>>
>> 1. To indicate 64 bit time_t syscall support. This will be dependent
>> on architectures as CONFIG_64BIT_TIME.
>> We can delete this once all architectures have provided support for this.
>>
>> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
>> which will compile out all syscalls/ features that use 32 bit time_t.
>> This can help build a y2038 safe kernel later.
>>
>> Would this work for everyone?
>
> Having extra config switches which are selectable by architectures and
> removed when everything is converted is definitely the right way to go.
>
> That allows you to gradually convert stuff w/o inflicting wreckage all over
> the place.

The CONFIG_64BIT_TIME would do that nicely for the new stuff like
the conditional definition of __kernel_timespec, this one would get
removed after we convert all architectures.

A second issue is how to control the compilation of the compat syscalls.
CONFIG_COMPAT_32BIT_TIME handles that and could be defined
in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
this is then just a more readable way of expressing exactly when the
functions should be built.

For completeness, there may be a third category, depending on how
we handle things like sys_nanosleep(): Here, we want the native
sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
architectures any more, as new glibc should call clock_nanosleep()
with a new syscall number instead. Should we then enclose
sys_nanosleep in "#if !defined(CONFIG_64BIT_TIME) ||
defined(CONFIG_64BIT)", or should we try to come up with another
Kconfig symbol name that expresses this better?

       Arnd

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Thomas Gleixner]

On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> >> Would this work for everyone?
> >
> > Having extra config switches which are selectable by architectures and
> > removed when everything is converted is definitely the right way to go.
> >
> > That allows you to gradually convert stuff w/o inflicting wreckage all over
> > the place.
> 
> The CONFIG_64BIT_TIME would do that nicely for the new stuff like
> the conditional definition of __kernel_timespec, this one would get
> removed after we convert all architectures.
> 
> A second issue is how to control the compilation of the compat syscalls.
> CONFIG_COMPAT_32BIT_TIME handles that and could be defined
> in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
> this is then just a more readable way of expressing exactly when the
> functions should be built.
> 
> For completeness, there may be a third category, depending on how
> we handle things like sys_nanosleep(): Here, we want the native
> sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
> to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
> but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
> architectures any more, as new glibc should call clock_nanosleep()
> with a new syscall number instead. Should we then enclose

Isn't that going to break existing userspace?

Thanks

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

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
>> >> Would this work for everyone?
>> >
>> > Having extra config switches which are selectable by architectures and
>> > removed when everything is converted is definitely the right way to go.
>> >
>> > That allows you to gradually convert stuff w/o inflicting wreckage all over
>> > the place.
>>
>> The CONFIG_64BIT_TIME would do that nicely for the new stuff like
>> the conditional definition of __kernel_timespec, this one would get
>> removed after we convert all architectures.
>>
>> A second issue is how to control the compilation of the compat syscalls.
>> CONFIG_COMPAT_32BIT_TIME handles that and could be defined
>> in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
>> this is then just a more readable way of expressing exactly when the
>> functions should be built.
>>
>> For completeness, there may be a third category, depending on how
>> we handle things like sys_nanosleep(): Here, we want the native
>> sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
>> to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
>> but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
>> architectures any more, as new glibc should call clock_nanosleep()
>> with a new syscall number instead. Should we then enclose
>
> Isn't that going to break existing userspace?

No, syscall that existing 32-bit user space enters would be handled by
compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
point. The idea here is to make the code path more uniform between
32-bit and 64-bit kernels.

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

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Thomas Gleixner]

On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> >> >> Would this work for everyone?
> >> >
> >> > Having extra config switches which are selectable by architectures and
> >> > removed when everything is converted is definitely the right way to go.
> >> >
> >> > That allows you to gradually convert stuff w/o inflicting wreckage all over
> >> > the place.
> >>
> >> The CONFIG_64BIT_TIME would do that nicely for the new stuff like
> >> the conditional definition of __kernel_timespec, this one would get
> >> removed after we convert all architectures.
> >>
> >> A second issue is how to control the compilation of the compat syscalls.
> >> CONFIG_COMPAT_32BIT_TIME handles that and could be defined
> >> in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
> >> this is then just a more readable way of expressing exactly when the
> >> functions should be built.
> >>
> >> For completeness, there may be a third category, depending on how
> >> we handle things like sys_nanosleep(): Here, we want the native
> >> sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
> >> to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
> >> but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
> >> architectures any more, as new glibc should call clock_nanosleep()
> >> with a new syscall number instead. Should we then enclose
> >
> > Isn't that going to break existing userspace?
> 
> No, syscall that existing 32-bit user space enters would be handled by
> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
> point. The idea here is to make the code path more uniform between
> 32-bit and 64-bit kernels.

So on a 32bit system compat_sys_nanosleep() would be the legacy
sys_nanosleep() with the existing syscall number, but you don't want to
introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.

So back to your original question whether to use #if (MAGIC logic) or a
separate config symbol. Please use the latter, these magic logic constructs
are harder to read and prone to get wrong at some point. Having the
decision logic in one place is always the right thing to do.

Thanks,

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

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>>
>> No, syscall that existing 32-bit user space enters would be handled by
>> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
>> point. The idea here is to make the code path more uniform between
>> 32-bit and 64-bit kernels.
>
> So on a 32bit system compat_sys_nanosleep() would be the legacy
> sys_nanosleep() with the existing syscall number, but you don't want to
> introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.
>
> So back to your original question whether to use #if (MAGIC logic) or a
> separate config symbol. Please use the latter, these magic logic constructs
> are harder to read and prone to get wrong at some point. Having the
> decision logic in one place is always the right thing to do.

How about this:

config LEGACY_TIME_SYSCALLS
      def_bool 64BIT || !64BIT_TIME
      help
        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 disable this.

       Arnd

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Thomas Gleixner]

On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >>
> >> No, syscall that existing 32-bit user space enters would be handled by
> >> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
> >> point. The idea here is to make the code path more uniform between
> >> 32-bit and 64-bit kernels.
> >
> > So on a 32bit system compat_sys_nanosleep() would be the legacy
> > sys_nanosleep() with the existing syscall number, but you don't want to
> > introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.
> >
> > So back to your original question whether to use #if (MAGIC logic) or a
> > separate config symbol. Please use the latter, these magic logic constructs
> > are harder to read and prone to get wrong at some point. Having the
> > decision logic in one place is always the right thing to do.
> 
> How about this:
> 
> config LEGACY_TIME_SYSCALLS
>       def_bool 64BIT || !64BIT_TIME
>       help
>         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.

s/handles/handling/ ????

>         New architectures should not explicitly disable this.

New architectures should never enable this, right?

Thanks,

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

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

[Arnd Bergmann]

On Fri, Nov 17, 2017 at 11:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
>> >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> >>
>> >> No, syscall that existing 32-bit user space enters would be handled by
>> >> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
>> >> point. The idea here is to make the code path more uniform between
>> >> 32-bit and 64-bit kernels.
>> >
>> > So on a 32bit system compat_sys_nanosleep() would be the legacy
>> > sys_nanosleep() with the existing syscall number, but you don't want to
>> > introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.
>> >
>> > So back to your original question whether to use #if (MAGIC logic) or a
>> > separate config symbol. Please use the latter, these magic logic constructs
>> > are harder to read and prone to get wrong at some point. Having the
>> > decision logic in one place is always the right thing to do.
>>
>> How about this:
>>
>> config LEGACY_TIME_SYSCALLS
>>       def_bool 64BIT || !64BIT_TIME
>>       help
>>         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.
>
> s/handles/handling/ ????

I meant "handlers".

>>         New architectures should not explicitly disable this.
>
> New architectures should never enable this, right?

Right, I got an extra "not". I guess if Deepa incorporates the new option,
she can also improve my English ;-)

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