| Message ID | 20190110162435.309262-15-arnd@arndb.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arch: synchronize syscall tables in preparation for y2038 | expand |
On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote: > 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. > diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl > index 022fc099b628..428cf512a757 100644 > --- a/arch/s390/kernel/syscalls/syscall.tbl > +++ b/arch/s390/kernel/syscalls/syscall.tbl > @@ -391,3 +391,15 @@ > 381 common kexec_file_load sys_kexec_file_load compat_sys_kexec_file_load > 382 common io_pgetevents sys_io_pgetevents compat_sys_io_pgetevents > 383 common rseq sys_rseq compat_sys_rseq > +# room for arch specific syscalls > +392 64 semtimedop sys_semtimedop - > +393 common semget sys_semget sys_semget ... > +395 common shmget sys_shmget sys_shmget ... > +398 common shmdt sys_shmdt sys_shmdt > +399 common msgget sys_msgget sys_msgget These four need compat system call wrappers, unfortunately... (well, actually only shmget and shmdt require them, but let's add them for all four). See arch/s390/kernel/compat_wrapper.c I'm afraid this compat special handling will be even more annoying in the future, since s390 will be the only architecture which requires this special handling. _Maybe_ it would make sense to automatically generate a weak compat system call wrapper for s390 with the SYSCALL_DEFINE macros, but that probably won't work in all cases.
On Thu, Jan 10, 2019 at 9:33 PM Heiko Carstens <heiko.carstens@de.ibm.com> wrote: > On Thu, Jan 10, 2019 at 05:24:34PM +0100, Arnd Bergmann wrote: > > diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl > > index 022fc099b628..428cf512a757 100644 > > --- a/arch/s390/kernel/syscalls/syscall.tbl > > +++ b/arch/s390/kernel/syscalls/syscall.tbl > > @@ -391,3 +391,15 @@ > > 381 common kexec_file_load sys_kexec_file_load compat_sys_kexec_file_load > > 382 common io_pgetevents sys_io_pgetevents compat_sys_io_pgetevents > > 383 common rseq sys_rseq compat_sys_rseq > > +# room for arch specific syscalls > > +392 64 semtimedop sys_semtimedop - > > +393 common semget sys_semget sys_semget > ... > > +395 common shmget sys_shmget sys_shmget > ... > > +398 common shmdt sys_shmdt sys_shmdt > > +399 common msgget sys_msgget sys_msgget > > These four need compat system call wrappers, unfortunately... (well, > actually only shmget and shmdt require them, but let's add them for > all four). See arch/s390/kernel/compat_wrapper.c > > I'm afraid this compat special handling will be even more annoying in > the future, since s390 will be the only architecture which requires > this special handling. > > _Maybe_ it would make sense to automatically generate a weak compat > system call wrapper for s390 with the SYSCALL_DEFINE macros, but that > probably won't work in all cases. For some reason I was under the impression that s390 already did that. However, it seems that x86 does, so I'll try to convert the x86 version for s390, and see if I can get rid of all the wrappers that way. It would certainly be safer to have the wrappers always present, especially if we expect future system calls to be added to the s390 table by whoever implements the syscall itself. Arnd
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. But would be good to add a comment pointing out that we have room there for arch specific syscalls as well. cheers
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
Michael Ellerman <mpe@ellerman.id.au> writes: > 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. ... > > 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 Guess I sent that one twice. 🤦 cheers
On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > 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. Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be nice for me to have a branch based on 5.0-rc1 that I can put the other patches on top of. > > 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. Ah, I missed that. I've added this to my patch now: index 5c0936d862fc..2ddfba536d5f 100644 --- a/arch/powerpc/kernel/syscalls/syscall.tbl +++ b/arch/powerpc/kernel/syscalls/syscall.tbl @@ -460,6 +460,7 @@ 363 spu switch_endian sys_ni_syscall 364 common userfaultfd sys_userfaultfd 365 common membarrier sys_membarrier +# 366-377 originally left for IPC, now unused 378 nospu mlock2 sys_mlock2 379 nospu copy_file_range sys_copy_file_range 380 common preadv2 sys_preadv2 compat_sys_preadv2 Arnd
On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > > Arnd Bergmann <arnd@arndb.de> writes: > > > 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. > > Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be > nice for me to have a branch based on 5.0-rc1 that I can put > the other patches on top of. There is also another change that I considered: At the end of my series, we have a lot of entries like 245 32 clock_settime sys_clock_settime32 245 64 clock_settime sys_clock_settime 245 spu clock_settime sys_clock_settime which could be folded into 245 32 clock_settime sys_clock_settime32 245 spu64 clock_settime sys_clock_settime if we just add another option to the ABI field. Any thoughts on that? Arnd
Hi Arnd, On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > > > Arnd Bergmann <arnd@arndb.de> writes: > > > > 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. > > > > Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be > > nice for me to have a branch based on 5.0-rc1 that I can put > > the other patches on top of. > > There is also another change that I considered: > > At the end of my series, we have a lot of entries like > > 245 32 clock_settime sys_clock_settime32 > 245 64 clock_settime sys_clock_settime > 245 spu clock_settime sys_clock_settime > > which could be folded into > > 245 32 clock_settime sys_clock_settime32 > 245 spu64 clock_settime sys_clock_settime > > if we just add another option to the ABI field. Any thoughts on > that? So "spu64" would mean "spu + 64"? That makes it more difficult to read, and to grep. What about allowing multiple ABIs, separated by commas? So that line would become: 245 spu,64 clock_settime sys_clock_settime Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Jan 15, 2019 at 5:36 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Jan 15, 2019 at 4:19 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: > > > > Arnd Bergmann <arnd@arndb.de> writes: > > > > > 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. > > > > > > Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be > > > nice for me to have a branch based on 5.0-rc1 that I can put > > > the other patches on top of. > > > > There is also another change that I considered: > > > > At the end of my series, we have a lot of entries like > > > > 245 32 clock_settime sys_clock_settime32 > > 245 64 clock_settime sys_clock_settime > > 245 spu clock_settime sys_clock_settime > > > > which could be folded into > > > > 245 32 clock_settime sys_clock_settime32 > > 245 spu64 clock_settime sys_clock_settime > > > > if we just add another option to the ABI field. Any thoughts on > > that? > > So "spu64" would mean "spu + 64"? > That makes it more difficult to read, and to grep. > What about allowing multiple ABIs, separated by commas? > So that line would become: > > 245 spu,64 clock_settime sys_clock_settime I agree that would be a nice representation, but doing this would again require changing the script, which then in turn clashes with Firoz' patches to unify it under the scripts/ directory. Arnd
Arnd Bergmann <arnd@arndb.de> writes: > On Tue, Jan 15, 2019 at 4:01 PM Arnd Bergmann <arnd@arndb.de> wrote: >> >> On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: >> > Arnd Bergmann <arnd@arndb.de> writes: >> > > 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. >> >> Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be >> nice for me to have a branch based on 5.0-rc1 that I can put >> the other patches on top of. > > There is also another change that I considered: > > At the end of my series, we have a lot of entries like > > 245 32 clock_settime sys_clock_settime32 > 245 64 clock_settime sys_clock_settime > 245 spu clock_settime sys_clock_settime > > which could be folded into > > 245 32 clock_settime sys_clock_settime32 > 245 spu64 clock_settime sys_clock_settime > > if we just add another option to the ABI field. Any thoughts on > that? My series splits spu out into a separate field. So the above would be: 245 32 - clock_settime sys_clock_settime32 245 64 spu clock_settime sys_clock_settime cheers
Arnd Bergmann <arnd@arndb.de> writes: > On Mon, Jan 14, 2019 at 4:59 AM Michael Ellerman <mpe@ellerman.id.au> wrote: >> Arnd Bergmann <arnd@arndb.de> writes: >> > 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. > > Ok. Are those for 5.0 or 5.1? If they are intended for 5.0, it would be > nice for me to have a branch based on 5.0-rc1 that I can put > the other patches on top of. For 5.1. I can put them in a topic branch for you. >> > 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. > > Ah, I missed that. I've added this to my patch now: > > index 5c0936d862fc..2ddfba536d5f 100644 > --- a/arch/powerpc/kernel/syscalls/syscall.tbl > +++ b/arch/powerpc/kernel/syscalls/syscall.tbl > @@ -460,6 +460,7 @@ > 363 spu switch_endian sys_ni_syscall > 364 common userfaultfd sys_userfaultfd > 365 common membarrier sys_membarrier > +# 366-377 originally left for IPC, now unused > 378 nospu mlock2 sys_mlock2 > 379 nospu copy_file_range sys_copy_file_range > 380 common preadv2 sys_preadv2 > compat_sys_preadv2 Thanks. cheers
diff --git a/arch/m68k/kernel/syscalls/syscall.tbl b/arch/m68k/kernel/syscalls/syscall.tbl index 85779d6ef935..5354ba02eed2 100644 --- a/arch/m68k/kernel/syscalls/syscall.tbl +++ b/arch/m68k/kernel/syscalls/syscall.tbl @@ -388,3 +388,14 @@ 378 common pwritev2 sys_pwritev2 379 common statx sys_statx 380 common seccomp sys_seccomp +# room for arch specific calls +393 common semget sys_semget +394 common semctl sys_semctl +395 common shmget sys_shmget +396 common shmctl sys_shmctl +397 common shmat sys_shmat +398 common shmdt sys_shmdt +399 common msgget sys_msgget +400 common msgsnd sys_msgsnd +401 common msgrcv sys_msgrcv +402 common msgctl sys_msgctl diff --git a/arch/mips/kernel/syscalls/syscall_o32.tbl b/arch/mips/kernel/syscalls/syscall_o32.tbl index 3d5a47b80d2b..fa47ea8cc6ef 100644 --- a/arch/mips/kernel/syscalls/syscall_o32.tbl +++ b/arch/mips/kernel/syscalls/syscall_o32.tbl @@ -380,3 +380,14 @@ 366 o32 statx sys_statx 367 o32 rseq sys_rseq 368 o32 io_pgetevents sys_io_pgetevents compat_sys_io_pgetevents +# room for arch specific calls +393 o32 semget sys_semget +394 o32 semctl sys_semctl compat_sys_semctl +395 o32 shmget sys_shmget +396 o32 shmctl sys_shmctl compat_sys_shmctl +397 o32 shmat sys_shmat compat_sys_shmat +398 o32 shmdt sys_shmdt +399 o32 msgget sys_msgget +400 o32 msgsnd sys_msgsnd compat_sys_msgsnd +401 o32 msgrcv sys_msgrcv compat_sys_msgrcv +402 o32 msgctl sys_msgctl compat_sys_msgctl 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 diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl index 022fc099b628..428cf512a757 100644 --- a/arch/s390/kernel/syscalls/syscall.tbl +++ b/arch/s390/kernel/syscalls/syscall.tbl @@ -391,3 +391,15 @@ 381 common kexec_file_load sys_kexec_file_load compat_sys_kexec_file_load 382 common io_pgetevents sys_io_pgetevents compat_sys_io_pgetevents 383 common rseq sys_rseq compat_sys_rseq +# room for arch specific syscalls +392 64 semtimedop sys_semtimedop - +393 common semget sys_semget sys_semget +394 common semctl sys_semctl compat_sys_semctl +395 common shmget sys_shmget sys_shmget +396 common shmctl sys_shmctl compat_sys_shmctl +397 common shmat sys_shmat compat_sys_shmat +398 common shmdt sys_shmdt sys_shmdt +399 common msgget sys_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 diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl index a70db013dbc7..6d0b84e3ef2d 100644 --- a/arch/sh/kernel/syscalls/syscall.tbl +++ b/arch/sh/kernel/syscalls/syscall.tbl @@ -391,3 +391,14 @@ 381 common preadv2 sys_preadv2 382 common pwritev2 sys_pwritev2 383 common statx sys_statx +# room for arch specific syscalls +393 common semget sys_semget +394 common semctl sys_semctl +395 common shmget sys_shmget +396 common shmctl sys_shmctl +397 common shmat sys_shmat +398 common shmdt sys_shmdt +399 common msgget sys_msgget +400 common msgsnd sys_msgsnd +401 common msgrcv sys_msgrcv +402 common msgctl sys_msgctl diff --git a/arch/sparc/kernel/syscalls/syscall.tbl b/arch/sparc/kernel/syscalls/syscall.tbl index c8c77c05ea97..8c9580302422 100644 --- a/arch/sparc/kernel/syscalls/syscall.tbl +++ b/arch/sparc/kernel/syscalls/syscall.tbl @@ -407,3 +407,15 @@ 359 common pwritev2 sys_pwritev2 compat_sys_pwritev2 360 common statx sys_statx 361 common 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 diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index 3cf7b533b3d1..fef80b92eb7e 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -398,3 +398,14 @@ 384 i386 arch_prctl sys_arch_prctl __ia32_compat_sys_arch_prctl 385 i386 io_pgetevents sys_io_pgetevents __ia32_compat_sys_io_pgetevents 386 i386 rseq sys_rseq __ia32_sys_rseq +# room for arch specific syscalls +393 i386 semget sys_semget __ia32_sys_semget +394 i386 semctl sys_semctl __ia32_compat_sys_semctl +395 i386 shmget sys_shmget __ia32_sys_shmget +396 i386 shmctl sys_shmctl __ia32_compat_sys_shmctl +397 i386 shmat sys_shmat __ia32_compat_sys_shmat +398 i386 shmdt sys_shmdt __ia32_sys_shmdt +399 i386 msgget sys_msgget __ia32_sys_msgget +400 i386 msgsnd sys_msgsnd __ia32_compat_sys_msgsnd +401 i386 msgrcv sys_msgrcv __ia32_compat_sys_msgrcv +402 i386 msgctl sys_msgctl __ia32_compat_sys_msgctl
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 ++++++++++++ arch/s390/kernel/syscalls/syscall.tbl | 12 ++++++++++++ arch/sh/kernel/syscalls/syscall.tbl | 11 +++++++++++ arch/sparc/kernel/syscalls/syscall.tbl | 12 ++++++++++++ arch/x86/entry/syscalls/syscall_32.tbl | 11 +++++++++++ 7 files changed, 80 insertions(+) -- 2.20.0