[PATCH 00/23] y2038 cleanups

[PATCH 00/23] y2038 cleanups

[Arnd Bergmann]

This is a series of cleanups for the y2038 work, mostly intended
for namespace cleaning: the kernel defines the traditional
time_t, timeval and timespec types that often lead to y2038-unsafe
code. Even though the unsafe usage is mostly gone from the kernel,
having the types and associated functions around means that we
can still grow new users, and that we may be missing conversions
to safe types that actually matter.

As there is no rush on any of these patches, I would either
queue them up in linux-next through my y2038 branch, or
Thomas could add them to the tip tree if he wants.

As mentioned in another series, this is part of a larger
effort to fix all the remaining bits and pieces that are
not completed yet from the y2038 conversion, and the full
set can be found at:

https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame

Maintainers, please review and provide Acks.

Let me know if you have any opinion on whether we should do
the include last two patches of this series or not.

     Arnd

Arnd Bergmann (23):
  y2038: remove CONFIG_64BIT_TIME
  y2038: add __kernel_old_timespec and __kernel_old_time_t
  y2038: vdso: change timeval to __kernel_old_timeval
  y2038: vdso: change timespec to __kernel_old_timespec
  y2038: vdso: change time_t to __kernel_old_time_t
  y2038: vdso: nds32: open-code timespec_add_ns()
  y2038: vdso: powerpc: avoid timespec references
  y2038: ipc: remove __kernel_time_t reference from headers
  y2038: stat: avoid 'time_t' in 'struct stat'
  y2038: uapi: change __kernel_time_t to __kernel_old_time_t
  y2038: rusage: use __kernel_old_timeval
  y2038: syscalls: change remaining timeval to __kernel_old_timeval
  y2038: socket: remove timespec reference in timestamping
  y2038: make ns_to_compat_timeval use __kernel_old_timeval
  y2038: elfcore: Use __kernel_old_timeval for process times
  y2038: timerfd: Use timespec64 internally
  y2038: time: avoid timespec usage in settimeofday()
  y2038: itimer: compat handling to itimer.c
  y2038: use compat_{get,set}_itimer on alpha
  y2038: move itimer reset into itimer.c
  y2038: itimer: change implementation to timespec64
  [RFC] y2038: itimer: use ktime_t internally
  y2038: allow disabling time32 system calls

 arch/Kconfig                              |  11 +-
 arch/alpha/kernel/osf_sys.c               |  67 +-----
 arch/alpha/kernel/syscalls/syscall.tbl    |   4 +-
 arch/ia64/kernel/asm-offsets.c            |   2 +-
 arch/mips/include/uapi/asm/msgbuf.h       |   6 +-
 arch/mips/include/uapi/asm/sembuf.h       |   4 +-
 arch/mips/include/uapi/asm/shmbuf.h       |   6 +-
 arch/mips/include/uapi/asm/stat.h         |  16 +-
 arch/mips/kernel/binfmt_elfn32.c          |   4 +-
 arch/mips/kernel/binfmt_elfo32.c          |   4 +-
 arch/nds32/kernel/vdso/gettimeofday.c     |  61 +++--
 arch/parisc/include/uapi/asm/msgbuf.h     |   6 +-
 arch/parisc/include/uapi/asm/sembuf.h     |   4 +-
 arch/parisc/include/uapi/asm/shmbuf.h     |   6 +-
 arch/powerpc/include/asm/asm-prototypes.h |   3 +-
 arch/powerpc/include/asm/vdso_datapage.h  |   6 +-
 arch/powerpc/include/uapi/asm/msgbuf.h    |   6 +-
 arch/powerpc/include/uapi/asm/sembuf.h    |   4 +-
 arch/powerpc/include/uapi/asm/shmbuf.h    |   6 +-
 arch/powerpc/include/uapi/asm/stat.h      |   2 +-
 arch/powerpc/kernel/asm-offsets.c         |  18 +-
 arch/powerpc/kernel/syscalls.c            |   4 +-
 arch/powerpc/kernel/time.c                |   5 +-
 arch/powerpc/kernel/vdso32/gettimeofday.S |   6 +-
 arch/powerpc/kernel/vdso64/gettimeofday.S |   8 +-
 arch/sparc/include/uapi/asm/msgbuf.h      |   6 +-
 arch/sparc/include/uapi/asm/sembuf.h      |   4 +-
 arch/sparc/include/uapi/asm/shmbuf.h      |   6 +-
 arch/sparc/include/uapi/asm/stat.h        |  24 +-
 arch/sparc/vdso/vclock_gettime.c          |  36 +--
 arch/x86/entry/vdso/vclock_gettime.c      |   6 +-
 arch/x86/entry/vsyscall/vsyscall_64.c     |   4 +-
 arch/x86/include/uapi/asm/msgbuf.h        |   6 +-
 arch/x86/include/uapi/asm/sembuf.h        |   4 +-
 arch/x86/include/uapi/asm/shmbuf.h        |   6 +-
 arch/x86/um/vdso/um_vdso.c                |  12 +-
 fs/aio.c                                  |   2 +-
 fs/binfmt_elf.c                           |  12 +-
 fs/binfmt_elf_fdpic.c                     |  12 +-
 fs/compat_binfmt_elf.c                    |   4 +-
 fs/select.c                               |  10 +-
 fs/timerfd.c                              |  14 +-
 fs/utimes.c                               |   8 +-
 include/linux/compat.h                    |  19 +-
 include/linux/syscalls.h                  |  16 +-
 include/linux/time.h                      |   9 +-
 include/linux/time32.h                    |   2 +-
 include/linux/types.h                     |   2 +-
 include/trace/events/timer.h              |  29 +--
 include/uapi/asm-generic/msgbuf.h         |  12 +-
 include/uapi/asm-generic/posix_types.h    |   1 +
 include/uapi/asm-generic/sembuf.h         |   7 +-
 include/uapi/asm-generic/shmbuf.h         |  12 +-
 include/uapi/linux/cyclades.h             |   6 +-
 include/uapi/linux/elfcore.h              |   8 +-
 include/uapi/linux/errqueue.h             |   7 +
 include/uapi/linux/msg.h                  |   6 +-
 include/uapi/linux/ppp_defs.h             |   4 +-
 include/uapi/linux/resource.h             |   4 +-
 include/uapi/linux/sem.h                  |   4 +-
 include/uapi/linux/shm.h                  |   6 +-
 include/uapi/linux/time.h                 |   6 +-
 include/uapi/linux/time_types.h           |   5 +
 include/uapi/linux/utime.h                |   4 +-
 ipc/syscall.c                             |   2 +-
 kernel/compat.c                           |  24 --
 kernel/power/power.h                      |   2 +-
 kernel/sys.c                              |   4 +-
 kernel/sys_ni.c                           |  23 ++
 kernel/time/hrtimer.c                     |   2 +-
 kernel/time/itimer.c                      | 280 ++++++++++++++--------
 kernel/time/time.c                        |  32 ++-
 lib/vdso/gettimeofday.c                   |   4 +-
 net/core/scm.c                            |   6 +-
 net/socket.c                              |   2 +-
 security/selinux/hooks.c                  |  10 +-
 76 files changed, 501 insertions(+), 504 deletions(-)

