All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
	ink@jurassic.park.msu.ru, mattst88@gmail.com,
	linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, tony.luck@intel.com, fenghua.yu@intel.com,
	geert@linux-m68k.org, monstr@monstr.eu, paul.burton@mips.com,
	deller@gmx.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	dalias@libc.org, davem@davemloft.net, luto@kernel.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, jcmvbkbc@gmail.com, firoz.khan@linaro.org,
	ebiederm@xmission.com, deepa.kernel@gmail.com,
	linux@dominikbrodowski.net, akpm@linux-foundation.org,
	dave@stgolabs.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.orgl
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 03:59:41 +0000	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>,
	y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
	ink@jurassic.park.msu.ru, mattst88@gmail.com,
	linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, tony.luck@intel.com, fenghua.yu@intel.com,
	geert@linux-m68k.org, monstr@monstr.eu, paul.burton@mips.com,
	deller@gmx.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	dalias@libc.org, davem@davemloft.net, luto@kernel.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, jcmvbkbc@gmail.com, firoz.khan@linaro.org,
	ebiederm@xmission.com, deepa.kernel@gmail.com,
	linux@dominikbrodowski.net, akpm@linux-foundation.org,
	dave@stgolabs.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 14:59:41 +1100	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
	ink@jurassic.park.msu.ru, mattst88@gmail.com,
	linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, tony.luck@intel.com, fenghua.yu@intel.com,
	geert@linux-m68k.org, monstr@monstr.eu, paul.burton@mips.com,
	deller@gmx.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	dalias@libc.org, davem@davemloft.net, luto@kernel.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, jcmvbkbc@gmail.com, firoz.khan@linaro.org,
	ebiederm@xmission.com, deepa.kernel@gmail.com,
	linux@dominikbrodowski.net, akpm@linux-foundation.org,
	dave@stgolabs.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.orgl
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 14:59:41 +1100	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>,
	y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: dalias@libc.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, catalin.marinas@arm.com,
	will.deacon@arm.com, linux@dominikbrodowski.net,
	jcmvbkbc@gmail.com, deepa.kernel@gmail.com, hpa@zytor.com,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	dave@stgolabs.net, deller@gmx.de, x86@kernel.org,
	linux@armlinux.org.uk, mingo@redhat.com, geert@linux-m68k.org,
	firoz.khan@linaro.org, mattst88@gmail.com, fenghua.yu@intel.com,
	Arnd Bergmann <arnd@arndb.de>,
	heiko.carstens@de.ibm.com, linux-m68k@lists.linux-m68k.org,
	ink@jurassic.park.msu.ru, luto@kernel.org, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, monstr@monstr.eu,
	tony.luck@intel.com, linux-parisc@vger.kernel.org,
	linux-mips@vger.kernel.org, paul.burton@mips.com,
	ebiederm@xmission.com, linux-alpha@vger.kernel.org,
	schwidefsky@de.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 14:59:41 +1100	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>,
	y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: dalias@libc.org, linux-ia64@vger.kernel.org,
	linux-sh@vger.kernel.org, catalin.marinas@arm.com,
	will.deacon@arm.com, linux@dominikbrodowski.net,
	jcmvbkbc@gmail.com, deepa.kernel@gmail.com, hpa@zytor.com,
	sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
	dave@stgolabs.net, deller@gmx.de, x86@kernel.org,
	linux@armlinux.org.uk, mingo@redhat.com, geert@linux-m68k.org,
	firoz.khan@linaro.org, mattst88@gmail.com, fenghua.yu@intel.com,
	Arnd Bergmann <arnd@arndb.de>,
	heiko.carstens@de.ibm.com, linux-m68k@lists.linux-m68k.org,
	ink@jurassic.park.msu.ru, luto@kernel.org, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org, monstr@monstr.eu,
	tony.luck@intel.com, linux-parisc@vger.kernel.org,
	linux-mips@vger.kernel.org, paul.burton@mips.com,
	ebiederm@xmission.com, linux-alpha@vger.kernel.org,
	schwidefsky@de.ibm.com, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org, davem@davemloft.net
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 14:59:41 +1100	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <mpe@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>,
	y2038@lists.linaro.org, linux-api@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>,
	ink@jurassic.park.msu.ru, mattst88@gmail.com,
	linux@armlinux.org.uk, catalin.marinas@arm.com,
	will.deacon@arm.com, tony.luck@intel.com, fenghua.yu@intel.com,
	geert@linux-m68k.org, monstr@monstr.eu, paul.burton@mips.com,
	deller@gmx.de, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	dalias@libc.org, davem@davemloft.net, luto@kernel.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	x86@kernel.org, jcmvbkbc@gmail.com, firoz.khan@linaro.org,
	ebiederm@xmission.com, deepa.kernel@gmail.com,
	linux@dominikbrodowski.net, akpm@linux-foundation.org,
	dave@stgolabs.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, l
