Commit 5ac9efa3 authored Apr 09, 2018 by Dominik Brodowski Committed by Ingo Molnar Apr 09, 2018

syscalls/core, syscalls/x86: Clean up compat syscall stub naming convention



Tidy the naming convention for compat syscall subs. Hints which describe
the purpose of the stub go in front and receive a double underscore to
denote that they are generated on-the-fly by the COMPAT_SYSCALL_DEFINEx()
macro.

For the generic case, this means:

t            kernel_waitid	# common C function (see kernel/exit.c)

    __do_compat_sys_waitid	# inlined helper doing the actual work
				# (takes original parameters as declared)

T   __se_compat_sys_waitid	# sign-extending C function calling inlined
				# helper (takes parameters of type long,
				# casts them to unsigned long and then to
				# the declared type)

T        compat_sys_waitid      # alias to __se_compat_sys_waitid()
				# (taking parameters as declared), to
				# be included in syscall table

For x86, the naming is as follows:

t            kernel_waitid	# common C function (see kernel/exit.c)

    __do_compat_sys_waitid	# inlined helper doing the actual work
				# (takes original parameters as declared)

t   __se_compat_sys_waitid      # sign-extending C function calling inlined
				# helper (takes parameters of type long,
				# casts them to unsigned long and then to
				# the declared type)

T __ia32_compat_sys_waitid	# IA32_EMULATION 32-bit-ptregs -> C stub,
				# calls __se_compat_sys_waitid(); to be
				# included in syscall table

T  __x32_compat_sys_waitid	# x32 64-bit-ptregs -> C stub, calls
				# __se_compat_sys_waitid(); to be included
				# in syscall table

If only one of IA32_EMULATION and x32 is enabled, __se_compat_sys_waitid()
may be inlined into the stub __{ia32,x32}_compat_sys_waitid().

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180409105145.5364-3-linux@dominikbrodowski.net


Signed-off-by: Ingo Molnar <mingo@kernel.org>

parent e145242e

Documentation/process/adding-syscalls.rst

+2 −2

Original line number	Original line	Diff line number	Diff line
	@@ -360,7 +360,7 @@ First, the entry in ``arch/x86/entry/syscalls/syscall_32.tbl`` gets an extra
	column to indicate that a 32-bit userspace program running on a 64-bit kernel		column to indicate that a 32-bit userspace program running on a 64-bit kernel
	should hit the compat entry point::		should hit the compat entry point::

	380 i386 xyzzy sys_xyzzy compat_sys_xyzzy		380 i386 xyzzy sys_xyzzy __ia32_compat_sys_xyzzy

	Second, you need to figure out what should happen for the x32 ABI version of		Second, you need to figure out what should happen for the x32 ABI version of
	the new system call. There's a choice here: the layout of the arguments		the new system call. There's a choice here: the layout of the arguments
	@@ -373,7 +373,7 @@ the compatibility wrapper::

	333 64 xyzzy sys_xyzzy		333 64 xyzzy sys_xyzzy
	...		...
	555 x32 xyzzy compat_sys_xyzzy		555 x32 xyzzy __x32_compat_sys_xyzzy

	If no pointers are involved, then it is preferable to re-use the 64-bit system		If no pointers are involved, then it is preferable to re-use the 64-bit system
	call for the x32 ABI (and consequently the entry in		call for the x32 ABI (and consequently the entry in