-- 
2.20.0

Cc: rth@twiddle.net
Cc: tony.luck@intel.com
Cc: paul.burton@mips.com
Cc: green.hu@gmail.com
Cc: deller@gmx.de
Cc: mpe@ellerman.id.au
Cc: davem@davemloft.net
Cc: tglx@linutronix.de
Cc: x86@kernel.org
Cc: jdike@addtoit.com
Cc: richard@nod.at
Cc: viro@zeniv.linux.org.uk
Cc: bcrl@kvack.org
Cc: john.stultz@linaro.org
Cc: sboyd@kernel.org
Cc: rostedt@goodmis.org
Cc: arnd@arndb.de
Cc: vincenzo.frascino@arm.com
Cc: paul@paul-moore.com
Cc: sds@tycho.nsa.gov
Cc: eparis@parisplace.org
Cc: peterz@infradead.org
Cc: will@kernel.org
Cc: deepa.kernel@gmail.com
Cc: christian@brauner.io
Cc: heiko.carstens@de.ibm.com
Cc: christophe.leroy@c-s.fr
Cc: ebiederm@xmission.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-alpha@vger.kernel.org>
Cc: linux-ia64@vger.kernel.org>
Cc: linux-mips@vger.kernel.org>
Cc: linux-parisc@vger.kernel.org>
Cc: linuxppc-dev@lists.ozlabs.org>
Cc: sparclinux@vger.kernel.org>
Cc: linux-um@lists.infradead.org>
Cc: linux-fsdevel@vger.kernel.org>
Cc: linux-aio@kvack.org>
Cc: linux-api@vger.kernel.org>
Cc: linux-arch@vger.kernel.org>
Cc: netdev@vger.kernel.org>
Cc: selinux@vger.kernel.org>