Subject: Re: [PATCH 14/15] arch: add split IPC system calls where needed
Date: Mon, 14 Jan 2019 14:59:41 +1100	[thread overview]
Message-ID: <87pnsz28k2.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20190110162435.309262-15-arnd@arndb.de>

Hi Arnd,

Arnd Bergmann <arnd@arndb.de> writes:
> The IPC system call handling is highly inconsistent across architectures,
> some use sys_ipc, some use separate calls, and some use both.  We also
> have some architectures that require passing IPC_64 in the flags, and
> others that set it implicitly.
>
> For the additon of a y2083 safe semtimedop() system call, I chose to only
> support the separate entry points, but that requires first supporting
> the regular ones with their own syscall numbers.
>
> The IPC_64 is now implied by the new semctl/shmctl/msgctl system
> calls even on the architectures that require passing it with the ipc()
> multiplexer.
>
> I'm not adding the new semtimedop() or semop() on 32-bit architectures,
> those will get implemented using the new semtimedop_time64() version
> that gets added along with the other time64 calls.
> Three 64-bit architectures (powerpc, s390 and sparc) get semtimedop().
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> One aspect here that might be a bit controversial is the use of
> the same system call numbers across all architectures, synchronizing
> all of them with the x86-32 numbers. With the new syscall.tbl
> files, I hope we can just keep doing that in the future, and no
> longer require the architecture maintainers to assign a number.
>
> This is mainly useful for implementers of the C libraries: if
> we can add future system calls everywhere at the same time, using
> a particular version of the kernel headers also guarantees that
> the system call number macro is visible.
> ---
>  arch/m68k/kernel/syscalls/syscall.tbl     | 11 +++++++++++
>  arch/mips/kernel/syscalls/syscall_o32.tbl | 11 +++++++++++
>  arch/powerpc/kernel/syscalls/syscall.tbl  | 12 ++++++++++++

I have some changes I'd like to make to our syscall table that will
clash with this.

I'll try and send them today.

> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl
> index db3bbb8744af..1bffab54ff35 100644
> --- a/arch/powerpc/kernel/syscalls/syscall.tbl
> +++ b/arch/powerpc/kernel/syscalls/syscall.tbl
> @@ -425,3 +425,15 @@
>  386	nospu	pkey_mprotect			sys_pkey_mprotect
>  387	nospu	rseq				sys_rseq
>  388	nospu	io_pgetevents			sys_io_pgetevents		compat_sys_io_pgetevents
> +# room for arch specific syscalls
> +392	64	semtimedop			sys_semtimedop
> +393	common	semget				sys_semget
> +394	common	semctl				sys_semctl			compat_sys_semctl
> +395	common	shmget				sys_shmget
> +396	common	shmctl				sys_shmctl			compat_sys_shmctl
> +397	common	shmat				sys_shmat			compat_sys_shmat
> +398	common	shmdt				sys_shmdt
> +399	common	msgget				sys_msgget
> +400	common	msgsnd				sys_msgsnd			compat_sys_msgsnd
> +401	common	msgrcv				sys_msgrcv			compat_sys_msgrcv
> +402	common	msgctl				sys_msgctl			compat_sys_msgctl

We already have a gap at 366-377 from when we tried to add the split IPC
calls a few years back.

I guess I don't mind leaving that gap and using the common numbers as
you've done here.

But it would be good to add a comment pointing out that we have room
at 366 for more arch specific syscalls as well.

cheers

  parent reply	other threads:[~2019-01-14  3:59 UTC|newest]

