[Y2038] [PATCH v2 14/17] y2038: socket: Add compat_sys_recvmmsg_time64

recvmmsg() takes two arguments to pointers of structures that differ between 32-bit and 64-bit architectures: mmsghdr and timespec. For y2038 compatbility, we are changing the native system call from timespec to __kernel_timespec with a 64-bit time_t (in another patch), and use the existing

[Y2038] [PATCH v2 02/17] y2038: Remove newstat family from default syscall set

We have four generations of stat() syscalls: - the oldstat syscalls that are only used on the older architectures - the newstat family that is used on all 64-bit architectures but lacked support for large files on 32-bit architectures. - the stat64 family that is used mostly on 32-bit

[Y2038] [PATCH v2 13/17] y2038: socket: Convert recvmmsg to __kernel_timespec

This converts the recvmmsg() system call in all its variations to use 'timespec64' internally for its timeout, and have a __kernel_timespec64 argument in the native entry point. This lets us change the type to use 64-bit time_t at a later point while using the 32-bit compat system call emulation

Re: [Y2038] [PATCH 6/6] alpha: uapi header and system call table file generation

Hi Firoz, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.18-rc5 next-20180716] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

[Y2038] [PATCH v2 04/17] asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro

The sys_llseek sytem call is needed on all 32-bit architectures and none of the 64-bit ones, so we can remove the __ARCH_WANT_SYS_LLSEEK guard and simplify the include/asm-generic/unistd.h header further. Since 32-bit tasks can run either natively or in compat mode on 64-bit architectures, we

[Y2038] [PATCH v2 09/17] y2038: futex: Move compat implementation into futex.c

We are going to share the compat_sys_futex() handler between 64-bit architectures and 32-bit architectures that need to deal with both 32-bit and 64-bit time_t, and this is easier if both entry points are in the same file. In fact, most other system call handlers do the same thing these days, so

[Y2038] [PATCH v2 10/17] y2038: futex: Add support for __kernel_timespec

This prepares sys_futex for y2038 safe calling: the native syscall is changed to receive a __kernel_timespec argument, which will be switched to 64-bit time_t in the future. All the internal time handling gets changed to timespec64, and the compat_sys_futex entry point is moved under the

[Y2038] [PATCH v2 08/17] y2038: utimes: Rework #ifdef guards for compat syscalls

After changing over to 64-bit time_t syscalls, many architectures will want compat_sys_utimensat() but not respective handlers for utime(), utimes() and futimesat(). This adds a new __ARCH_WANT_COMPAT_SYS_UTIME to complement __ARCH_WANT_SYS_UTIME. For now, all 64-bit architectures that support

[Y2038] [PATCH v2 12/17] y2038: aio: Prepare sys_io_{p, }getevents for __kernel_timespec

This is a preparation patch for converting sys_io_pgetevents to work with 64-bit time_t on 32-bit architectures. The 'timeout' argument is changed to struct __kernel_timespec, which will be redefined using 64-bit time_t in the future. The compat version of the system call in turn is enabled for

[Y2038] [PATCH v2 01/17] y2038: compat: Move common compat types to asm-generic/compat.h

While converting compat system call handlers to work on 32-bit architectures, I found a number of types used in those handlers that are identical between all architectures. Let's move all the identical ones into asm-generic/compat.h to avoid having to add even more identical definitions of those

[Y2038] [PATCH v2 15/17] y2038: signal: Change rt_sigtimedwait to use __kernel_timespec

This changes sys_rt_sigtimedwait() to use get_timespec64(), changing the timeout type to __kernel_timespec, which will be changed to use a 64-bit time_t in the future. Since the do_sigtimedwait() core function changes, we also have to modify the compat version of this system call in the same way.

[Y2038] [PATCH 2/6] alpha: Add CONFIG_OSF4_COMPAT for compat syscall support

Removed the CONFIG_OSF4_COMPAT check from systbls.S and kept it in osf_sys.c, so it will provide the same system call support. To do so, we can keep a generic formatted system call table file across all architectures. Signed-off-by: Firoz Khan --- arch/alpha/kernel/osf_sys.c | 9 ++---

[Y2038] [PATCH 0/6] System call table generation support

The goal of this patch series is to easily add/modify/delete a system call by changing entry in syscall.tbl file. No need to manually edit many files. The another goal of this patch series is to to unify the system call implementation across all the architectures. ARM, s390 and x86 architecuture

Re: [Y2038] [PATCH] [RFC] y2038: globally rename compat_time to old_time32

On Sat, Jul 14, 2018 at 5:54 PM, Deepa Dinamani wrote: > Right now we only have compat syscalls and native syscalls. > Until we transition all the architectures to use the new syscalls, > wouldn't it be the same sort of confusion as exists today? > These structures today are still used by compat

[Y2038] [PATCH 6/6] alpha: uapi header and system call table file generation

