The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the
system call table generation support implementation
across all the architectures.
The system call tables are in different format in
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a
script and which'll generate uapi header file and
syscall table file.
syscall.tbl contains the list of available system
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture will be possible by adding new entry in the
syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the sim-
ilar support. I leverage their implementation to come
up with a generic solution.
I have done the same support for work for alpha, ia64,
m68k, microblaze, mips, parisc, powerpc, sh and sparc.
Below mentioned git repository contains more details
about the workflow.
https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to solve
Y2038 issue. So this patch series will help to add new
system calls easily by adding new entry in the syscall.tbl.
Firoz Khan (4):
xtensa: move SYS_XTENSA_* macros to non uapi header
xtensa: add __NR_syscalls along with __NR_syscall_count
xtensa: add system call table generation support
xtensa: generate uapi header and syscall table header files
arch/xtensa/Makefile | 3 +
arch/xtensa/include/asm/Kbuild | 1 +
arch/xtensa/include/asm/unistd.h | 20 +
arch/xtensa/include/uapi/asm/Kbuild | 1 +
arch/xtensa/include/uapi/asm/unistd.h | 798 +-----------------------------
arch/xtensa/kernel/syscall.c | 5 +-
arch/xtensa/kernel/syscalls/Makefile | 38 ++
arch/xtensa/kernel/syscalls/syscall.tbl | 374 ++++++++++++++
arch/xtensa/kernel/syscalls/syscallhdr.sh | 36 ++
arch/xtensa/kernel/syscalls/syscalltbl.sh | 32 ++
10 files changed, 510 insertions(+), 798 deletions(-)
create mode 100644 arch/xtensa/kernel/syscalls/Makefile
create mode 100644 arch/xtensa/kernel/syscalls/syscall.tbl
create mode 100644 arch/xtensa/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/xtensa/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the
system call table generation support implementation
across all the architectures.
The system call tables are in different format in
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a
script and which'll generate uapi header file and
syscall table file.
syscall.tbl contains the list of available system
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the sim-
ilar support. I leverage their implementation to
come up with a generic solution.
I have done the same support for work for alpha,
ia64, m68k, microblaze, mips, parisc, powerpc, sh
and xtensa. Below mentioned git repository contains
more details about the workflow.
https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to
solve Y2038 issue. So this patch series will help to
add new system calls easily by adding new entry in the
syscall.tbl.
Changes since v1:
- optimized/updated the syscall table generation
scripts.
- fixed all mixed indentation issues in syscall.tbl.
- added "comments" in syscall.tbl.
Firoz Khan (4):
sparc: move __IGNORE* entries to non uapi header
sparc: add __NR_syscalls along with NR_syscalls
sparc: add system call table generation support
sparc: generate uapi header and system call table files
arch/sparc/Makefile | 3 +
arch/sparc/include/asm/Kbuild | 4 +-
arch/sparc/include/asm/unistd.h | 18 ++
arch/sparc/include/uapi/asm/Kbuild | 2 +
arch/sparc/include/uapi/asm/unistd.h | 425 +------------------------------
arch/sparc/kernel/syscalls/Makefile | 55 ++++
arch/sparc/kernel/syscalls/syscall.tbl | 408 +++++++++++++++++++++++++++++
arch/sparc/kernel/syscalls/syscallhdr.sh | 36 +++
arch/sparc/kernel/syscalls/syscalltbl.sh | 36 +++
arch/sparc/kernel/systbls_32.S | 81 +-----
arch/sparc/kernel/systbls_64.S | 157 +-----------
11 files changed, 571 insertions(+), 654 deletions(-)
create mode 100644 arch/sparc/kernel/syscalls/Makefile
create mode 100644 arch/sparc/kernel/syscalls/syscall.tbl
create mode 100644 arch/sparc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/sparc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the
system call table generation support implementation
across all the architectures.
The system call tables are in different format in
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a
script and which'll generate uapi header file and
syscall table file.
syscall.tbl contains the list of available system
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture will be possible by adding new entry in the
syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the sim-
ilar support. I leverage their implementation to come
up with a generic solution.
I have done the same support for work for ia64, m68k,
microblaze, mips, parisc, powerpc, sh sparc and xtensa.
Below mentioned git repository contains more details
about the workflow.
https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to solve
Y2038 issue. So this patch series will help to add new
system calls easily by adding new entry in the syscall.tbl.
Changes since v1:
- optimized/updated the syscall table generation
scripts.
- fixed all mixed indentation issues in syscall.tbl.
- added "comments" in syscall.tbl.
Firoz Khan (5):
alpha: move __IGNORE* entries to non uapi header
alpha: remove CONFIG_OSF4_COMPAT flag from syscall table
alpha: add __NR_syscalls along with NR_SYSCALLS
alpha: add system call table generation support
alpha: generate uapi header and syscall table header files
arch/alpha/Makefile | 3 +
arch/alpha/include/asm/Kbuild | 2 +-
arch/alpha/include/asm/unistd.h | 23 +-
arch/alpha/include/uapi/asm/Kbuild | 1 +
arch/alpha/include/uapi/asm/unistd.h | 484 +--------------------------
arch/alpha/kernel/osf_sys.c | 9 +-
arch/alpha/kernel/syscalls/Makefile | 38 +++
arch/alpha/kernel/syscalls/syscall.tbl | 453 ++++++++++++++++++++++++++
arch/alpha/kernel/syscalls/syscallhdr.sh | 36 ++
arch/alpha/kernel/syscalls/syscalltbl.sh | 36 ++
arch/alpha/kernel/systbls.S | 542 +------------------------------
11 files changed, 600 insertions(+), 1027 deletions(-)
create mode 100644 arch/alpha/kernel/syscalls/Makefile
create mode 100644 arch/alpha/kernel/syscalls/syscall.tbl
create mode 100644 arch/alpha/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/alpha/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the
system call table generation support implementation
across all the architectures.
The system call tables are in different format in
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a
script and which'll generate uapi header file and
syscall table file.
syscall.tbl contains the list of available system
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the sim-
ilar support. I leverage their implementation to come
up with a generic solution.
I have done the same support for work for alpha, ia64,
m68k, microblaze, mips, parisc, powerpc, sparc, and
xtensa. Below mentioned git repository contains more
details about the workflow.
https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to solve
Y2038 issue. So this patch series will help to add new
system calls easily by adding new entry in the syscall.tbl.
Changes since v1:
- optimized/updated the syscall table generation
scripts.
- fixed all mixed indentation issues in syscall.tbl.
- added "comments" in syscall.tbl.
Firoz Khan (3):
sh: add __NR_syscalls along with NR_syscalls
sh: add system call table generation support
sh: generate uapi header and syscall table header files
arch/sh/Makefile | 3 +
arch/sh/include/asm/Kbuild | 1 +
arch/sh/include/asm/unistd.h | 2 +
arch/sh/include/uapi/asm/Kbuild | 1 +
arch/sh/include/uapi/asm/unistd_32.h | 4 +-
arch/sh/include/uapi/asm/unistd_64.h | 4 +-
arch/sh/kernel/syscalls/Makefile | 38 ++++
arch/sh/kernel/syscalls/syscall.tbl | 392 ++++++++++++++++++++++++++++++++++
arch/sh/kernel/syscalls/syscallhdr.sh | 36 ++++
arch/sh/kernel/syscalls/syscalltbl.sh | 32 +++
arch/sh/kernel/syscalls_32.S | 387 +--------------------------------
11 files changed, 514 insertions(+), 386 deletions(-)
create mode 100644 arch/sh/kernel/syscalls/Makefile
create mode 100644 arch/sh/kernel/syscalls/syscall.tbl
create mode 100644 arch/sh/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/sh/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture.
It will be difficult to manually add, modify or delete the system
calls in the respective files manually. To make it easy by keeping
a script and which'll generate uapi header file and syscall table
file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038 issue. We need
to add two dozen of system calls to solve Y2038 issue. So this patch
series will help to add new system calls easily by adding new entry
in the syscall.tbl.
Firoz Khan (4):
m68k: rename system call table file name
m68k: add __NR_syscalls along with NR_syscalls
m68k: add system call table generation support
m68k: generate uapi header and syscall table header files
arch/m68k/Makefile | 3 +
arch/m68k/include/asm/Kbuild | 1 +
arch/m68k/include/asm/unistd.h | 3 +-
arch/m68k/include/uapi/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/unistd.h | 385 +-----------------------------
arch/m68k/kernel/Makefile | 2 +-
arch/m68k/kernel/syscall_table.S | 26 +++
arch/m68k/kernel/syscalls/Makefile | 38 +++
arch/m68k/kernel/syscalls/syscall.tbl | 389 ++++++++++++++++++++++++++++++
arch/m68k/kernel/syscalls/syscallhdr.sh | 36 +++
arch/m68k/kernel/syscalls/syscalltbl.sh | 32 +++
arch/m68k/kernel/syscalltable.S | 403 --------------------------------
12 files changed, 529 insertions(+), 790 deletions(-)
create mode 100644 arch/m68k/kernel/syscall_table.S
create mode 100644 arch/m68k/kernel/syscalls/Makefile
create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/m68k/kernel/syscalltable.S
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture.
It will be difficult to manually add, modify or delete the system
calls in the respective files manually. To make it easy by keeping
a script and which'll generate uapi header file and syscall table
file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038 issue. We need
to add two dozen of system calls to solve Y2038 issue. So this patch
series will help to add new system calls easily by adding new entry
in the syscall.tbl.
Firoz Khan (5):
ia64: add __NR_old_getpagesize in uapi header file
ia64: add __NR_syscalls along with NR_syscalls
ia64: add an offset for system call number
ia64: add system call table generation support
ia64: generate uapi header and system call table files
arch/ia64/Makefile | 3 +
arch/ia64/include/asm/Kbuild | 1 +
arch/ia64/include/asm/unistd.h | 4 +-
arch/ia64/include/uapi/asm/Kbuild | 1 +
arch/ia64/include/uapi/asm/unistd.h | 332 +------------------------------
arch/ia64/kernel/entry.S | 331 +------------------------------
arch/ia64/kernel/syscalls/Makefile | 40 ++++
arch/ia64/kernel/syscalls/syscall.tbl | 337 ++++++++++++++++++++++++++++++++
arch/ia64/kernel/syscalls/syscallhdr.sh | 36 ++++
arch/ia64/kernel/syscalls/syscalltbl.sh | 32 +++
10 files changed, 457 insertions(+), 660 deletions(-)
create mode 100644 arch/ia64/kernel/syscalls/Makefile
create mode 100644 arch/ia64/kernel/syscalls/syscall.tbl
create mode 100644 arch/ia64/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/ia64/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture.
It will be difficult to manually add, modify or delete the system
calls in the respective files manually. To make it easy by keeping
a script and which'll generate uapi header file and syscall table
file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64, m68k, micro-
blaze, mips, powerpc, sh, sparc, and xtensa. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038 issue. We need
to add two dozen of system calls to solve Y2038 issue. So this patch
series will help to add new system calls easily by adding new entry
in the syscall.tbl.
Firoz Khan (5):
parisc: move __IGNORE* entries to non uapi header
parisc: add __NR_syscalls along with __NR_Linux_syscalls
parisc: add system call table generation support
parisc: generate uapi header and system call table files
parisc: syscalls: ignore nfsservctl for other architectures
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 8 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 382 +------------------------
arch/parisc/kernel/syscall.S | 11 +-
arch/parisc/kernel/syscall_table.S | 459 ------------------------------
arch/parisc/kernel/syscalls/Makefile | 57 ++++
arch/parisc/kernel/syscalls/syscall.tbl | 369 ++++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 36 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 36 +++
scripts/checksyscalls.sh | 1 +
12 files changed, 532 insertions(+), 836 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture.
It will be difficult to manually add, modify or delete the system
calls in the respective files manually. To make it easy by keeping
a script and which'll generate uapi header file and syscall table
file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64, m68k, mips,
parisc, powerpc, sh, sparc, and xtensa. Below mentioned git repos-
itory contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work to solve the Y2038 issue. We need
to add two dozen of system calls to solve Y2038 issue. So this patch
series will help to add new system calls easily by adding new entry
in the syscall.tbl.
Firoz Khan (3):
microblaze: move __NR_syscalls macro from asm/unistd.h
microblaze: add system call table generation support
microblaze: generate uapi header and system call table files
arch/microblaze/Makefile | 3 +
arch/microblaze/include/asm/Kbuild | 1 +
arch/microblaze/include/asm/unistd.h | 2 -
arch/microblaze/include/uapi/asm/Kbuild | 1 +
arch/microblaze/include/uapi/asm/unistd.h | 407 +------------------------
arch/microblaze/kernel/syscall_table.S | 406 +------------------------
arch/microblaze/kernel/syscalls/Makefile | 38 +++
arch/microblaze/kernel/syscalls/syscall.tbl | 410 ++++++++++++++++++++++++++
arch/microblaze/kernel/syscalls/syscallhdr.sh | 36 +++
arch/microblaze/kernel/syscalls/syscalltbl.sh | 32 ++
10 files changed, 526 insertions(+), 810 deletions(-)
create mode 100644 arch/microblaze/kernel/syscalls/Makefile
create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl
create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture. It
will be difficult to manually add, modify or delete the system calls
in the respective files manually. To make it easy by keeping a script
and which'll generate uapi header file and syscall table file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
m68k, mips, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add two dozen of system calls to solve Y2038 issue. So this
patch series will help to add new system calls easily by adding new
entry in the syscall.tbl.
Firoz Khan (5):
parisc: move __IGNORE* entries to non uapi header
parisc: add __NR_syscalls along with __NR_Linux_syscalls
parisc: add system call table generation support
parisc: uapi header and system call table file generation
parisc: syscalls: ignore nfsservctl for other architectures
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 8 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 382 +------------------------
arch/parisc/kernel/syscall.S | 10 +-
arch/parisc/kernel/syscall_table.S | 459 ------------------------------
arch/parisc/kernel/syscalls/Makefile | 57 ++++
arch/parisc/kernel/syscalls/syscall.tbl | 369 ++++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 34 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 36 +++
scripts/checksyscalls.sh | 1 +
12 files changed, 529 insertions(+), 836 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is, we can easily add/modify/delete
system call table support by changing entry in syscall.tbl file
instead of manually changing many files. The other goal is to unify
the system call table generation support implementation across all
the architectures.
The system call tables are in different format in all architecture. It
will be difficult to manually add, modify or delete the system calls
in the respective files manually. To make it easy by keeping a script
and which'll generate uapi header file and syscall table file.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
m68k, mips, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add two dozen of system calls to solve Y2038 issue. So this
patch series will help to add new system calls easily by adding new
entry in the syscall.tbl.
Firoz Khan (6):
parisc: move __IGNORE* entries to non uapi header
parisc: add __NR_Linux_syscalls along with __NR_syscalls
parisc: add system call table generation support
parisc: uapi header and system call table file generation
parisc: wire up rseq system call
parisc: syscalls: Ignore nfsservctl for other architectures
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 8 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 382 +------------------------
arch/parisc/kernel/syscall.S | 10 +-
arch/parisc/kernel/syscall_table.S | 459 ------------------------------
arch/parisc/kernel/syscalls/Makefile | 55 ++++
arch/parisc/kernel/syscalls/syscall.tbl | 371 ++++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 35 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 46 +++
scripts/checksyscalls.sh | 1 +
12 files changed, 540 insertions(+), 836 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64, sparc, mips,
parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (5):
m68k: rename system call table file name
m68k: replace NR_syscalls macro from asm/unistd.h
m68k: add system call table generation support
m68k: uapi header and system call table file generation
m68k: add __IGNORE* entries in asm/unistd.h
arch/m68k/Makefile | 3 +
arch/m68k/include/asm/Kbuild | 1 +
arch/m68k/include/asm/unistd.h | 10 +-
arch/m68k/include/uapi/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/unistd.h | 385 +-----------------------------
arch/m68k/kernel/Makefile | 2 +-
arch/m68k/kernel/syscall_table.S | 14 ++
arch/m68k/kernel/syscalls/Makefile | 38 +++
arch/m68k/kernel/syscalls/syscall.tbl | 369 +++++++++++++++++++++++++++++
arch/m68k/kernel/syscalls/syscallhdr.sh | 35 +++
arch/m68k/kernel/syscalls/syscalltbl.sh | 34 +++
arch/m68k/kernel/syscalltable.S | 403 --------------------------------
12 files changed, 505 insertions(+), 790 deletions(-)
create mode 100644 arch/m68k/kernel/syscall_table.S
create mode 100644 arch/m68k/kernel/syscalls/Makefile
create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/m68k/kernel/syscalltable.S
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
In v3 patch series, I wired up perf_event_open, seccomp, pkey_
mprotect, pkey_alloc, pkey_free, statx, io_pgetevents and rseq
system calls. This require an architecture specific implementation
as it not present now.
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (7):
ia64: add __NR_old_getpagesize in uapi/asm/unistd.h
ia64: replace NR_syscalls macro from asm/unistd.h
ia64: add an offset for system call number
ia64: replace the system call table entries from entry.S
ia64: add system call table generation support
ia64: uapi header and system call table file generation
ia64: wire up system calls
arch/ia64/Makefile | 3 +
arch/ia64/include/asm/Kbuild | 1 +
arch/ia64/include/asm/unistd.h | 4 +-
arch/ia64/include/uapi/asm/Kbuild | 1 +
arch/ia64/include/uapi/asm/unistd.h | 332 +-----------------------------
arch/ia64/kernel/entry.S | 333 +-----------------------------
arch/ia64/kernel/syscall_table.S | 9 +
arch/ia64/kernel/syscalls/Makefile | 39 ++++
arch/ia64/kernel/syscalls/syscall.tbl | 353 ++++++++++++++++++++++++++++++++
arch/ia64/kernel/syscalls/syscallhdr.sh | 35 ++++
arch/ia64/kernel/syscalls/syscalltbl.sh | 37 ++++
11 files changed, 483 insertions(+), 664 deletions(-)
create mode 100644 arch/ia64/kernel/syscall_table.S
create mode 100644 arch/ia64/kernel/syscalls/Makefile
create mode 100644 arch/ia64/kernel/syscalls/syscall.tbl
create mode 100644 arch/ia64/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/ia64/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
m68k, mips, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Added an ignore entry for nfsservctl in script/checksyscalls.sh.
Wired up rseq system call.
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (6):
parisc: move __IGNORE* entries to non uapi header
parisc: add __NR_Linux_syscalls along with __NR_syscalls
parisc: add system call table generation support
parisc: uapi header and system call table file generation
parisc: wire up rseq system call
parisc: syscalls: Ignore nfsservctl for other architectures
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 8 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 382 +------------------------
arch/parisc/kernel/syscall.S | 12 +-
arch/parisc/kernel/syscall_table.S | 459 ------------------------------
arch/parisc/kernel/syscall_table_32.S | 13 +
arch/parisc/kernel/syscall_table_64.S | 20 ++
arch/parisc/kernel/syscalls/Makefile | 55 ++++
arch/parisc/kernel/syscalls/syscall.tbl | 353 +++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 35 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 41 +++
scripts/checksyscalls.sh | 1 +
14 files changed, 545 insertions(+), 843 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscall_table_32.S
create mode 100644 arch/parisc/kernel/syscall_table_64.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64, sparc, mips,
parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (3):
microblaze: replace __NR_syscalls macro from asm/unistd.h
microblaze: add system call table generation support
microblaze: uapi header and system call table file generation
arch/microblaze/Makefile | 3 +
arch/microblaze/include/asm/Kbuild | 1 +
arch/microblaze/include/asm/unistd.h | 2 -
arch/microblaze/include/uapi/asm/Kbuild | 1 +
arch/microblaze/include/uapi/asm/unistd.h | 407 +-------------------------
arch/microblaze/kernel/syscall_table.S | 406 +------------------------
arch/microblaze/kernel/syscalls/Makefile | 38 +++
arch/microblaze/kernel/syscalls/syscall.tbl | 405 +++++++++++++++++++++++++
arch/microblaze/kernel/syscalls/syscallhdr.sh | 35 +++
arch/microblaze/kernel/syscalls/syscalltbl.sh | 34 +++
10 files changed, 522 insertions(+), 810 deletions(-)
create mode 100644 arch/microblaze/kernel/syscalls/Makefile
create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl
create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
m68k, mips, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Added an extra patch to keep __IGNORE* entries in asm/unistd.h.
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (5):
parisc: move __IGNORE* entries to non uapi header
parisc: add __NR_Linux_syscalls macro with __NR_syscalls
parisc: add system call table generation support
parisc: uapi header and system call table file generation
parisc: add __IGNORE* entries in asm/unistd.h
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 9 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 380 +-----------------------
arch/parisc/kernel/syscall.S | 12 +-
arch/parisc/kernel/syscall_table.S | 459 -----------------------------
arch/parisc/kernel/syscall_table_32.S | 13 +
arch/parisc/kernel/syscall_table_64.S | 20 ++
arch/parisc/kernel/syscalls/Makefile | 55 ++++
arch/parisc/kernel/syscalls/syscall_32.tbl | 342 +++++++++++++++++++++
arch/parisc/kernel/syscalls/syscall_64.tbl | 342 +++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 35 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 42 +++
14 files changed, 877 insertions(+), 841 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscall_table_32.S
create mode 100644 arch/parisc/kernel/syscall_table_64.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall_32.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscall_64.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in all architecture
and it will be difficult to manually add or modify the system calls
manually 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 the implementation across all architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, ia64,m68k, mips,
parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
it will generate a different syscall.tbl. But I still use the old
file - syscall.tbl and once all review got over I'll update
syscall.tbl alone w.r.to the tip of the kernel. The impact of this
is, few of the system call won't work.
Firoz Khan (3):
microblaze: Replace NR_syscalls macro from asm/unistd.h
microblaze: Added system call table generation support
microblaze: uapi header and system call table file generation
arch/microblaze/Makefile | 3 +
arch/microblaze/include/asm/Kbuild | 2 +
arch/microblaze/include/asm/unistd.h | 2 -
arch/microblaze/include/uapi/asm/Kbuild | 2 +
arch/microblaze/include/uapi/asm/unistd.h | 407 +-------------------------
arch/microblaze/kernel/syscall_table.S | 406 +------------------------
arch/microblaze/kernel/syscalls/Makefile | 37 +++
arch/microblaze/kernel/syscalls/syscall.tbl | 404 +++++++++++++++++++++++++
arch/microblaze/kernel/syscalls/syscallhdr.sh | 33 +++
arch/microblaze/kernel/syscalls/syscalltbl.sh | 28 ++
10 files changed, 514 insertions(+), 810 deletions(-)
create mode 100644 arch/microblaze/kernel/syscalls/Makefile
create mode 100644 arch/microblaze/kernel/syscalls/syscall.tbl
create mode 100644 arch/microblaze/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/microblaze/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Added an extra patch to add __NR_old_getpagesize macro.
Added an extra patch to keep __IGNORE* entries in asm/unistd.h.
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (7):
ia64: add __NR_old_getpagesize macro
ia64: replace NR_syscalls macro from asm/unistd.h
ia64: add an offset for system call number
ia64: replace the system call table entries from entry.S
ia64: add system call table generation support
ia64: uapi header and system call table file generation
ia64: add __IGNORE* entries in asm/unistd.h
arch/ia64/Makefile | 3 +
arch/ia64/include/asm/Kbuild | 1 +
arch/ia64/include/asm/unistd.h | 13 +-
arch/ia64/include/uapi/asm/Kbuild | 1 +
arch/ia64/include/uapi/asm/unistd.h | 334 +-------------------------------
arch/ia64/kernel/entry.S | 333 +------------------------------
arch/ia64/kernel/syscall_table.S | 12 ++
arch/ia64/kernel/syscalls/Makefile | 40 ++++
arch/ia64/kernel/syscalls/syscall.tbl | 328 +++++++++++++++++++++++++++++++
arch/ia64/kernel/syscalls/syscallhdr.sh | 35 ++++
arch/ia64/kernel/syscalls/syscalltbl.sh | 34 ++++
11 files changed, 469 insertions(+), 665 deletions(-)
create mode 100644 arch/ia64/kernel/syscall_table.S
create mode 100644 arch/ia64/kernel/syscalls/Makefile
create mode 100644 arch/ia64/kernel/syscalls/syscall.tbl
create mode 100644 arch/ia64/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/ia64/kernel/syscalls/syscalltbl.sh
--
1.9.1
There are only two 64-bit architecture ports that have a 32-bit
suseconds_t: sparc64 and parisc64. I've encountered a number of problems
with this, while trying to get a proper 64-bit time_t working on 32-bit
architectures. Having a 32-bit suseconds_t combined with a 64-bit time_t
means that we get extra padding in data structures that may leak kernel
stack data to user space, and it breaks all code that assumes that
timespec and timeval have the same layout.
While we can't change sparc64, it seems that glibc on parisc64 has always
set suseconds_t to 'long', and the current version would give incorrect
results for gettimeofday() and many other interfaces: timestamps passed
from user space into the kernel result in tv_usec being always zero
(the lower bits contain the intended value but are ignored) while data
passed from the kernel to user space contains either zeroes or random
data in tv_usec.
Based on that, it seems best to change the user API in the kernel in
an incompatible way to match what glibc expects.
Note that the distros I could find (gentoo and debian) all just
have 32-bit user space, which does not suffer from this problem.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/parisc/include/uapi/asm/posix_types.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/parisc/include/uapi/asm/posix_types.h b/arch/parisc/include/uapi/asm/posix_types.h
index 2785632c85e7..8dce56f5dcee 100644
--- a/arch/parisc/include/uapi/asm/posix_types.h
+++ b/arch/parisc/include/uapi/asm/posix_types.h
@@ -16,9 +16,6 @@ typedef unsigned short __kernel_mode_t;
typedef unsigned short __kernel_ipc_pid_t;
#define __kernel_ipc_pid_t __kernel_ipc_pid_t
-typedef int __kernel_suseconds_t;
-#define __kernel_suseconds_t __kernel_suseconds_t
-
typedef long long __kernel_off64_t;
typedef unsigned long long __kernel_ino64_t;
--
2.18.0
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
It will generate a new syscall.tbl. But I still use the old file -
syscall.tbl and once all review got over I'll update syscall.tbl
alone w.r.to the tip of the kernel. The impact of this thing, few
of the system call won't work.
Firoz Khan (4):
sparc: Move __IGNORE* entries to non uapi header
sparc: Replace NR_SYSCALLS macro with __NR_SYSCALLS
sparc: Add system call table generation support
sparc: uapi header and system call table file generation
arch/sparc/Makefile | 3 +
arch/sparc/include/asm/Kbuild | 5 +-
arch/sparc/include/asm/unistd.h | 27 ++
arch/sparc/include/uapi/asm/Kbuild | 3 +
arch/sparc/include/uapi/asm/unistd.h | 434 +-----------------------------
arch/sparc/kernel/Makefile | 2 +-
arch/sparc/kernel/head_64.S | 2 +-
arch/sparc/kernel/syscall_table_32.S | 12 +
arch/sparc/kernel/syscall_table_64.S | 22 ++
arch/sparc/kernel/syscalls/Makefile | 50 ++++
arch/sparc/kernel/syscalls/syscall_32.tbl | 365 +++++++++++++++++++++++++
arch/sparc/kernel/syscalls/syscall_64.tbl | 349 ++++++++++++++++++++++++
arch/sparc/kernel/syscalls/syscallhdr.sh | 33 +++
arch/sparc/kernel/syscalls/syscalltbl.sh | 38 +++
arch/sparc/kernel/systbls_32.S | 93 -------
arch/sparc/kernel/systbls_64.S | 176 ------------
16 files changed, 912 insertions(+), 702 deletions(-)
create mode 100644 arch/sparc/kernel/syscall_table_32.S
create mode 100644 arch/sparc/kernel/syscall_table_64.S
create mode 100644 arch/sparc/kernel/syscalls/Makefile
create mode 100644 arch/sparc/kernel/syscalls/syscall_32.tbl
create mode 100644 arch/sparc/kernel/syscalls/syscall_64.tbl
create mode 100644 arch/sparc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/sparc/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/sparc/kernel/systbls_32.S
delete mode 100644 arch/sparc/kernel/systbls_64.S
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, sparc,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Added an extra patch to keep __IGNORE* entries in asm/unistd.h.
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
Firoz Khan (5):
m68k: Rename system call table file name
m68k: Replace NR_syscalls macro from asm/unistd.h
m68k: Added system call table generation support
m68k: uapi header and system call table file generation
m68k: added __IGNORE* entries in asm/unistd.h
arch/m68k/Makefile | 3 +
arch/m68k/include/asm/Kbuild | 1 +
arch/m68k/include/asm/unistd.h | 10 +-
arch/m68k/include/uapi/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/unistd.h | 385 +-----------------------------
arch/m68k/kernel/Makefile | 2 +-
arch/m68k/kernel/syscall_table.S | 14 ++
arch/m68k/kernel/syscalls/Makefile | 37 +++
arch/m68k/kernel/syscalls/syscall.tbl | 369 +++++++++++++++++++++++++++++
arch/m68k/kernel/syscalls/syscallhdr.sh | 39 ++++
arch/m68k/kernel/syscalls/syscalltbl.sh | 28 +++
arch/m68k/kernel/syscalltable.S | 403 --------------------------------
12 files changed, 502 insertions(+), 790 deletions(-)
create mode 100644 arch/m68k/kernel/syscall_table.S
create mode 100644 arch/m68k/kernel/syscalls/Makefile
create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/m68k/kernel/syscalltable.S
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
ia64, mips, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
It will generate a new syscall.tbl. But I still use the old file -
syscall.tbl and once all review got over I'll update syscall.tbl
alone w.r.to the tip of the kernel. The impact of this thing, few
of the system call won't work.
Firoz Khan (4):
parisc: Move __IGNORE* entries to non uapi header
parisc: Replace __NR_Linux_syscalls macro with __NR_syscalls
parisc: Add system call table generation support
parisc: uapi header and system call table file generation
arch/parisc/Makefile | 4 +
arch/parisc/include/asm/Kbuild | 3 +
arch/parisc/include/asm/unistd.h | 8 +
arch/parisc/include/uapi/asm/Kbuild | 2 +
arch/parisc/include/uapi/asm/unistd.h | 377 +----------------------
arch/parisc/kernel/syscall.S | 14 +-
arch/parisc/kernel/syscall_table.S | 459 -----------------------------
arch/parisc/kernel/syscall_table_32.S | 11 +
arch/parisc/kernel/syscall_table_64.S | 19 ++
arch/parisc/kernel/syscalls/Makefile | 52 ++++
arch/parisc/kernel/syscalls/syscall_32.tbl | 358 ++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscall_64.tbl | 357 ++++++++++++++++++++++
arch/parisc/kernel/syscalls/syscallhdr.sh | 38 +++
arch/parisc/kernel/syscalls/syscalltbl.sh | 36 +++
14 files changed, 896 insertions(+), 842 deletions(-)
delete mode 100644 arch/parisc/kernel/syscall_table.S
create mode 100644 arch/parisc/kernel/syscall_table_32.S
create mode 100644 arch/parisc/kernel/syscall_table_64.S
create mode 100644 arch/parisc/kernel/syscalls/Makefile
create mode 100644 arch/parisc/kernel/syscalls/syscall_32.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscall_64.tbl
create mode 100644 arch/parisc/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/parisc/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in all architecture
and it will be difficult to manually add or modify the system calls
manually 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 the implementation across all architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, microblaze, ia64,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
it will generate a different syscall.tbl. But I still use the old
file - syscall.tbl and once all review got over I'll update
syscall.tbl alone w.r.to the tip of the kernel. The impact of this
is, few of the system call won't work.
Firoz Khan (4):
m68k: Rename system call table file name
m68k: Replace NR_syscalls macro from asm/unistd.h
m68k: Added system call table generation support
m68k: uapi header and system call table file generation
arch/m68k/68000/entry.S | 4 +-
arch/m68k/Makefile | 3 +
arch/m68k/coldfire/entry.S | 2 +-
arch/m68k/include/asm/Kbuild | 2 +
arch/m68k/include/asm/unistd.h | 3 -
arch/m68k/include/uapi/asm/Kbuild | 2 +
arch/m68k/include/uapi/asm/unistd.h | 385 +-----------------------------
arch/m68k/kernel/Makefile | 2 +-
arch/m68k/kernel/entry.S | 4 +-
arch/m68k/kernel/syscall_table.S | 14 ++
arch/m68k/kernel/syscalls/Makefile | 37 +++
arch/m68k/kernel/syscalls/syscall.tbl | 386 ++++++++++++++++++++++++++++++
arch/m68k/kernel/syscalls/syscallhdr.sh | 33 +++
arch/m68k/kernel/syscalls/syscalltbl.sh | 28 +++
arch/m68k/kernel/syscalltable.S | 403 --------------------------------
15 files changed, 512 insertions(+), 796 deletions(-)
create mode 100644 arch/m68k/kernel/syscall_table.S
create mode 100644 arch/m68k/kernel/syscalls/Makefile
create mode 100644 arch/m68k/kernel/syscalls/syscall.tbl
create mode 100644 arch/m68k/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/m68k/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/m68k/kernel/syscalltable.S
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
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 manually. 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 architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
- Compat entry name, if required.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
ia64, powerpc, parisc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
It will generate a new syscall.tbl. But I still use the old file -
syscall.tbl and once all review got over I'll update syscall.tbl
alone w.r.to the tip of the kernel. The impact of this thing, few
of the system call won't work.
Firoz Khan (3):
mips: Add __NR_syscalls macro in uapi/asm/unistd.h
mips: Add system call table generation support
mips: uapi header and system call table file generation
arch/mips/Makefile | 3 +
arch/mips/include/asm/Kbuild | 4 +
arch/mips/include/uapi/asm/Kbuild | 3 +
arch/mips/include/uapi/asm/unistd.h | 1053 +----------------------------
arch/mips/kernel/scall32-o32.S | 385 +----------
arch/mips/kernel/scall64-64.S | 334 +--------
arch/mips/kernel/scall64-n32.S | 337 +--------
arch/mips/kernel/scall64-o32.S | 374 +---------
arch/mips/kernel/syscall_table_32_o32.S | 8 +
arch/mips/kernel/syscall_table_64_64.S | 9 +
arch/mips/kernel/syscall_table_64_n32.S | 8 +
arch/mips/kernel/syscall_table_64_o32.S | 9 +
arch/mips/kernel/syscalls/Makefile | 62 ++
arch/mips/kernel/syscalls/README.md | 16 +
arch/mips/kernel/syscalls/syscall_32.tbl | 375 ++++++++++
arch/mips/kernel/syscalls/syscall_64.tbl | 335 +++++++++
arch/mips/kernel/syscalls/syscall_n32.tbl | 339 ++++++++++
arch/mips/kernel/syscalls/syscallhdr.sh | 37 +
arch/mips/kernel/syscalls/syscalltbl.sh | 44 ++
19 files changed, 1268 insertions(+), 2467 deletions(-)
create mode 100644 arch/mips/kernel/syscall_table_32_o32.S
create mode 100644 arch/mips/kernel/syscall_table_64_64.S
create mode 100644 arch/mips/kernel/syscall_table_64_n32.S
create mode 100644 arch/mips/kernel/syscall_table_64_o32.S
create mode 100644 arch/mips/kernel/syscalls/Makefile
create mode 100644 arch/mips/kernel/syscalls/README.md
create mode 100644 arch/mips/kernel/syscalls/syscall_32.tbl
create mode 100644 arch/mips/kernel/syscalls/syscall_64.tbl
create mode 100644 arch/mips/kernel/syscalls/syscall_n32.tbl
create mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in all architecture
and it will be difficult to manually add or modify the system calls
manually 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 the implementation across all architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
it will generate a different syscall.tbl. But I still use the old
file - syscall.tbl and once all review got over I'll update
syscall.tbl alone w.r.to the tip of the kernel. The impact of this
is, few of the system call won't work.
Firoz Khan (5):
ia64: Replace NR_syscalls macro from asm/unistd.h
ia64: Added an offset for system call number
ia64: Replaced the system call table entry from entry.S
ia64: Added system call table generation support
ia64: uapi header and system call table file generation
arch/ia64/Makefile | 3 +
arch/ia64/include/asm/Kbuild | 2 +
arch/ia64/include/asm/unistd.h | 4 -
arch/ia64/include/uapi/asm/Kbuild | 2 +
arch/ia64/include/uapi/asm/unistd.h | 331 +------------------------------
arch/ia64/kernel/entry.S | 335 +-------------------------------
arch/ia64/kernel/fsys.S | 2 +-
arch/ia64/kernel/gate.S | 4 +-
arch/ia64/kernel/ivt.S | 2 +-
arch/ia64/kernel/patch.c | 2 +-
arch/ia64/kernel/syscall.S | 13 ++
arch/ia64/kernel/syscalls/Makefile | 40 ++++
arch/ia64/kernel/syscalls/syscall.tbl | 334 +++++++++++++++++++++++++++++++
arch/ia64/kernel/syscalls/syscallhdr.sh | 33 ++++
arch/ia64/kernel/syscalls/syscalltbl.sh | 34 ++++
arch/ia64/mm/init.c | 6 +-
16 files changed, 474 insertions(+), 673 deletions(-)
create mode 100644 arch/ia64/kernel/syscall.S
create mode 100644 arch/ia64/kernel/syscalls/Makefile
create mode 100644 arch/ia64/kernel/syscalls/syscall.tbl
create mode 100644 arch/ia64/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/ia64/kernel/syscalls/syscalltbl.sh
--
1.9.1
The purpose of this patch series is:
1. We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
2. It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in all architecture
and it will be difficult to manually add or modify the system calls
manually 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 the implementation across all architectures.
syscall.tbl contains the list of available system calls along with
system call number and corresponding entry point. Add a new system
call in this architecture will be possible by adding new entry in
the syscall.tbl file.
Adding a new table entry consisting of:
- System call number.
- ABI.
- System call name.
- Entry point name.
Important thing to note, I have added this support only for 32-bit
ABI. It seems like no one using 64-bit ABI for long time. But it is
very easy to add the support for64-bit. Please let me know if any-
one need this support:)
ARM, s390 and x86 architecuture does exist the similar support. I
leverage their implementation to come up with a generic solution.
I have done the same support for work for alpha, m68k, microblaze,
ia64, mips, parisc, powerpc, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to add/change two dozen of system calls to solve Y2038 issue.
So this patch series will help to easily modify from existing
system call to Y2038 compatible system calls.
I started working system call table generation on 4.17-rc1. I used
marcin's script - https://github.com/hrw/syscalls-table to generate
the syscall.tbl file. And this will be the input to the system call
table generation script. But there are couple system call got add
in the latest rc release. If run Marcin's script on latest release,
it will generate a different syscall.tbl. But I still use the old
file - syscall.tbl and once all review got over I'll update
syscall.tbl alone w.r.to the tip of the kernel. The impact of this
is, few of the system call won't work.
Firoz Khan (3):
sh: Rename NR_syscalls macro to __NR_syscalls
sh: Added system call table generation support
sh: uapi header and system call table file generation
arch/sh/Makefile | 3 +
arch/sh/include/asm/Kbuild | 2 +
arch/sh/include/asm/ftrace.h | 2 +-
arch/sh/include/uapi/asm/Kbuild | 2 +
arch/sh/include/uapi/asm/unistd_32.h | 2 +-
arch/sh/include/uapi/asm/unistd_64.h | 2 +-
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel/cpu/sh5/entry.S | 2 +-
arch/sh/kernel/entry-common.S | 2 +-
arch/sh/kernel/syscall.S | 9 +
arch/sh/kernel/syscalls/Makefile | 37 ++++
arch/sh/kernel/syscalls/syscall.tbl | 388 ++++++++++++++++++++++++++++++++
arch/sh/kernel/syscalls/syscallhdr.sh | 33 +++
arch/sh/kernel/syscalls/syscalltbl.sh | 28 +++
arch/sh/kernel/syscalls_32.S | 402 ----------------------------------
15 files changed, 508 insertions(+), 408 deletions(-)
create mode 100644 arch/sh/kernel/syscall.S
create mode 100644 arch/sh/kernel/syscalls/Makefile
create mode 100644 arch/sh/kernel/syscalls/syscall.tbl
create mode 100644 arch/sh/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/sh/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/sh/kernel/syscalls_32.S
--
1.9.1
The series transitions the ppoll, io_getevents, and pselect syscalls
to be y2038 safe.
This is part of the work proceeding for syscalls for y2038.
It is based on the series [1] from Arnd Bergmann.
The overview of the series is as below:
1. Refactor sigmask handling logic for the above syscalls.
2. Provide y2038 safe versions of syscalls for all ABIs.
[1] https://lkml.org/lkml/2018/8/27/651
Changes since v2:
* remove 64BIT_TIME conditional for ppoll, pselect,
io_getpevents as per review comments
Changes since v1:
* fixed bug pointed out by arnd
Deepa Dinamani (5):
signal: Add set_user_sigmask()
signal: Add restore_user_sigmask()
ppoll: use __kernel_timespec
pselect6: use __kernel_timespec
io_pgetevents: use __kernel_timespec
fs/aio.c | 135 ++++++++++-----
fs/eventpoll.c | 52 +-----
fs/select.c | 360 ++++++++++++++++++++++-----------------
include/linux/compat.h | 20 +++
include/linux/signal.h | 4 +
include/linux/syscalls.h | 20 ++-
kernel/signal.c | 78 +++++++++
7 files changed, 427 insertions(+), 242 deletions(-)
--
2.17.1
Hi Thomas,
Please pull the system call changes into a branch of the tip tree.
These are the ones I posted right after rc1, with the addition of
two bug fixes that were contributed by Guenther and the kbuild test
robot.
I've had the changes in linux-next since then and not received
any other bug reports or feedback.
I panicked a little at one point when I realized that there is
a sparc64 specific bug in some of my patches, but I then
found that at least this series is not affected at all.
Arnd
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git+ssh://git@ra.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038
for you to fetch changes up to 67314ec7b0250290cc85eaa7a2f88a8ddb9e8547:
RISC-V: Request newstat syscalls (2018-09-05 22:44:21 +0200)
----------------------------------------------------------------
y2038: convert more syscalls
Here is another set of system call changes to prepare the change over to
64-bit time_t. As before, the strategy is to change system calls that
take a 'struct timespec' argument over to 'struct __kernel_timespec',
which for now is defined to be the same but will get redefined to use a
64-bit time_t argument once we are ready to modify the system call tables.
The major change from previous patches is that the plan is no longer
to directly use the 'compat' system calls for providing compatibility
with the existing 32-bit time_t based entry points. Instead, we rename
the compat code to something that makes more sense on 32-bit architectures,
e.g. compat_timespec becomes old_timespec32.
With the renamed types in place, we change over the 'stat' and 'utimes'
families of system calls, sched_rr_get_interval, recvmmsg and
rt_sigtimedwait. Another series for poll, select and io_pgetevents is
currently being tested.
----------------------------------------------------------------
Arnd Bergmann (14):
y2038: remove unused time interfaces
y2038: make do_gettimeofday() and get_seconds() inline
y2038: globally rename compat_time to old_time32
y2038: Remove newstat family from default syscall set
y2038: Remove stat64 family from default syscall set
asm-generic: Move common compat types to asm-generic/compat.h
asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro
asm-generic: Remove empty asm/unistd.h
y2038: Change sys_utimensat() to use __kernel_timespec
y2038: Compile utimes()/futimesat() conditionally
y2038: utimes: Rework #ifdef guards for compat syscalls
y2038: sched: Change sched_rr_get_interval to use __kernel_timespec
y2038: socket: Change recvmmsg to use __kernel_timespec
y2038: signal: Change rt_sigtimedwait to use __kernel_timespec
Guenter Roeck (1):
RISC-V: Request newstat syscalls
kbuild test robot (1):
y2038: __get_old_timespec32() can be static
arch/alpha/include/asm/unistd.h | 2 ++
arch/arc/include/uapi/asm/unistd.h | 1 +
arch/arm/include/asm/unistd.h | 4 ++--
arch/arm64/include/asm/compat.h | 26 +++++---------------------
arch/arm64/include/asm/stat.h | 2 +-
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/uapi/asm/unistd.h | 1 +
arch/c6x/include/uapi/asm/unistd.h | 1 +
arch/h8300/include/uapi/asm/unistd.h | 1 +
arch/hexagon/include/uapi/asm/unistd.h | 1 +
arch/ia64/include/asm/unistd.h | 3 +++
arch/m68k/include/asm/unistd.h | 2 +-
arch/microblaze/include/asm/unistd.h | 2 +-
arch/mips/include/asm/compat.h | 28 +++++-----------------------
arch/mips/include/asm/unistd.h | 3 ++-
arch/mips/kernel/binfmt_elfn32.c | 14 +++++++-------
arch/mips/kernel/binfmt_elfo32.c | 14 +++++++-------
arch/nds32/include/uapi/asm/unistd.h | 1 +
arch/nios2/include/uapi/asm/unistd.h | 1 +
arch/openrisc/include/uapi/asm/unistd.h | 1 +
arch/parisc/include/asm/compat.h | 24 +++++-------------------
arch/parisc/include/asm/unistd.h | 3 ++-
arch/powerpc/include/asm/compat.h | 24 +++++-------------------
arch/powerpc/include/asm/unistd.h | 3 ++-
arch/powerpc/kernel/asm-offsets.c | 8 ++++----
arch/powerpc/oprofile/backtrace.c | 2 +-
arch/riscv/include/asm/unistd.h | 1 +
arch/s390/include/asm/compat.h | 18 ++----------------
arch/s390/include/asm/unistd.h | 3 ++-
arch/sh/include/asm/unistd.h | 2 +-
arch/sparc/include/asm/compat.h | 25 +++++--------------------
arch/sparc/include/asm/unistd.h | 3 ++-
arch/unicore32/include/uapi/asm/unistd.h | 1 +
arch/x86/include/asm/compat.h | 19 ++-----------------
arch/x86/include/asm/unistd.h | 3 ++-
arch/xtensa/include/asm/unistd.h | 2 +-
fs/aio.c | 8 ++++----
fs/compat_binfmt_elf.c | 2 +-
fs/read_write.c | 2 +-
fs/select.c | 20 ++++++++++----------
fs/stat.c | 3 +++
fs/timerfd.c | 12 ++++++------
fs/utimes.c | 73
+++++++++++++++++++++++++++++++++++--------------------------------------
include/asm-generic/compat.h | 24 +++++++++++++++++++++++-
include/asm-generic/unistd.h | 13 -------------
include/linux/compat.h | 101
+++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------------------
include/linux/compat_time.h | 32 --------------------------------
include/linux/elfcore-compat.h | 8 ++++----
include/linux/restart_block.h | 4 ++--
include/linux/socket.h | 4 ++--
include/linux/syscalls.h | 21 ++++++++++++---------
include/linux/time32.h | 78
+++++++++++++++++++++++++++++++++++++++++-------------------------------------
include/linux/timekeeping.h | 12 ------------
include/linux/timekeeping32.h | 53
+++++++----------------------------------------------
include/uapi/asm-generic/unistd.h | 2 ++
ipc/mqueue.c | 8 ++++----
ipc/msg.c | 6 +++---
ipc/sem.c | 10 +++++-----
ipc/shm.c | 6 +++---
ipc/syscall.c | 2 +-
ipc/util.h | 2 +-
kernel/compat.c | 8 ++++----
kernel/futex_compat.c | 2 +-
kernel/sched/core.c | 8 ++++----
kernel/signal.c | 19 ++++++++++---------
kernel/time/hrtimer.c | 8 ++++----
kernel/time/posix-stubs.c | 18 +++++++++---------
kernel/time/posix-timers.c | 30 +++++++++++++++---------------
kernel/time/time.c | 97
++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------
kernel/time/timekeeping.c | 24 ------------------------
net/compat.c | 10 +++++-----
net/socket.c | 18 ++++++++----------
72 files changed, 398 insertions(+), 601 deletions(-)
delete mode 100644 include/asm-generic/unistd.h
delete mode 100644 include/linux/compat_time.h
Reply
Forward
The series transitions the ppoll, io_getevents, and pselect syscalls
to be y2038 safe.
This is part of the work proceeding for syscalls for y2038.
It is based on the series [1] from Arnd Bergmann.
The overview of the series is as below:
1. Refactor sigmask handling logic for the above syscalls.
2. Provide y2038 safe versions of syscalls for all ABIs.
[1] https://lkml.org/lkml/2018/8/27/651
Changes since v1:
* fixed bug pointed out by arnd
Deepa Dinamani (5):
signal: Add set_user_sigmask()
signal: Add restore_user_sigmask()
ppoll: use __kernel_timespec
pselect6: use __kernel_timespec
io_pgetevents: use __kernel_timespec
fs/aio.c | 138 ++++++++++-----
fs/eventpoll.c | 52 +-----
fs/select.c | 367 +++++++++++++++++++++++----------------
include/linux/compat.h | 20 +++
include/linux/signal.h | 4 +
include/linux/syscalls.h | 20 ++-
kernel/signal.c | 78 +++++++++
7 files changed, 437 insertions(+), 242 deletions(-)
--
2.17.1
The series transitions the ppoll, io_getevents, and pselect syscalls
to be y2038 safe.
This is part of the work proceeding for syscalls for y2038.
It is based on the series [1] from Arnd Bergmann.
The overview of the series is as below:
1. Refactor sigmask handling logic for the above syscalls.
2. Provide y2038 safe versions of syscalls for all ABIs.
[1] https://lkml.org/lkml/2018/8/27/651
Deepa Dinamani (5):
signal: Add set_user_sigmask()
signal: Add restore_user_sigmask()
ppoll: use __kernel_timespec
pselect6: use __kernel_timespec
io_pgetevents: use __kernel_timespec
fs/aio.c | 138 ++++++++++-----
fs/eventpoll.c | 52 +-----
fs/select.c | 367 +++++++++++++++++++++++----------------
include/linux/compat.h | 20 +++
include/linux/signal.h | 4 +
include/linux/syscalls.h | 20 ++-
kernel/signal.c | 78 +++++++++
7 files changed, 437 insertions(+), 242 deletions(-)
--
2.17.1
The old rtc driver is getting in the way of some compat_ioctl
simplification. Looking up the loongson64 git history, it seems
that everyone uses the more modern but compatible RTC_CMOS driver
anyway, so let's remove the special case for loongson64.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/mips/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 35511999156a..c695825d9377 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -75,7 +75,7 @@ config MIPS
select MODULES_USE_ELF_RELA if MODULES && 64BIT
select MODULES_USE_ELF_REL if MODULES
select PERF_USE_VMALLOC
- select RTC_LIB if !MACH_LOONGSON64
+ select RTC_LIB
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index ce277ee0a28a..131b4c300050 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -268,7 +268,7 @@ if RTC_LIB=n
config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
- depends on ALPHA || (MIPS && MACH_LOONGSON64)
+ depends on ALPHA
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
--
2.18.0
The VIDEO_GET_EVENT and VIDEO_STILLPICTURE was added back in 2005 but
it never worked because the command number is wrong.
Using the right command number means we have a better chance of them
actually doing the right thing, though clearly nobody has ever tried
it successfully.
I noticed these while auditing the remaining users of compat_time_t
for y2038 bugs. This one is fine in that regard, it just never did
anything.
Fixes: 6e87abd0b8cb ("[DVB]: Add compat ioctl handling.")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
fs/compat_ioctl.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index a9b00942e87d..0c46ce224590 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -141,6 +141,7 @@ struct compat_video_event {
unsigned int frame_rate;
} u;
};
+#define VIDEO_GET_EVENT32 _IOR('o', 28, struct compat_video_event)
static int do_video_get_event(struct file *file,
unsigned int cmd, struct compat_video_event __user *up)
@@ -152,7 +153,7 @@ static int do_video_get_event(struct file *file,
if (kevent == NULL)
return -EFAULT;
- err = do_ioctl(file, cmd, (unsigned long)kevent);
+ err = do_ioctl(file, VIDEO_GET_EVENT, (unsigned long)kevent);
if (!err) {
err = convert_in_user(&kevent->type, &up->type);
err |= convert_in_user(&kevent->timestamp, &up->timestamp);
@@ -171,6 +172,7 @@ struct compat_video_still_picture {
compat_uptr_t iFrame;
int32_t size;
};
+#define VIDEO_STILLPICTURE32 _IOW('o', 30, struct compat_video_still_picture)
static int do_video_stillpicture(struct file *file,
unsigned int cmd, struct compat_video_still_picture __user *up)
@@ -193,7 +195,7 @@ static int do_video_stillpicture(struct file *file,
if (err)
return -EFAULT;
- err = do_ioctl(file, cmd, (unsigned long) up_native);
+ err = do_ioctl(file, VIDEO_STILLPICTURE, (unsigned long) up_native);
return err;
}
@@ -1305,9 +1307,9 @@ static long do_ioctl_trans(unsigned int cmd,
return rtc_ioctl(file, cmd, argp);
/* dvb */
- case VIDEO_GET_EVENT:
+ case VIDEO_GET_EVENT32:
return do_video_get_event(file, cmd, argp);
- case VIDEO_STILLPICTURE:
+ case VIDEO_STILLPICTURE32:
return do_video_stillpicture(file, cmd, argp);
}
--
2.18.0
Support for handling the PPPOEIOCSFWD ioctl in compat mode was added in
linux-2.5.69 along with hundreds of other commands, but was always broken
sincen only the structure is compatible, but the command number is not,
due to the size being sizeof(size_t), or at first sizeof(sizeof((struct
sockaddr_pppox)), which is different on 64-bit architectures.
Fix it by defining a separate command code that matches the 32-bit
version, and marking that one as compatible.
This should apply to all stable kernels.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
drivers/net/ppp/pppoe.c | 4 ++++
fs/compat_ioctl.c | 2 +-
include/linux/if_pppox.h | 2 ++
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index ce61231e96ea..d1c3f9292c54 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -57,6 +57,7 @@
*
*/
+#include <linux/compat.h>
#include <linux/string.h>
#include <linux/module.h>
#include <linux/kernel.h>
@@ -780,6 +781,9 @@ static int pppoe_ioctl(struct socket *sock, unsigned int cmd,
err = 0;
break;
+#ifdef CONFIG_COMPAT
+ case PPPOEIOCSFWD32:
+#endif
case PPPOEIOCSFWD:
{
struct pppox_sock *relay_po;
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index a9b00942e87d..a8bb193fdfd5 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -895,7 +895,7 @@ COMPATIBLE_IOCTL(PPPIOCATTCHAN)
COMPATIBLE_IOCTL(PPPIOCGCHAN)
COMPATIBLE_IOCTL(PPPIOCGL2TPSTATS)
/* PPPOX */
-COMPATIBLE_IOCTL(PPPOEIOCSFWD)
+COMPATIBLE_IOCTL(PPPOEIOCSFWD32)
COMPATIBLE_IOCTL(PPPOEIOCDFWD)
/* Big A */
/* sparc only */
diff --git a/include/linux/if_pppox.h b/include/linux/if_pppox.h
index ba7a9b0c7c57..d221f1465f41 100644
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -85,6 +85,8 @@ extern void unregister_pppox_proto(int proto_num);
extern void pppox_unbind_sock(struct sock *sk);/* delete ppp-channel binding */
extern int pppox_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg);
+#define PPPOEIOCSFWD32 _IOW(0xB1 ,0, compat_size_t)
+
/* PPPoX socket states */
enum {
PPPOX_NONE = 0, /* initial state */
--
2.18.0
The old rtc driver is getting in the way of some compat_ioctl
simplification. Looking up the loongson64 git history, it seems
that everyone uses the more modern but compatible RTC_CMOS driver
anyway, so let's remove the special case for loongson64.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/mips/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 35511999156a..c695825d9377 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -75,7 +75,7 @@ config MIPS
select MODULES_USE_ELF_RELA if MODULES && 64BIT
select MODULES_USE_ELF_REL if MODULES
select PERF_USE_VMALLOC
- select RTC_LIB if !MACH_LOONGSON64
+ select RTC_LIB
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index ce277ee0a28a..131b4c300050 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -268,7 +268,7 @@ if RTC_LIB=n
config RTC
tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
- depends on ALPHA || (MIPS && MACH_LOONGSON64)
+ depends on ALPHA
---help---
If you say Y here and create a character special file /dev/rtc with
major number 10 and minor number 135 using mknod ("man mknod"), you
--
2.18.0
This is a note to let you know that I've just added the patch titled
posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
to the 4.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch
and it can be found in the queue-4.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Aug 22 09:16:55 CEST 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Mon, 18 Jun 2018 16:07:59 +0200
Subject: posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 0fe2795516b9e1c59b58b02bdf8658698117ec4e ]
Commit b5793b0d92c9 added support for building the nanosleep compat system
call on 32-bit architectures, but missed one change in nanosleep_copyout(),
which would trigger a BUG() as soon as any architecture is switched over to
use it.
Use the proper config symbol to enable the code path.
Fixes: Commit b5793b0d92c9 ("posix-timers: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: y2038(a)lists.linaro.org
Cc: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Deepa Dinamani <deepa.kernel(a)gmail.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Link: https://lkml.kernel.org/r/20180618140811.2998503-1-arnd@arndb.de
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1659,7 +1659,7 @@ EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
int nanosleep_copyout(struct restart_block *restart, struct timespec64 *ts)
{
switch(restart->nanosleep.type) {
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
case TT_COMPAT:
if (compat_put_timespec64(ts, restart->nanosleep.compat_rmtp))
return -EFAULT;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.17/posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch
queue-4.17/ieee802154-mcr20a-add-missing-includes.patch
queue-4.17/drm-sun4i-link-in-front-end-code-if-needed.patch
As part of the system call rework for 64-bit time_t, we are restructuring
the way that compat syscalls deal with 32-bit time_t, reusing the
implementation for 32-bit architectures. Christoph Hellwig suggested
a rename of the associated types and interfaces to avoid the confusing
usage of the 'compat' prefix for 32-bit architectures.
To prepare for doing that in linux-4.20, this adds a set of macros
that lets us convert subsystems separately to the new names and
avoid some of the nastier merge conflicts.
Link: https://lore.kernel.org/lkml/20180713133204.3123939-1-arnd@arndb.de/
Cc: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
The patch I posted originally was ready but didn't see proper linux-next
testing as I did not get to finalize it before my summer vacation,
so this is the minimal replacement I'd still like to get into 4.19-rc1,
in order to base patches for system calls, sound, networking, media
and file systems on top of.
I have put it into linux-next now after realizing that it would be
a problem to do all my other planned changes for the 4.20 merge
window. Please let me know if you have concerns about the approach,
or provide an Ack if this is ok with you.
---
include/linux/time32.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/linux/time32.h b/include/linux/time32.h
index 0b14f936100a..d1ae43c13e25 100644
--- a/include/linux/time32.h
+++ b/include/linux/time32.h
@@ -207,4 +207,19 @@ static inline s64 timeval_to_ns(const struct timeval *tv)
extern struct timeval ns_to_timeval(const s64 nsec);
extern struct __kernel_old_timeval ns_to_kernel_old_timeval(s64 nsec);
+/*
+ * New aliases for compat time functions. These will be used to replace
+ * the compat code so it can be shared between 32-bit and 64-bit builds
+ * both of which provide compatibility with old 32-bit tasks.
+ */
+#define old_time32_t compat_time_t
+#define old_timeval32 compat_timeval
+#define old_timespec32 compat_timespec
+#define old_itimerspec32 compat_itimerspec
+#define ns_to_old_timeval32 ns_to_compat_timeval
+#define get_old_itimerspec32 get_compat_itimerspec64
+#define put_old_itimerspec32 put_compat_itimerspec64
+#define get_old_timespec32 compat_get_timespec64
+#define put_old_timespec32 compat_put_timespec64
+
#endif
--
2.18.0
This is a note to let you know that I've just added the patch titled
posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Wed Aug 22 09:33:46 CEST 2018
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Mon, 18 Jun 2018 16:07:59 +0200
Subject: posix-timers: Fix nanosleep_copyout() for CONFIG_COMPAT_32BIT_TIME
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 0fe2795516b9e1c59b58b02bdf8658698117ec4e ]
Commit b5793b0d92c9 added support for building the nanosleep compat system
call on 32-bit architectures, but missed one change in nanosleep_copyout(),
which would trigger a BUG() as soon as any architecture is switched over to
use it.
Use the proper config symbol to enable the code path.
Fixes: Commit b5793b0d92c9 ("posix-timers: Make compat syscalls depend on CONFIG_COMPAT_32BIT_TIME")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: y2038(a)lists.linaro.org
Cc: Anna-Maria Gleixner <anna-maria(a)linutronix.de>
Cc: Deepa Dinamani <deepa.kernel(a)gmail.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com>
Link: https://lkml.kernel.org/r/20180618140811.2998503-1-arnd@arndb.de
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/time/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1450,7 +1450,7 @@ EXPORT_SYMBOL_GPL(hrtimer_init_sleeper);
int nanosleep_copyout(struct restart_block *restart, struct timespec64 *ts)
{
switch(restart->nanosleep.type) {
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
case TT_COMPAT:
if (compat_put_timespec64(ts, restart->nanosleep.compat_rmtp))
return -EFAULT;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/posix-timers-fix-nanosleep_copyout-for-config_compat_32bit_time.patch
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 does have the similar support. I leverage their
implementation to come up with a generic solution.
I have done the same support for work for ia64, m68k, microblaze,
mips, parisc, powerpc, sh, sparc, and xtensa. But I started sending
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/
Finally, this is the ground work for solving the Y2038 issue. We
need to change two dozen of system calls to solve Y2038 issue. So
this implementation will help to easily modify from existing system
call to Y2038 compatible system calls.
Firoz Khan (6):
alpha: Move __IGNORE* entries to non uapi header
alpha: Add CONFIG_OSF4_COMPAT for compat syscall support
alpha: Unify the not-implemented system call entry name
alpha: Replace NR_SYSCALLS macro from asm/unistd.h
alpha: Add system call table generation support
alpha: uapi header and system call table file generation
arch/alpha/Makefile | 3 +
arch/alpha/include/asm/Kbuild | 3 +-
arch/alpha/include/asm/unistd.h | 7 +-
arch/alpha/include/uapi/asm/Kbuild | 2 +
arch/alpha/include/uapi/asm/unistd.h | 489 ---------------------------
arch/alpha/kernel/Makefile | 2 +-
arch/alpha/kernel/entry.S | 4 +-
arch/alpha/kernel/osf_sys.c | 9 +-
arch/alpha/kernel/syscall.S | 20 ++
arch/alpha/kernel/syscalls/Makefile | 37 +++
arch/alpha/kernel/syscalls/syscall.tbl | 450 +++++++++++++++++++++++++
arch/alpha/kernel/syscalls/syscallhdr.sh | 33 ++
arch/alpha/kernel/syscalls/syscalltbl.sh | 28 ++
arch/alpha/kernel/systbls.S | 552 -------------------------------
14 files changed, 589 insertions(+), 1050 deletions(-)
delete mode 100644 arch/alpha/include/uapi/asm/unistd.h
create mode 100644 arch/alpha/kernel/syscall.S
create mode 100644 arch/alpha/kernel/syscalls/Makefile
create mode 100644 arch/alpha/kernel/syscalls/syscall.tbl
create mode 100644 arch/alpha/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/alpha/kernel/syscalls/syscalltbl.sh
delete mode 100644 arch/alpha/kernel/systbls.S
--
2.7.4
current_time is the last remaining caller of current_kernel_time64(),
which is a wrapper around ktime_get_coarse_real_ts64(). This calls the
latter directly for consistency with the rest of the kernel that is
moving to the ktime_get_ family of time accessors, as now documented
in Documentation/core-api/timekeeping.rst.
An open questions is whether we may want to actually call the more
accurate ktime_get_real_ts64() for file systems that save high-resolution
timestamps in their on-disk format. This would add a small overhead to
each update of the inode stamps but lead to inode timestamps to actually
have a usable resolution better than one jiffy (1 to 10 milliseconds
normally). Experiments on a variety of hardware platforms show a typical
time of around 100 CPU cycles to read the cycle counter and calculate
the accurate time from that. On old platforms without a cycle counter,
this can be signiciantly higher, up to several microseconds to access
a hardware clock, but those have become very rare by now.
I traced the original addition of the current_kernel_time() call to set
the nanosecond fields back to linux-2.5.48, where Andi Kleen added a
patch with subject "nanosecond stat timefields". Andi explains that the
motivation was to introduce as little overhead as possible back then. At
this time, reading the clock hardware was also more expensive when most
architectures did not have a cycle counter.
One side effect of having more accurate inode timestamp would be having
to write out the inode every time that mtime/ctime/atime get touched on
most systems, whereas many file systems today only write it when the
timestamps have changed, i.e. at most once per jiffy unless something
else changes as well. That change would certainly be noticed in some
workloads, which is enough reason to not do it without a good reason,
regardless of the cost of reading the time.
One thing we could still consider however would be to round the timestamps
from current_time() to multiples of NSEC_PER_JIFFY, e.g. full milliseconds
rather than having six or seven meaningless but confusing digits at the
end of the timestamp.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
--
changes in v2:
* wait for Documentation to get merged first, as Dave Chinner requested
* rewrite changelog based on discussion
---
fs/inode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/inode.c b/fs/inode.c
index 462eb50b096f..c2dbab9a7cf5 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -2105,7 +2105,9 @@ EXPORT_SYMBOL(timespec64_trunc);
*/
struct timespec64 current_time(struct inode *inode)
{
- struct timespec64 now = current_kernel_time64();
+ struct timespec64 now;
+
+ ktime_get_coarse_real_ts64(&now);
if (unlikely(!inode->i_sb)) {
WARN(1, "current_time() called with uninitialized super_block in the inode");
--
2.18.0
According to the official documentation for HFS+ [1], inode timestamps
are supposed to cover the time range from 1904 to 2040 as originally
used in classic MacOS.
The traditional Linux usage is to convert the timestamps into an unsigned
32-bit number based on the Unix epoch and from there to a time_t. On
32-bit systems, that wraps the time from 2038 to 1902, so the last
two years of the valid time range become garbled. On 64-bit systems,
all times before 1970 get turned into timestamps between 2038 and 2106,
which is more convenient but also different from the documented behavior.
Looking at the Darwin sources [2], it seems that MacOS is inconsistent in
yet another way: all timestamps are wrapped around to a 32-bit unsigned
number when written to the disk, but when read back, all numeric values
lower than 2082844800U are assumed to be invalid, so we cannot represent
the times before 1970 or the times after 2040.
While all implementations seem to agree on the interpretation of values
between 1970 and 2038, they often differ on the exact range they support
when reading back values outside of the common range:
MacOS (traditional): 1904-2040
Apple Documentation: 1904-2040
MacOS X source comments: 1970-2040
MacOS X source code: 1970-2038
32-bit Linux: 1902-2038
64-bit Linux: 1970-2106
hfsfuse: 1970-2040
hfsutils (32 bit, old libc) 1902-2038
hfsutils (32 bit, new libc) 1970-2106
hfsutils (64 bit) 1904-2040
hfsplus-utils 1904-2040
hfsexplorer 1904-2040
7-zip 1904-2040
This changes Linux over to mostly the same behavior as described in the
code comment in MacOS X, disallowing all times before 1970 and after
2040, while still allowing times between 2038 and 2040 like most other
implementations do. Most importantly, it means we can have the same
behavior on 32-bit and 64-bit.
Cc: stable(a)vger.kernel.org
Link: [1] https://developer.apple.com/library/archive/technotes/tn/tn1150.html
Link: [2] https://opensource.apple.com/source/hfs/hfs-407.30.1/core/MacOSStubs.c.auto…
Suggested-by: Viacheslav Dubeyko <slava(a)dubeyko.com>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
v2: treat pre-1970 dates as invalid following MacOS X behavior,
reword and expand changelog text
---
fs/hfs/hfs_fs.h | 29 +++++++++++++++++++++++++----
fs/hfsplus/hfsplus_fs.h | 26 +++++++++++++++++++++++---
2 files changed, 48 insertions(+), 7 deletions(-)
diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h
index 6d0783e2e276..1af998fb522e 100644
--- a/fs/hfs/hfs_fs.h
+++ b/fs/hfs/hfs_fs.h
@@ -246,14 +246,35 @@ extern void hfs_mark_mdb_dirty(struct super_block *sb);
* mac: unsigned big-endian since 00:00 GMT, Jan. 1, 1904
*
*/
-#define __hfs_u_to_mtime(sec) cpu_to_be32(sec + 2082844800U - sys_tz.tz_minuteswest * 60)
-#define __hfs_m_to_utime(sec) (be32_to_cpu(sec) - 2082844800U + sys_tz.tz_minuteswest * 60)
+static inline time64_t __hfs_m_to_utime(__be32 mt)
+{
+ time64_t ut = (u32)(be32_to_cpu(mt) - 2082844800U);
+
+ /*
+ * Times past 2040-02-06 06:28 are assumed to be invalid,
+ * matching the MacOS behavior.
+ */
+ if (ut > 2082844800U + UINT_MAX)
+ ut = 0;
+
+ return ut + sys_tz.tz_minuteswest * 60;
+}
+static inline __be32 __hfs_u_to_mtime(time64_t ut)
+{
+ ut -= - sys_tz.tz_minuteswest * 60;
+
+ /*
+ * MacOS wraps "invalid" times after 2040 when writing back, so
+ * let's do the same here.
+ */
+ return cpu_to_be32(lower_32_bits(ut + 2082844800U));
+}
#define HFS_I(inode) (container_of(inode, struct hfs_inode_info, vfs_inode))
#define HFS_SB(sb) ((struct hfs_sb_info *)(sb)->s_fs_info)
-#define hfs_m_to_utime(time) (struct timespec){ .tv_sec = __hfs_m_to_utime(time) }
-#define hfs_u_to_mtime(time) __hfs_u_to_mtime((time).tv_sec)
+#define hfs_m_to_utime(time) (struct timespec){ .tv_sec = __hfs_m_to_utime(time) }
+#define hfs_u_to_mtime(time) __hfs_u_to_mtime((time).tv_sec)
#define hfs_mtime() __hfs_u_to_mtime(get_seconds())
static inline const char *hfs_mdb_name(struct super_block *sb)
diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
index d9255abafb81..7f0943e540a0 100644
--- a/fs/hfsplus/hfsplus_fs.h
+++ b/fs/hfsplus/hfsplus_fs.h
@@ -530,9 +530,29 @@ int hfsplus_submit_bio(struct super_block *sb, sector_t sector, void *buf,
void **data, int op, int op_flags);
int hfsplus_read_wrapper(struct super_block *sb);
-/* time macros */
-#define __hfsp_mt2ut(t) (be32_to_cpu(t) - 2082844800U)
-#define __hfsp_ut2mt(t) (cpu_to_be32(t + 2082844800U))
+/* time helpers */
+static inline time64_t __hfsp_mt2ut(__be32 mt)
+{
+ time64_t ut = (u32)(be32_to_cpu(mt) - 2082844800U);
+
+ /*
+ * Times past 2040-02-06 06:28 are assumed to be invalid,
+ * matching the MacOS behavior.
+ */
+ if (ut > 2082844800U + UINT_MAX)
+ ut = 0;
+
+ return ut;
+}
+
+static inline __be32 __hfsp_ut2mt(time64_t ut)
+{
+ /*
+ * MacOS wraps "invalid" times after 2040 when writing back, so
+ * let's do the same here.
+ */
+ return cpu_to_be32(lower_32_bits(ut + 2082844800U));
+}
/* compatibility */
#define hfsp_mt2ut(t) (struct timespec){ .tv_sec = __hfsp_mt2ut(t) }
--
2.9.0
The ohci driver uses the get_seconds() function to implement the 32-bit
CSR_BUS_TIME register. This was added in 2010 commit a48777e03ad5
("firewire: add CSR BUS_TIME support").
As get_seconds() returns a 32-bit value (on 32-bit architectures), it
seems like a good fit for that register, but it is also deprecated because
of the y2038/y2106 overflow problem, and should be replaced throughout
the kernel with either ktime_get_real_seconds() or ktime_get_seconds().
I'm using the latter here, which uses monotonic time. This has the
advantage of behaving better during concurrent settimeofday() updates
or leap second adjustments and won't overflow a 32-bit integer, but
the downside of using CLOCK_MONOTONIC instead of CLOCK_REALTIME is
that the observed values are not related to external clocks.
If we instead need UTC but can live with clock jumps or overflows,
then we should use ktime_get_real_seconds() instead, retaining the
existing behavior.
Reviewed-by: Clemens Ladisch <clemens(a)ladisch.de>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
I notice that Stefan Richter has not been active on the mailing lists
since February 2018.
Andrew, could you pick it up in the meantime?
---
drivers/firewire/ohci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 45c048751f3b..5125841ea338 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -1765,7 +1765,7 @@ static u32 update_bus_time(struct fw_ohci *ohci)
if (unlikely(!ohci->bus_time_running)) {
reg_write(ohci, OHCI1394_IntMaskSet, OHCI1394_cycle64Seconds);
- ohci->bus_time = (lower_32_bits(get_seconds()) & ~0x7f) |
+ ohci->bus_time = (lower_32_bits(ktime_get_seconds()) & ~0x7f) |
(cycle_time_seconds & 0x40);
ohci->bus_time_running = true;
}
--
2.9.0
As Mathieu pointed out, my conversion to time64_t was incorrect and resulted
in negative times to be read from the RTC. The problem is that during the
conversion from a byte array to a time64_t, the 'unsigned char' variable
holding the top byte gets turned into a negative signed 32-bit integer
before being assigned to the 64-bit variable for any times after 1972.
This changes the logic to cast to an unsigned 32-bit number first for
the Macintosh time and then convert that to the Unix time, which then gives
us a time in the documented 1904..2040 year range. I decided not to use
the longer 1970..2106 range that other drivers use, for consistency with
the literal interpretation of the register, but that could be easily
changed if we decide we want to support any Mac after 2040.
Just to be on the safe side, I'm also adding a WARN_ON that will trigger
if either the year 2040 has come and is observed by this driver, or we
run into an RTC that got set back to a pre-1970 date for some reason
(the two are indistinguishable).
For the RTC write functions, Andreas found another problem: both
pmu_request() and cuda_request() are varargs functions, so changing
the type of the arguments passed into them from 32 bit to 64 bit
breaks the API for the set_rtc_time functions. This changes it
back to 32 bits.
The same code exists in arch/m68k/ and is patched in an identical way now
in a separate patch.
Fixes: 5bfd643583b2 ("powerpc: use time64_t in read_persistent_clock")
Reported-by: Mathieu Malaterre <malat(a)debian.org>
Reported-by: Andreas Schwab <schwab(a)linux-m68k.org>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
arch/powerpc/platforms/powermac/time.c | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/time.c b/arch/powerpc/platforms/powermac/time.c
index 7c968e46736f..12e6e4d30602 100644
--- a/arch/powerpc/platforms/powermac/time.c
+++ b/arch/powerpc/platforms/powermac/time.c
@@ -42,7 +42,11 @@
#define DBG(x...)
#endif
-/* Apparently the RTC stores seconds since 1 Jan 1904 */
+/*
+ * Offset between Unix time (1970-based) and Mac time (1904-based). Cuda and PMU
+ * times wrap in 2040. If we need to handle later times, the read_time functions
+ * need to be changed to interpret wrapped times as post-2040.
+ */
#define RTC_OFFSET 2082844800
/*
@@ -97,8 +101,11 @@ static time64_t cuda_get_time(void)
if (req.reply_len != 7)
printk(KERN_ERR "cuda_get_time: got %d byte reply\n",
req.reply_len);
- now = (req.reply[3] << 24) + (req.reply[4] << 16)
- + (req.reply[5] << 8) + req.reply[6];
+ now = (u32)((req.reply[3] << 24) + (req.reply[4] << 16) +
+ (req.reply[5] << 8) + req.reply[6]);
+ /* it's either after year 2040, or the RTC has gone backwards */
+ WARN_ON(now < RTC_OFFSET);
+
return now - RTC_OFFSET;
}
@@ -106,10 +113,10 @@ static time64_t cuda_get_time(void)
static int cuda_set_rtc_time(struct rtc_time *tm)
{
- time64_t nowtime;
+ u32 nowtime;
struct adb_request req;
- nowtime = rtc_tm_to_time64(tm) + RTC_OFFSET;
+ nowtime = lower_32_bits(rtc_tm_to_time64(tm) + RTC_OFFSET);
if (cuda_request(&req, NULL, 6, CUDA_PACKET, CUDA_SET_TIME,
nowtime >> 24, nowtime >> 16, nowtime >> 8,
nowtime) < 0)
@@ -140,8 +147,12 @@ static time64_t pmu_get_time(void)
if (req.reply_len != 4)
printk(KERN_ERR "pmu_get_time: got %d byte reply from PMU\n",
req.reply_len);
- now = (req.reply[0] << 24) + (req.reply[1] << 16)
- + (req.reply[2] << 8) + req.reply[3];
+ now = (u32)((req.reply[0] << 24) + (req.reply[1] << 16) +
+ (req.reply[2] << 8) + req.reply[3]);
+
+ /* it's either after year 2040, or the RTC has gone backwards */
+ WARN_ON(now < RTC_OFFSET);
+
return now - RTC_OFFSET;
}
@@ -149,10 +160,10 @@ static time64_t pmu_get_time(void)
static int pmu_set_rtc_time(struct rtc_time *tm)
{
- time64_t nowtime;
+ u32 nowtime;
struct adb_request req;
- nowtime = rtc_tm_to_time64(tm) + RTC_OFFSET;
+ nowtime = lower_32_bits(rtc_tm_to_time64(tm) + RTC_OFFSET);
if (pmu_request(&req, NULL, 5, PMU_SET_RTC, nowtime >> 24,
nowtime >> 16, nowtime >> 8, nowtime) < 0)
return -ENXIO;
--
2.9.0
While working on extended rand for last_error/first_error timestamps,
I noticed that the endianess is wrong, we access the little-endian
fields in struct ext4_super_block as native-endian when we print them.
This adds a special case in ext4_attr_show() and ext4_attr_store()
to byteswap the superblock fields if needed.
In older kernels, this code was part of super.c, it got moved to sysfs.c
in linux-4.4.
Cc: stable(a)vger.kernel.org
Fixes: 52c198c6820f ("ext4: add sysfs entry showing whether the fs contains errors")
Reviewed-by: Andreas Dilger <adilger(a)dilger.ca>
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
---
fs/ext4/sysfs.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
index f34da0bb8f17..b970a200f20c 100644
--- a/fs/ext4/sysfs.c
+++ b/fs/ext4/sysfs.c
@@ -274,8 +274,12 @@ static ssize_t ext4_attr_show(struct kobject *kobj,
case attr_pointer_ui:
if (!ptr)
return 0;
- return snprintf(buf, PAGE_SIZE, "%u\n",
- *((unsigned int *) ptr));
+ if (a->attr_ptr == ptr_ext4_super_block_offset)
+ return snprintf(buf, PAGE_SIZE, "%u\n",
+ le32_to_cpup(ptr));
+ else
+ return snprintf(buf, PAGE_SIZE, "%u\n",
+ *((unsigned int *) ptr));
case attr_pointer_atomic:
if (!ptr)
return 0;
@@ -308,7 +312,10 @@ static ssize_t ext4_attr_store(struct kobject *kobj,
ret = kstrtoul(skip_spaces(buf), 0, &t);
if (ret)
return ret;
- *((unsigned int *) ptr) = t;
+ if (a->attr_ptr == ptr_ext4_super_block_offset)
+ *((__le32 *) ptr) = cpu_to_le32(t);
+ else
+ *((unsigned int *) ptr) = t;
return len;
case attr_inode_readahead:
return inode_readahead_blks_store(sbi, buf, len);
--
2.9.0