Thread overview: 245+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10 16:24 [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038 Arnd Bergmann
2019-01-10 16:24 ` Arnd Bergmann
2019-01-10 16:24 ` Arnd Bergmann
2019-01-10 16:24 ` Arnd Bergmann
2019-01-10 16:24 ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 01/15] ia64: add __NR_umount2 definition Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 02/15] ia64: add statx and io_pgetevents syscalls Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 03/15] ia64: assign syscall numbers for perf and seccomp Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 04/15] alpha: wire up io_pgetevents system call Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 05/15] alpha: update syscall macro definitions Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 06/15] ARM: add migrate_pages() system call Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:32   ` Will Deacon
2019-01-10 16:32     ` Will Deacon
2019-01-10 16:32     ` Will Deacon
2019-01-10 16:32     ` Will Deacon
2019-01-10 16:32     ` Will Deacon
2019-01-10 17:11     ` Arnd Bergmann
2019-01-10 17:11       ` Arnd Bergmann
2019-01-10 17:11       ` Arnd Bergmann
2019-01-10 17:11       ` Arnd Bergmann
2019-01-10 17:11       ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 07/15] ARM: add kexec_file_load system call number Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:39   ` Will Deacon
2019-01-10 16:39     ` Will Deacon
2019-01-10 16:39     ` Will Deacon
2019-01-10 16:39     ` Will Deacon
2019-01-10 16:39     ` Will Deacon
2019-01-10 17:14     ` Arnd Bergmann
2019-01-10 17:14       ` Arnd Bergmann
2019-01-10 17:14       ` Arnd Bergmann
2019-01-10 17:14       ` Arnd Bergmann
2019-01-10 17:14       ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 08/15] m68k: assign syscall number for seccomp Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 09/15] sh: remove duplicate unistd_32.h file Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 10/15] sh: add statx system call Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 11/15] mips: fix n32 compat_ipc_parse_version Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 19:39   ` Paul Burton
2019-01-10 19:39     ` Paul Burton
2019-01-10 19:39     ` Paul Burton
2019-01-10 19:39     ` Paul Burton
2019-01-10 23:04     ` Arnd Bergmann
2019-01-10 23:04       ` Arnd Bergmann
2019-01-10 23:04       ` Arnd Bergmann
2019-01-10 23:04       ` Arnd Bergmann
2019-01-10 23:04       ` Arnd Bergmann
2019-01-11 19:25   ` Paul Burton
2019-01-11 19:25     ` Paul Burton
2019-01-11 19:25     ` Paul Burton
2019-01-11 19:25     ` Paul Burton
2019-01-10 16:24 ` [PATCH 12/15] sparc64: fix sparc_ipc type conversion Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 13/15] ipc: rename old-style shmctl/semctl/msgctl syscalls Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24 ` [PATCH 14/15] arch: add split IPC system calls where needed Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 20:32   ` Heiko Carstens
2019-01-10 20:32     ` Heiko Carstens
2019-01-10 20:32     ` Heiko Carstens
2019-01-10 20:32     ` Heiko Carstens
2019-01-10 20:32     ` Heiko Carstens
2019-01-11 17:33     ` Arnd Bergmann
2019-01-11 17:33       ` Arnd Bergmann
2019-01-11 17:33       ` Arnd Bergmann
2019-01-11 17:33       ` Arnd Bergmann
2019-01-11 17:33       ` Arnd Bergmann
2019-01-14  3:40   ` Michael Ellerman
2019-01-14  3:40     ` Michael Ellerman
2019-01-14  3:40     ` Michael Ellerman
2019-01-14  3:40     ` Michael Ellerman
2019-01-14  3:40     ` Michael Ellerman
2019-01-14  3:40     ` Michael Ellerman
2019-01-14  3:59   ` Michael Ellerman [this message]
2019-01-14  3:59     ` Michael Ellerman
2019-01-14  3:59     ` Michael Ellerman
2019-01-14  3:59     ` Michael Ellerman
2019-01-14  3:59     ` Michael Ellerman
2019-01-14  3:59     ` Michael Ellerman
2019-01-14  9:58     ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-14  9:58       ` Michael Ellerman
2019-01-15 15:01     ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:01       ` Arnd Bergmann
2019-01-15 15:18       ` Arnd Bergmann
2019-01-15 15:18         ` Arnd Bergmann
2019-01-15 15:18         ` Arnd Bergmann
2019-01-15 15:18         ` Arnd Bergmann
2019-01-15 15:18         ` Arnd Bergmann
2019-01-15 16:35         ` Geert Uytterhoeven
2019-01-15 16:35           ` Geert Uytterhoeven
2019-01-15 16:35           ` Geert Uytterhoeven
2019-01-15 16:35           ` Geert Uytterhoeven
2019-01-15 16:35           ` Geert Uytterhoeven
2019-01-15 16:35           ` Geert Uytterhoeven
2019-01-15 21:24           ` Arnd Bergmann
2019-01-15 21:24             ` Arnd Bergmann
2019-01-15 21:24             ` Arnd Bergmann
2019-01-15 21:24             ` Arnd Bergmann
2019-01-15 21:24             ` Arnd Bergmann
2019-01-16  0:09         ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:09           ` Michael Ellerman
2019-01-16  0:10       ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-16  0:10         ` Michael Ellerman
2019-01-10 16:24 ` [PATCH 15/15] arch: add pkey and rseq syscall numbers everywhere Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 16:24   ` Arnd Bergmann
2019-01-10 20:36   ` Heiko Carstens
2019-01-10 20:36     ` Heiko Carstens
2019-01-10 20:36     ` Heiko Carstens
2019-01-10 20:36     ` Heiko Carstens
2019-01-10 20:36     ` Heiko Carstens
2019-01-11 17:30     ` Arnd Bergmann
2019-01-11 17:30       ` Arnd Bergmann
2019-01-11 17:30       ` Arnd Bergmann
2019-01-11 17:30       ` Arnd Bergmann
2019-01-11 17:30       ` Arnd Bergmann
2019-01-14  8:31       ` Heiko Carstens
2019-01-14  8:31         ` Heiko Carstens
2019-01-14  8:31         ` Heiko Carstens
2019-01-14  8:31         ` Heiko Carstens
2019-01-14  8:31         ` Heiko Carstens
2019-01-15 11:52   ` Russell King - ARM Linux admin
2019-01-15 11:52     ` Russell King - ARM Linux admin
2019-01-15 11:52     ` Russell King - ARM Linux admin
2019-01-15 11:52     ` Russell King - ARM Linux admin
2019-01-15 11:52     ` Russell King - ARM Linux admin
2019-01-15 14:47     ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-15 14:47       ` Arnd Bergmann
2019-01-10 16:59 ` [PATCH 00/15] arch: synchronize syscall tables in preparation for y2038 Geert Uytterhoeven
2019-01-10 16:59   ` Geert Uytterhoeven
2019-01-10 16:59   ` Geert Uytterhoeven
2019-01-10 16:59   ` Geert Uytterhoeven
2019-01-10 16:59   ` Geert Uytterhoeven
2019-01-10 17:06   ` Arnd Bergmann
2019-01-10 17:06     ` Arnd Bergmann
2019-01-10 17:06     ` Arnd Bergmann
2019-01-10 17:06     ` Arnd Bergmann
2019-01-10 17:06     ` Arnd Bergmann
2019-01-10 18:11     ` Geert Uytterhoeven
2019-01-10 18:11       ` Geert Uytterhoeven
2019-01-10 18:11       ` Geert Uytterhoeven
2019-01-10 18:11       ` Geert Uytterhoeven
2019-01-10 18:11       ` Geert Uytterhoeven
2019-01-10 22:43       ` Arnd Bergmann
2019-01-10 22:43         ` Arnd Bergmann
2019-01-10 22:43         ` Arnd Bergmann
2019-01-10 22:43         ` Arnd Bergmann
2019-01-10 22:43         ` Arnd Bergmann
2019-01-11  8:07         ` Geert Uytterhoeven
2019-01-11  8:07           ` Geert Uytterhoeven
2019-01-11  8:07           ` Geert Uytterhoeven
2019-01-11  8:07           ` Geert Uytterhoeven
2019-01-11  8:07           ` Geert Uytterhoeven
2019-01-10 18:10 ` Joseph Myers
2019-01-10 18:10   ` Joseph Myers
2019-01-10 18:10   ` Joseph Myers
2019-01-10 18:10   ` Joseph Myers
2019-01-10 22:42   ` Arnd Bergmann
2019-01-10 22:42     ` Arnd Bergmann
2019-01-10 22:42     ` Arnd Bergmann
2019-01-10 22:42     ` Arnd Bergmann
2019-01-10 22:42     ` Arnd Bergmann
2019-01-10 23:14     ` Michael Cree
2019-01-10 23:14       ` Michael Cree
2019-01-10 23:14       ` Michael Cree
2019-01-10 23:14       ` Michael Cree
2019-01-10 23:14       ` Michael Cree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnsz28k2.fsf@concordia.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=deepa.kernel@gmail.com \
    --cc=deller@gmx.de \
    --cc=ebiederm@xmission.com \
    --cc=fenghua.yu@intel.com \
    --cc=firoz.khan@linaro.org \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.orgl \
    --cc=linux@armlinux.org.uk \
    --cc=linux@dominikbrodowski.net \
    --cc=luto@kernel.org \
    --cc=mattst88@gmail.com \
    --cc=mingo@redhat.com \
    --cc=monstr@monstr.eu \
    --cc=paul.burton@mips.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.