This change will generate unistd.h and syscall_table.h files by the syscall table generation script invoked by arch/alpha/Makefile and the generated files against the removed files will be identical. The generated uapi header file will be included in uapi/asm/unistd.h and generated system call

[Y2038] [PATCH 5/6] alpha: Add system call table generation support

The system call tables are in different format in all architecture and it will be difficult to manually add or modify the system calls in the respective files. To make it easy by keeping a script and which'll generate the header file and syscall table file so this change will unify them across all

[Y2038] [PATCH 4/6] alpha: Replace NR_SYSCALLS macro from asm/unistd.h

Replace NR_SYSCALLS from asm/unistd.h and keep equivalent macro __NR_syscalls in uapi/asm/unistd.h and this will make a unified implementation across all the architecture and we can use a system call generation script to generate __NR_syscalls. While __NR_syscalls isn't strictly part of the uapi,

[Y2038] [PATCH 3/6] alpha: Unify the not-implemented system call entry name

systbl.S contain two types of system call entry name which are alpha_ni_syscall and sys_ni_syscall. So this patch will unify the not-implemented system call entry name as alpha_ni_syscall. Signed-off-by: Firoz Khan --- arch/alpha/kernel/systbls.S | 320

[Y2038] [PATCH 1/6] alpha: Move __IGNORE* entries to non uapi header

It is correct to keep __IGNORE* entry in non uapi header asm/unistd.h while uapi/asm/unistd.h must hold information only useful for user space applications. Signed-off-by: Firoz Khan --- arch/alpha/include/asm/unistd.h | 5 + arch/alpha/include/uapi/asm/unistd.h | 5 - 2 files

Re: [Y2038] [PATCH 0/6] System call table generation support

On Mon, Jul 16, 2018 at 12:23 PM, Firoz Khan wrote: > The goal of this patch series is to easily add/modify/delete a > system call by changing entry in syscall.tbl file. No need > to manually edit many files. > > The another goal of this patch series is to to unify the system > call

[Y2038] [PATCH v2 06/17] y2038: Change sys_utimensat() to use __kernel_timespec

When 32-bit architectures get changed to support 64-bit time_t, utimensat() needs to use the new __kernel_timespec structure as its argument. The older utime(), utimes() and futimesat() system calls don't need a corresponding change as they are no longer used on C libraries that have 64-bit time

[Y2038] [PATCH v2 05/17] asm-generic: Remove empty asm/unistd.h

Nothing is left in asm/unistd.h except for the redirect to uapi/asm/unistd.h, so removing the file simply leads to that one being used directly. The linux/export.h inclusion is a leftover from commit e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations") and should not be used

[Y2038] [PATCH v2 07/17] y2038: Compile utimes()/futimesat() conditionally

There are four generations of utimes() syscalls: utime(), utimes(), futimesat() and utimensat(), each one being a superset of the previous one. For y2038 support, we have to add another one, which is the same as the existing utimensat() but always passes 64-bit times_t based timespec values.

[Y2038] [PATCH v2 03/17] y2038: Remove stat64 family from default syscall set

New architectures should no longer need stat64, which is not y2038 safe and has been replaced by statx(). This removes the 'select __ARCH_WANT_STAT64' statement from asm-generic/unistd.h and instead moves it into the respective asm/unistd.h UAPI header files for each architecture that uses it

[Y2038] [PATCH v2 11/17] y2038: Prepare sched_rr_get_interval for __kernel_timespec

This is a preparation patch for converting sys_sched_rr_get_interval to work with 64-bit time_t on 32-bit architectures. The 'interval' argument is changed to struct __kernel_timespec, which will be redefined using 64-bit time_t in the future. The compat version of the system call in turn is

[Y2038] [PATCH v2 16/17] y2038: Make compat_sys_rt_sigtimedwait usable on 32-bit

Once sys_rt_sigtimedwait() gets changed to a 64-bit time_t, we have to provide compatibility support for existing binaries. Using the compat_sys_rt_sigtimedwait() entry point is convenient because it allows to share the implementation with 64-bit architectures. Unfortunately, the

[Y2038] [PATCH v2 17/17] y2038: signal: Add compat_sys_rt_sigtimedwait_time64

Now that 32-bit architectures have two variants of sys_rt_sigtimedwaid() for 32-bit and 64-bit time_t, we also need to have a second compat system call entry point on the corresponding 64-bit architectures. The traditional system call keeps getting handled by compat_sys_rt_sigtimedwait(), and

[Y2038] [PATCH v2 00/17] y2038: system calls, part 3

This is a mostly unchanged copy of a series I sent back in April for an initial review. All the earlier syscall patches that Deepa or I sent got merged now, and this is the largest chunk of remaining patches. Changes this time are: - This is actually tested with the LTP syscalls test suite,