--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

[PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Arnd Bergmann]

There are two 'struct timeval' fields in 'struct rusage'.

Unfortunately the definition of timeval is now ambiguous when used in
user space with a libc that has a 64-bit time_t, and this also changes
the 'rusage' definition in user space in a way that is incompatible with
the system call interface.

While there is no good solution to avoid all ambiguity here, change
the definition in the kernel headers to be compatible with the kernel
ABI, using __kernel_old_timeval as an unambiguous base type.

In previous discussions, there was also a plan to add a replacement
for rusage based on 64-bit timestamps and nanosecond resolution,
i.e. 'struct __kernel_timespec'. I have patches for that as well,
if anyone thinks we should do that.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
here, to make them completely unambiguous?
---
 arch/alpha/kernel/osf_sys.c   | 2 +-
 include/uapi/linux/resource.h | 4 ++--
 kernel/sys.c                  | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index bf497b8b0ec6..bbe7a0da6264 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -963,7 +963,7 @@ put_tv32(struct timeval32 __user *o, struct timespec64 *i)
 }
 
 static inline long
-put_tv_to_tv32(struct timeval32 __user *o, struct timeval *i)
+put_tv_to_tv32(struct timeval32 __user *o, struct __kernel_old_timeval *i)
 {
 	return copy_to_user(o, &(struct timeval32){
 				.tv_sec = i->tv_sec,
diff --git a/include/uapi/linux/resource.h b/include/uapi/linux/resource.h
index cc00fd079631..74ef57b38f9f 100644
--- a/include/uapi/linux/resource.h
+++ b/include/uapi/linux/resource.h
@@ -22,8 +22,8 @@
 #define	RUSAGE_THREAD	1		/* only the calling thread */
 
 struct	rusage {
-	struct timeval ru_utime;	/* user time used */
-	struct timeval ru_stime;	/* system time used */
+	struct __kernel_old_timeval ru_utime;	/* user time used */
+	struct __kernel_old_timeval ru_stime;	/* system time used */
 	__kernel_long_t	ru_maxrss;	/* maximum resident set size */
 	__kernel_long_t	ru_ixrss;	/* integral shared memory size */
 	__kernel_long_t	ru_idrss;	/* integral unshared data size */
diff --git a/kernel/sys.c b/kernel/sys.c
index a611d1d58c7d..d3aef31e24dc 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1763,8 +1763,8 @@ void getrusage(struct task_struct *p, int who, struct rusage *r)
 	unlock_task_sighand(p, &flags);
 
 out:
-	r->ru_utime = ns_to_timeval(utime);
-	r->ru_stime = ns_to_timeval(stime);
+	r->ru_utime = ns_to_kernel_old_timeval(utime);
+	r->ru_stime = ns_to_kernel_old_timeval(stime);
 
 	if (who != RUSAGE_CHILDREN) {
 		struct mm_struct *mm = get_task_mm(p);
-- 
2.20.0

[PATCH 19/23] y2038: use compat_{get,set}_itimer on alpha

[Arnd Bergmann]

The itimer handling for the old alpha osf_setitimer/osf_getitimer
system calls is identical to the compat version of getitimer/setitimer,
so just use those directly.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/alpha/kernel/osf_sys.c            | 65 --------------------------
 arch/alpha/kernel/syscalls/syscall.tbl |  4 +-
 kernel/time/itimer.c                   |  4 +-
 3 files changed, 4 insertions(+), 69 deletions(-)

diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index bbe7a0da6264..94e4cde8071a 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -971,30 +971,6 @@ put_tv_to_tv32(struct timeval32 __user *o, struct __kernel_old_timeval *i)
 			    sizeof(struct timeval32));
 }
 
-static inline long
-get_it32(struct itimerval *o, struct itimerval32 __user *i)
-{
-	struct itimerval32 itv;
-	if (copy_from_user(&itv, i, sizeof(struct itimerval32)))
-		return -EFAULT;
-	o->it_interval.tv_sec = itv.it_interval.tv_sec;
-	o->it_interval.tv_usec = itv.it_interval.tv_usec;
-	o->it_value.tv_sec = itv.it_value.tv_sec;
-	o->it_value.tv_usec = itv.it_value.tv_usec;
-	return 0;
-}
-
-static inline long
-put_it32(struct itimerval32 __user *o, struct itimerval *i)
-{
-	return copy_to_user(o, &(struct itimerval32){
-				.it_interval.tv_sec = o->it_interval.tv_sec,
-				.it_interval.tv_usec = o->it_interval.tv_usec,
-				.it_value.tv_sec = o->it_value.tv_sec,
-				.it_value.tv_usec = o->it_value.tv_usec},
-			    sizeof(struct itimerval32));
-}
-
 static inline void
 jiffies_to_timeval32(unsigned long jiffies, struct timeval32 *value)
 {
@@ -1039,47 +1015,6 @@ SYSCALL_DEFINE2(osf_settimeofday, struct timeval32 __user *, tv,
 
 asmlinkage long sys_ni_posix_timers(void);
 
-SYSCALL_DEFINE2(osf_getitimer, int, which, struct itimerval32 __user *, it)
-{
-	struct itimerval kit;
-	int error;
-
-	if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
-		return sys_ni_posix_timers();
-
-	error = do_getitimer(which, &kit);
-	if (!error && put_it32(it, &kit))
-		error = -EFAULT;
-
-	return error;
-}
-
-SYSCALL_DEFINE3(osf_setitimer, int, which, struct itimerval32 __user *, in,
-		struct itimerval32 __user *, out)
-{
-	struct itimerval kin, kout;
-	int error;
-
-	if (!IS_ENABLED(CONFIG_POSIX_TIMERS))
-		return sys_ni_posix_timers();
-
-	if (in) {
-		if (get_it32(&kin, in))
-			return -EFAULT;
-	} else
-		memset(&kin, 0, sizeof(kin));
-
-	error = do_setitimer(which, &kin, out ? &kout : NULL);
-	if (error || !out)
-		return error;
-
-	if (put_it32(out, &kout))
-		return -EFAULT;
-
-	return 0;
-
-}
-
 SYSCALL_DEFINE2(osf_utimes, const char __user *, filename,
 		struct timeval32 __user *, tvs)
 {
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl
index 728fe028c02c..8e13b0b2928d 100644
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@ -89,10 +89,10 @@
 80	common	setgroups			sys_setgroups
 81	common	osf_old_getpgrp			sys_ni_syscall
 82	common	setpgrp				sys_setpgid
-83	common	osf_setitimer			sys_osf_setitimer
+83	common	osf_setitimer			compat_sys_setitimer
 84	common	osf_old_wait			sys_ni_syscall
 85	common	osf_table			sys_ni_syscall
-86	common	osf_getitimer			sys_osf_getitimer
+86	common	osf_getitimer			compat_sys_getitimer
 87	common	gethostname			sys_gethostname
 88	common	sethostname			sys_sethostname
 89	common	getdtablesize			sys_getdtablesize
diff --git a/kernel/time/itimer.c b/kernel/time/itimer.c
index c52ebb40b60b..4664c6addf69 100644
--- a/kernel/time/itimer.c
+++ b/kernel/time/itimer.c
@@ -111,7 +111,7 @@ SYSCALL_DEFINE2(getitimer, int, which, struct itimerval __user *, value)
 	return error;
 }
 
-#ifdef CONFIG_COMPAT
+#if defined(CONFIG_COMPAT) || defined(CONFIG_ALPHA)
 struct old_itimerval32 {
 	struct old_timeval32	it_interval;
 	struct old_timeval32	it_value;
@@ -324,7 +324,7 @@ SYSCALL_DEFINE3(setitimer, int, which, struct itimerval __user *, value,
 	return 0;
 }
 
-#ifdef CONFIG_COMPAT
+#if defined(CONFIG_COMPAT) || defined(CONFIG_ALPHA)
 static int get_old_itimerval32(struct itimerval *o, const struct old_itimerval32 __user *i)
 {
 	struct old_itimerval32 v32;
-- 
2.20.0

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Cyrill Gorcunov]

On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> There are two 'struct timeval' fields in 'struct rusage'.
> 
> Unfortunately the definition of timeval is now ambiguous when used in
> user space with a libc that has a 64-bit time_t, and this also changes
> the 'rusage' definition in user space in a way that is incompatible with
> the system call interface.
> 
> While there is no good solution to avoid all ambiguity here, change
> the definition in the kernel headers to be compatible with the kernel
> ABI, using __kernel_old_timeval as an unambiguous base type.
> 
> In previous discussions, there was also a plan to add a replacement
> for rusage based on 64-bit timestamps and nanosecond resolution,
> i.e. 'struct __kernel_timespec'. I have patches for that as well,
> if anyone thinks we should do that.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
> here, to make them completely unambiguous?

The patch looks ok to me. I must confess I looked into rusage long ago
so __kernel_timespec type used in uapi made me nervious at first,
but then i found that we've this type defined in time_types.h uapi
so userspace should be safe. I also like the idea of __kernel_rusage
but definitely on top of the series.

Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Arnd Bergmann]

On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:

> > ---
> > Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
> > here, to make them completely unambiguous?
>
> The patch looks ok to me. I must confess I looked into rusage long ago
> so __kernel_timespec type used in uapi made me nervious at first,
> but then i found that we've this type defined in time_types.h uapi
> so userspace should be safe. I also like the idea of __kernel_rusage
> but definitely on top of the series.

There are clearly too many time types at the moment, but I'm in the
process of throwing out the ones we no longer need now.

I do have a number patches implementing other variants for the syscall,
and I suppose that if we end up adding __kernel_rusage, that would
have to go with a set of syscalls using 64-bit seconds/nanoseconds
rather than the old 32/64 microseconds. I don't know what other
changes remain that anyone would want from sys_waitid() now that
it does support pidfd.

If there is still a need for a new waitid() replacement, that should take
that new __kernel_rusage I think, but until then I hope we are fine
with today's getrusage+waitid based on the current struct rusage.

BSD has wait6() to return separate rusage structures for 'self' and
'children', but I could not find any application (using the freebsd
sources and debian code search) that actually uses that information,
so there might not be any demand for that.

> Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>

Thanks,

      Arnd

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Cyrill Gorcunov]

On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
...
> 
> There are clearly too many time types at the moment, but I'm in the
> process of throwing out the ones we no longer need now.

Cool!

> I do have a number patches implementing other variants for the syscall,
> and I suppose that if we end up adding __kernel_rusage, that would
> have to go with a set of syscalls using 64-bit seconds/nanoseconds
> rather than the old 32/64 microseconds. I don't know what other
> changes remain that anyone would want from sys_waitid() now that
> it does support pidfd.
> 
> If there is still a need for a new waitid() replacement, that should take
> that new __kernel_rusage I think, but until then I hope we are fine
> with today's getrusage+waitid based on the current struct rusage.

Definitely.

> 
> BSD has wait6() to return separate rusage structures for 'self' and
> 'children', but I could not find any application (using the freebsd
> sources and debian code search) that actually uses that information,
> so there might not be any demand for that.

Thanks for detailed info Arnd!

Re: [PATCH 00/23] y2038 cleanups

[Arnd Bergmann]

On Fri, Nov 8, 2019 at 10:04 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> This is a series of cleanups for the y2038 work, mostly intended
> for namespace cleaning: the kernel defines the traditional
> time_t, timeval and timespec types that often lead to y2038-unsafe
> code. Even though the unsafe usage is mostly gone from the kernel,
> having the types and associated functions around means that we
> can still grow new users, and that we may be missing conversions
> to safe types that actually matter.
>
> As there is no rush on any of these patches, I would either
> queue them up in linux-next through my y2038 branch, or
> Thomas could add them to the tip tree if he wants.
>
> As mentioned in another series, this is part of a larger
> effort to fix all the remaining bits and pieces that are
> not completed yet from the y2038 conversion, and the full
> set can be found at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame
>
> Maintainers, please review and provide Acks.
>
> Let me know if you have any opinion on whether we should do
> the include last two patches of this series or not.
>
>      Arnd
>
> Arnd Bergmann (23):
>   y2038: remove CONFIG_64BIT_TIME
>   y2038: add __kernel_old_timespec and __kernel_old_time_t
>   y2038: vdso: change timeval to __kernel_old_timeval
>   y2038: vdso: change timespec to __kernel_old_timespec
>   y2038: vdso: change time_t to __kernel_old_time_t
>   y2038: vdso: nds32: open-code timespec_add_ns()
>   y2038: vdso: powerpc: avoid timespec references
>   y2038: ipc: remove __kernel_time_t reference from headers
>   y2038: stat: avoid 'time_t' in 'struct stat'
>   y2038: uapi: change __kernel_time_t to __kernel_old_time_t
>   y2038: rusage: use __kernel_old_timeval
>   y2038: syscalls: change remaining timeval to __kernel_old_timeval
>   y2038: socket: remove timespec reference in timestamping
>   y2038: make ns_to_compat_timeval use __kernel_old_timeval
>   y2038: elfcore: Use __kernel_old_timeval for process times
>   y2038: timerfd: Use timespec64 internally
>   y2038: time: avoid timespec usage in settimeofday()
>   y2038: itimer: compat handling to itimer.c
>   y2038: use compat_{get,set}_itimer on alpha
>   y2038: move itimer reset into itimer.c
>   y2038: itimer: change implementation to timespec64
>   [RFC] y2038: itimer: use ktime_t internally
>   y2038: allow disabling time32 system calls

I've dropped the "[RFC] y2038: itimer: use ktime_t internally" patch
for the moment,
and added two other patches from other series:

y2038: remove CONFIG_64BIT_TIME
y2038: socket: use __kernel_old_timespec instead of timespec

Tentatively pushed out the patches with the Acks I have received so
far to my y2038 branch on git.kernel.org so it gets included in linux-next.

If I hear no complaints, I'll send a pull request for the merge window,
along with the compat-ioctl series I have already queued up in the same
branch.

    Arnd

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Christian Brauner]

On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
> On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> >
> > On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> 
> > > ---
> > > Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
> > > here, to make them completely unambiguous?
> >
> > The patch looks ok to me. I must confess I looked into rusage long ago
> > so __kernel_timespec type used in uapi made me nervious at first,
> > but then i found that we've this type defined in time_types.h uapi
> > so userspace should be safe. I also like the idea of __kernel_rusage
> > but definitely on top of the series.
> 
> There are clearly too many time types at the moment, but I'm in the
> process of throwing out the ones we no longer need now.
> 
> I do have a number patches implementing other variants for the syscall,
> and I suppose that if we end up adding __kernel_rusage, that would
> have to go with a set of syscalls using 64-bit seconds/nanoseconds
> rather than the old 32/64 microseconds. I don't know what other
> changes remain that anyone would want from sys_waitid() now that
> it does support pidfd.
> 
> If there is still a need for a new waitid() replacement, that should take
> that new __kernel_rusage I think, but until then I hope we are fine
> with today's getrusage+waitid based on the current struct rusage.

Note, that glibc does _not_ expose the rusage argument, i.e. most of
userspace is unaware that waitid() does allow you to get rusage
information. So users first need to know that waitid() has an rusage
argument and then need to call the waitid() syscall directly.

> 
> BSD has wait6() to return separate rusage structures for 'self' and
> 'children', but I could not find any application (using the freebsd
> sources and debian code search) that actually uses that information,
> so there might not be any demand for that.

Speaking specifically for Linux now, I think that rusage does not
actually expose the information most relevant users are interested in.
On Linux nowadays it is _way_ more interesting to retrieve stats
relative to the cgroup the task lived in etc.
Doing a git grep -i rusage in the systemd source code shows that rusage
is used _nowhere_. And I consider an init system to be the most likely
candidate to be interested in rusage.

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

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Arnd Bergmann]

On Thu, Nov 14, 2019 at 1:38 AM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
> On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
> > On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> > >
> > > On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> >
> > > > ---
> > > > Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
> > > > here, to make them completely unambiguous?
> > >
> > > The patch looks ok to me. I must confess I looked into rusage long ago
> > > so __kernel_timespec type used in uapi made me nervious at first,
> > > but then i found that we've this type defined in time_types.h uapi
> > > so userspace should be safe. I also like the idea of __kernel_rusage
> > > but definitely on top of the series.
> >
> > There are clearly too many time types at the moment, but I'm in the
> > process of throwing out the ones we no longer need now.
> >
> > I do have a number patches implementing other variants for the syscall,
> > and I suppose that if we end up adding __kernel_rusage, that would
> > have to go with a set of syscalls using 64-bit seconds/nanoseconds
> > rather than the old 32/64 microseconds. I don't know what other
> > changes remain that anyone would want from sys_waitid() now that
> > it does support pidfd.
> >
> > If there is still a need for a new waitid() replacement, that should take
> > that new __kernel_rusage I think, but until then I hope we are fine
> > with today's getrusage+waitid based on the current struct rusage.
>
> Note, that glibc does _not_ expose the rusage argument, i.e. most of
> userspace is unaware that waitid() does allow you to get rusage
> information. So users first need to know that waitid() has an rusage
> argument and then need to call the waitid() syscall directly.

On architectures that don't have a wait4 syscall (riscv32 for now),
glibc uses waitid to implement wait4 and wait3.

> > BSD has wait6() to return separate rusage structures for 'self' and
> > 'children', but I could not find any application (using the freebsd
> > sources and debian code search) that actually uses that information,
> > so there might not be any demand for that.
>
> Speaking specifically for Linux now, I think that rusage does not
> actually expose the information most relevant users are interested in.
> On Linux nowadays it is _way_ more interesting to retrieve stats
> relative to the cgroup the task lived in etc.
> Doing a git grep -i rusage in the systemd source code shows that rusage
> is used _nowhere_. And I consider an init system to be the most likely
> candidate to be interested in rusage.

I looked at a couple of implementations of time(1), this is one example
that sometimes uses wait3(), though other implementations just call
getrusage() in the parent process before the fork/exec. None of them
actually seem to report better than millisecond resolution, so there is
not a strict reason to do a timespec replacement for these.

       Arnd

Re: [PATCH 11/23] y2038: rusage: use __kernel_old_timeval

[Christian Brauner]

[+Cc Florian, libc-alpha]

On Thu, Nov 14, 2019 at 11:18:15AM +0100, Arnd Bergmann wrote:
> On Thu, Nov 14, 2019 at 1:38 AM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> > On Wed, Nov 13, 2019 at 11:02:12AM +0100, Arnd Bergmann wrote:
> > > On Tue, Nov 12, 2019 at 10:09 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
> > > >
> > > > On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> > >
> > > > > ---
> > > > > Question: should we also rename 'struct rusage' into 'struct __kernel_rusage'
> > > > > here, to make them completely unambiguous?
> > > >
> > > > The patch looks ok to me. I must confess I looked into rusage long ago
> > > > so __kernel_timespec type used in uapi made me nervious at first,
> > > > but then i found that we've this type defined in time_types.h uapi
> > > > so userspace should be safe. I also like the idea of __kernel_rusage
> > > > but definitely on top of the series.
> > >
> > > There are clearly too many time types at the moment, but I'm in the
> > > process of throwing out the ones we no longer need now.
> > >
> > > I do have a number patches implementing other variants for the syscall,
> > > and I suppose that if we end up adding __kernel_rusage, that would
> > > have to go with a set of syscalls using 64-bit seconds/nanoseconds
> > > rather than the old 32/64 microseconds. I don't know what other
> > > changes remain that anyone would want from sys_waitid() now that
> > > it does support pidfd.
> > >
> > > If there is still a need for a new waitid() replacement, that should take
> > > that new __kernel_rusage I think, but until then I hope we are fine
> > > with today's getrusage+waitid based on the current struct rusage.
> >
> > Note, that glibc does _not_ expose the rusage argument, i.e. most of
> > userspace is unaware that waitid() does allow you to get rusage
> > information. So users first need to know that waitid() has an rusage
> > argument and then need to call the waitid() syscall directly.
> 
> On architectures that don't have a wait4 syscall (riscv32 for now),
> glibc uses waitid to implement wait4 and wait3.

Yes, and there's an ongoing discussion to implement wait4() on all
arches through waitid(), I think. I haven't followed it too closely.

> 
> > > BSD has wait6() to return separate rusage structures for 'self' and
> > > 'children', but I could not find any application (using the freebsd
> > > sources and debian code search) that actually uses that information,
> > > so there might not be any demand for that.
> >
> > Speaking specifically for Linux now, I think that rusage does not
> > actually expose the information most relevant users are interested in.
> > On Linux nowadays it is _way_ more interesting to retrieve stats
> > relative to the cgroup the task lived in etc.
> > Doing a git grep -i rusage in the systemd source code shows that rusage
> > is used _nowhere_. And I consider an init system to be the most likely
> > candidate to be interested in rusage.
> 
> I looked at a couple of implementations of time(1), this is one example
> that sometimes uses wait3(), though other implementations just call
> getrusage() in the parent process before the fork/exec. None of them
> actually seem to report better than millisecond resolution, so there is
> not a strict reason to do a timespec replacement for these.

Right, though I have to say that for the sake of consistency I'd much
rather have a replacement. We're doing all this work right now so we
might as well. But I get the point.

	Christian

Re: [PATCH 19/23] y2038: use compat_{get,set}_itimer on alpha

[Guenter Roeck]

On Fri, Nov 08, 2019 at 10:12:18PM +0100, Arnd Bergmann wrote:
> The itimer handling for the old alpha osf_setitimer/osf_getitimer
> system calls is identical to the compat version of getitimer/setitimer,
> so just use those directly.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

alpha:allnoconfig, alpha:tinyconfig:

alpha-linux-ld: arch/alpha/kernel/systbls.o: in function `sys_call_table':
(.data+0x298): undefined reference to `compat_sys_setitimer'
alpha-linux-ld: (.data+0x2b0): undefined reference to `compat_sys_getitimer'

Guenter