Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote: > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann Acked-by: Catalin Marinas (as long as compat follows the arm32 syscall numbers)
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Mon, Jan 21, 2019 at 6:08 PM Arnd Bergmann wrote: > On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven > wrote: > > Regardless, I'm wondering what to do with the holes marked "room for > > arch specific calls". > > When is a syscall really arch-specific, and can it be added there, and > > when does it turn out (later) that it isn't, breaking the > > synchronization again? > > We've had a bit of that already, with cacheflush(), which exists on > a couple of architectures, including some that use the first > 'arch specific' slot (244) of the asm-generic table. I think this > will be rare enough that we can figure out a solution when we > get there. > > > The pkey syscalls may be a bad example, as AFAIU they can be implemented > > on some architectures, but not on some others. Still, I had skipped them > > when adding new syscalls to m68k. > > > > Perhaps we should get rid of the notion of "arch-specific syscalls", and > > reserve a slot everywhere anyway? > > I don't mind calling the hole something else if that helps. Out of > principle I would already assume that anything we add for x86 > or the generic table should be added everywhere, but we can > make it broader than that. Applying this fixup below, ARnd diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index d9c2d2eea044..955ab6a3b61f 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -398,7 +398,7 @@ 384i386arch_prctl sys_arch_prctl __ia32_compat_sys_arch_prctl 385i386io_pgetevents sys_io_pgetevents_time32 __ia32_compat_sys_io_pgetevents 386i386rseqsys_rseq __ia32_sys_rseq -# room for arch specific syscalls +# don't use numbers 387 through 392, add new calls at the end 393i386semget sys_semget __ia32_sys_semget 394i386semctl sys_semctl __ia32_compat_sys_semctl 395i386shmget sys_shmget __ia32_sys_shmget diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index 43a622aec07e..2ae92fddb6d5 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -343,6 +343,8 @@ 332common statx __x64_sys_statx 333common io_pgetevents __x64_sys_io_pgetevents 334common rseq__x64_sys_rseq +# don't use numbers 387 through 423, add new calls after the last +# 'common' entry # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index 53831e4a4c86..acf9a07ab2ff 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -740,7 +740,7 @@ __SC_COMP_3264(__NR_io_pgetevents, sys_io_pgetevents_time32, sys_io_pgetevents, __SYSCALL(__NR_rseq, sys_rseq) #define __NR_kexec_file_load 294 __SYSCALL(__NR_kexec_file_load, sys_kexec_file_load) -/* 295 through 402 are unassigned to sync up with generic numbers */ +/* 295 through 402 are unassigned to sync up with generic numbers, don't use */ #if __BITS_PER_LONG == 32 #define __NR_clock_gettime64 403 __SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven wrote: > On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin > wrote: > > On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote: > > > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > > > > > Can we perhaps just start the consistent numbers above 547 or maybe > > > block out 512..547 in the new regime? > > > > I don't think you gain much with that kind of scheme - it won't take > > very long before an architecture misses having a syscall added, and > > then someone else adds their own. Been there with ARM - I was keeping > > the syscall table in the same order as x86 for new syscalls, but now > > Same for m68k, and probably other architectures. > > > that others have been adding syscalls to the table since I converted > > ARM to the tabular form, that's now gone out the window. > > > > So, I think it's completely pointless to do what you're suggesting. > > We'll just end up with a big hole in the middle of the syscall table > > and then revert back to random numbering of syscalls thereafter again. > > I believe the plan is to add future syscalls for all architectures in a > single commit, to keep everything in sync. Yes, that is the idea. This was not realistic before, since each one of the old architectures had its own way of describing the system call tables, and many needed a different set of quirks. Since (almost) everything is now converted to the syscall.tbl format, we have removed all obsolete architectures, and a lot of the quirks (x32, spu, s390-31) won't matter as much in the future, I think it is now possible to do it. We could even extend scripts/checksyscalls.sh to warn if a new syscall above 423 is not added to all 16 tables at the same time. > Regardless, I'm wondering what to do with the holes marked "room for > arch specific calls". > When is a syscall really arch-specific, and can it be added there, and > when does it turn out (later) that it isn't, breaking the > synchronization again? We've had a bit of that already, with cacheflush(), which exists on a couple of architectures, including some that use the first 'arch specific' slot (244) of the asm-generic table. I think this will be rare enough that we can figure out a solution when we get there. > The pkey syscalls may be a bad example, as AFAIU they can be implemented > on some architectures, but not on some others. Still, I had skipped them > when adding new syscalls to m68k. > > Perhaps we should get rid of the notion of "arch-specific syscalls", and > reserve a slot everywhere anyway? I don't mind calling the hole something else if that helps. Out of principle I would already assume that anything we add for x86 or the generic table should be added everywhere, but we can make it broader than that. Arnd
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote: > > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. I've successfully tested this with musl and LTP now, using an i386 kernel. The musl port I used is at https://git.linaro.org/people/arnd.bergmann/musl-y2038.git/ This is just an updated version of what I used for testing last year, using the current syscall assignment, and going back to the time32 versions of getitimer/setitimer and wait4/waitid/getusage. It's certainly not intended for merging like this, but a proper musl port is under discussion now, and this should be sufficient if anyone else wants to try out the new syscall ABI before we merge it. The LTP I have is heavily hacked, and has a number of failures resulting from differences between musl and glibc, or from the way we convert between the kernel types and the user space types. The testing found one minor bug in all the kernel syscall tables: > +418common mq_timedsend_time64 sys_mq_timedsend > +419common mq_timedreceiv_time64 sys_mq_timedreceive While this would have fit in with umount(), creat() and mknod(), it was unintentional, and I've changed it back to mq_timedreceive_time64 (with an added 'e'). Arnd
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 05:18:35PM +0100, Arnd Bergmann wrote: > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann > --- > arch/s390/kernel/syscalls/syscall.tbl | 20 + For the s390 bits: Acked-by: Heiko Carstens
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 5:25 PM Arnd Bergmann wrote:
> This adds 21 new system calls on each ABI that has 32-bit time_t
> today. All of these have the exact same semantics as their existing
> counterparts, and the new ones all have macro names that end in 'time64'
> for clarification.
>
> This gets us to the point of being able to safely use a C library
> that has 64-bit time_t in user space. There are still a couple of
> loose ends to tie up in various areas of the code, but this is the
> big one, and should be entirely uncontroversial at this point.
>
> In particular, there are four system calls (getitimer, setitimer,
> waitid, and getrusage) that don't have a 64-bit counterpart yet,
> but these can all be safely implemented in the C library by wrapping
> around the existing system calls because the 32-bit time_t they
> pass only counts elapsed time, not time since the epoch. They
> will be dealt with later.
>
> Signed-off-by: Arnd Bergmann
> arch/m68k/kernel/syscalls/syscall.tbl | 20 +
For m68k:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
Hi Russell,
On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin
wrote:
> On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > > > - Once we get to 512, we clash with the x32 numbers (unless
> > > > > we remove x32 support first), and probably have to skip
> > > > > a few more. I also considered using the 512..547 space
> > > > > for 32-bit-only calls (which never clash with x32), but
> > > > > that also seems to add a bit of complexity.
> > > >
> > > > I have a patch that I'll send soon to make x32 use its own table. As
> > > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is
> > > > not special. But let's please not reuse 512..547 for other purposes
> > > > on x86 variants -- that way lies even more confusion, IMO.
> > >
> > > Fair enough, the space for those numbers is cheap enough here.
> > > I take it you mean we also should not reuse that number space if
> > > we were to decide to remove x32 soon, but you are not worried
> > > about clashing with arch/alpha when everything else uses consistent
> > > numbers?
> > >
> >
> > I think we have two issues if we reuse those numbers for new syscalls.
> > First, I'd really like to see new syscalls be numbered consistently
> > everywhere, or at least on all x86 variants, and we can't on x32
> > because they mean something else. Perhaps more importantly, due to
> > what is arguably a rather severe bug, issuing a native x86_64 syscall
> > (x32 bit clear) with nr in the range 512..547 does *not* return
> > -ENOSYS on a kernel with x32 enabled. Instead it does something that
> > is somewhat arbitrary. With my patch applied, it will return -ENOSYS,
> > but old kernels will still exist, and this will break syscall probing.
> >
> > Can we perhaps just start the consistent numbers above 547 or maybe
> > block out 512..547 in the new regime?
>
> I don't think you gain much with that kind of scheme - it won't take
> very long before an architecture misses having a syscall added, and
> then someone else adds their own. Been there with ARM - I was keeping
> the syscall table in the same order as x86 for new syscalls, but now
Same for m68k, and probably other architectures.
> that others have been adding syscalls to the table since I converted
> ARM to the tabular form, that's now gone out the window.
>
> So, I think it's completely pointless to do what you're suggesting.
> We'll just end up with a big hole in the middle of the syscall table
> and then revert back to random numbering of syscalls thereafter again.
I believe the plan is to add future syscalls for all architectures in a
single commit, to keep everything in sync.
Regardless, I'm wondering what to do with the holes marked "room for
arch specific calls".
When is a syscall really arch-specific, and can it be added there, and
when does it turn out (later) that it isn't, breaking the
synchronization again?
The pkey syscalls may be a bad example, as AFAIU they can be implemented
on some architectures, but not on some others. Still, I had skipped them
when adding new syscalls to m68k.
Perhaps we should get rid of the notion of "arch-specific syscalls", and
reserve a slot everywhere anyway?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > > - Once we get to 512, we clash with the x32 numbers (unless > > > > we remove x32 support first), and probably have to skip > > > > a few more. I also considered using the 512..547 space > > > > for 32-bit-only calls (which never clash with x32), but > > > > that also seems to add a bit of complexity. > > > > > > I have a patch that I'll send soon to make x32 use its own table. As > > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > > > not special. But let's please not reuse 512..547 for other purposes > > > on x86 variants -- that way lies even more confusion, IMO. > > > > Fair enough, the space for those numbers is cheap enough here. > > I take it you mean we also should not reuse that number space if > > we were to decide to remove x32 soon, but you are not worried > > about clashing with arch/alpha when everything else uses consistent > > numbers? > > > > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something else. Perhaps more importantly, due to > what is arguably a rather severe bug, issuing a native x86_64 syscall > (x32 bit clear) with nr in the range 512..547 does *not* return > -ENOSYS on a kernel with x32 enabled. Instead it does something that > is somewhat arbitrary. With my patch applied, it will return -ENOSYS, > but old kernels will still exist, and this will break syscall probing. > > Can we perhaps just start the consistent numbers above 547 or maybe > block out 512..547 in the new regime? I don't think you gain much with that kind of scheme - it won't take very long before an architecture misses having a syscall added, and then someone else adds their own. Been there with ARM - I was keeping the syscall table in the same order as x86 for new syscalls, but now that others have been adding syscalls to the table since I converted ARM to the tabular form, that's now gone out the window. So, I think it's completely pointless to do what you're suggesting. We'll just end up with a big hole in the middle of the syscall table and then revert back to random numbering of syscalls thereafter again. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 8:53 PM Andy Lutomirski wrote: > I think we have two issues if we reuse those numbers for new syscalls. > First, I'd really like to see new syscalls be numbered consistently > everywhere, or at least on all x86 variants, and we can't on x32 > because they mean something else. Perhaps more importantly, due to > what is arguably a rather severe bug, issuing a native x86_64 syscall > (x32 bit clear) with nr in the range 512..547 does *not* return > -ENOSYS on a kernel with x32 enabled. Instead it does something that > is somewhat arbitrary. With my patch applied, it will return -ENOSYS, > but old kernels will still exist, and this will break syscall probing. > > Can we perhaps just start the consistent numbers above 547 or maybe > block out 512..547 in the new regime? I'm definitely fine with not reusing them ever, and jumping from 511 to 548 when we get there on all architectures, if you think that helps. While we could also jump to 548 *now*, I think that would be a bit wasteful. Syscall numbers are fairly cheap, but not entirely free, especially when you consider architectures like mips that have an upper bound of 1000 syscalls before they have to get inventive. Arnd
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > > - Once we get to 512, we clash with the x32 numbers (unless > > > we remove x32 support first), and probably have to skip > > > a few more. I also considered using the 512..547 space > > > for 32-bit-only calls (which never clash with x32), but > > > that also seems to add a bit of complexity. > > > > I have a patch that I'll send soon to make x32 use its own table. As > > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > > not special. But let's please not reuse 512..547 for other purposes > > on x86 variants -- that way lies even more confusion, IMO. > > Fair enough, the space for those numbers is cheap enough here. > I take it you mean we also should not reuse that number space if > we were to decide to remove x32 soon, but you are not worried > about clashing with arch/alpha when everything else uses consistent > numbers? > I think we have two issues if we reuse those numbers for new syscalls. First, I'd really like to see new syscalls be numbered consistently everywhere, or at least on all x86 variants, and we can't on x32 because they mean something else. Perhaps more importantly, due to what is arguably a rather severe bug, issuing a native x86_64 syscall (x32 bit clear) with nr in the range 512..547 does *not* return -ENOSYS on a kernel with x32 enabled. Instead it does something that is somewhat arbitrary. With my patch applied, it will return -ENOSYS, but old kernels will still exist, and this will break syscall probing. Can we perhaps just start the consistent numbers above 547 or maybe block out 512..547 in the new regime? --Andy
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > - Once we get to 512, we clash with the x32 numbers (unless > > we remove x32 support first), and probably have to skip > > a few more. I also considered using the 512..547 space > > for 32-bit-only calls (which never clash with x32), but > > that also seems to add a bit of complexity. > > I have a patch that I'll send soon to make x32 use its own table. As > far as I'm concerned, 547 is *it*. 548 is just a normal number and is > not special. But let's please not reuse 512..547 for other purposes > on x86 variants -- that way lies even more confusion, IMO. Fair enough, the space for those numbers is cheap enough here. I take it you mean we also should not reuse that number space if we were to decide to remove x32 soon, but you are not worried about clashing with arch/alpha when everything else uses consistent numbers? Arnd
Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote: > > This adds 21 new system calls on each ABI that has 32-bit time_t > today. All of these have the exact same semantics as their existing > counterparts, and the new ones all have macro names that end in 'time64' > for clarification. > > This gets us to the point of being able to safely use a C library > that has 64-bit time_t in user space. There are still a couple of > loose ends to tie up in various areas of the code, but this is the > big one, and should be entirely uncontroversial at this point. > > In particular, there are four system calls (getitimer, setitimer, > waitid, and getrusage) that don't have a 64-bit counterpart yet, > but these can all be safely implemented in the C library by wrapping > around the existing system calls because the 32-bit time_t they > pass only counts elapsed time, not time since the epoch. They > will be dealt with later. > > Signed-off-by: Arnd Bergmann > --- > The one point that still needs to be agreed on is the actual > number assignment. Following the earlier patch that added > the sysv IPC calls with common numbers where possible, I also > tried the same here, using consistent numbers on all 32-bit > architectures. > > There are a couple of minor issues with this: > > - On asm-generic, we now leave the numbers from 295 to 402 > unassigned, which wastes a small amount of kernel .data > segment. Originally I had asm-generic start at 300 and > everyone else start at 400 here, which was also not > perfect, and we have gone beyond 400 already, so I ended > up just using the same numbers as the rest here. > > - Once we get to 512, we clash with the x32 numbers (unless > we remove x32 support first), and probably have to skip > a few more. I also considered using the 512..547 space > for 32-bit-only calls (which never clash with x32), but > that also seems to add a bit of complexity. I have a patch that I'll send soon to make x32 use its own table. As far as I'm concerned, 547 is *it*. 548 is just a normal number and is not special. But let's please not reuse 512..547 for other purposes on x86 variants -- that way lies even more confusion, IMO. --Andy
[PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures
This adds 21 new system calls on each ABI that has 32-bit time_t today. All of these have the exact same semantics as their existing counterparts, and the new ones all have macro names that end in 'time64' for clarification. This gets us to the point of being able to safely use a C library that has 64-bit time_t in user space. There are still a couple of loose ends to tie up in various areas of the code, but this is the big one, and should be entirely uncontroversial at this point. In particular, there are four system calls (getitimer, setitimer, waitid, and getrusage) that don't have a 64-bit counterpart yet, but these can all be safely implemented in the C library by wrapping around the existing system calls because the 32-bit time_t they pass only counts elapsed time, not time since the epoch. They will be dealt with later. Signed-off-by: Arnd Bergmann --- The one point that still needs to be agreed on is the actual number assignment. Following the earlier patch that added the sysv IPC calls with common numbers where possible, I also tried the same here, using consistent numbers on all 32-bit architectures. There are a couple of minor issues with this: - On asm-generic, we now leave the numbers from 295 to 402 unassigned, which wastes a small amount of kernel .data segment. Originally I had asm-generic start at 300 and everyone else start at 400 here, which was also not perfect, and we have gone beyond 400 already, so I ended up just using the same numbers as the rest here. - Once we get to 512, we clash with the x32 numbers (unless we remove x32 support first), and probably have to skip a few more. I also considered using the 512..547 space for 32-bit-only calls (which never clash with x32), but that also seems to add a bit of complexity. - On alpha, we have already used up the space up to 527 (with a small hole between 261 and 299). We could sync up with that as well, but my feeling was that alpha syscalls are already special enough that I don't care. Let me know if you have other ideas. --- arch/alpha/kernel/syscalls/syscall.tbl | 2 + arch/arm/tools/syscall.tbl | 21 ++ arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 41 +++ arch/ia64/kernel/syscalls/syscall.tbl | 1 + arch/m68k/kernel/syscalls/syscall.tbl | 20 + arch/microblaze/kernel/syscalls/syscall.tbl | 21 ++ arch/mips/kernel/syscalls/syscall_n32.tbl | 21 ++ arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 20 + arch/parisc/kernel/syscalls/syscall.tbl | 21 ++ arch/powerpc/kernel/syscalls/syscall.tbl| 20 + arch/s390/kernel/syscalls/syscall.tbl | 20 + arch/sh/kernel/syscalls/syscall.tbl | 20 + arch/sparc/kernel/syscalls/syscall.tbl | 20 + arch/x86/entry/syscalls/syscall_32.tbl | 20 + arch/xtensa/kernel/syscalls/syscall.tbl | 21 ++ include/uapi/asm-generic/unistd.h | 45 - scripts/checksyscalls.sh| 40 ++ 19 files changed, 375 insertions(+), 2 deletions(-) diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index 337b8108771a..936a33fae3c9 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -461,3 +461,5 @@ 530common getegid sys_getegid 531common geteuid sys_geteuid 532common getppid sys_getppid +# all other architectures have common numbers for new syscall, alpha +# is the exception. diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl index a96d9b5ee04e..286afdc43283 100644 --- a/arch/arm/tools/syscall.tbl +++ b/arch/arm/tools/syscall.tbl @@ -416,3 +416,24 @@ 399common io_pgetevents sys_io_pgetevents_time32 400common migrate_pages sys_migrate_pages 401common kexec_file_load sys_kexec_file_load +# 402 is unused +403common clock_gettime64 sys_clock_gettime +404common clock_settime64 sys_clock_settime +405common clock_adjtime64 sys_clock_adjtime +406common clock_getres_time64 sys_clock_getres +407common clock_nanosleep_time64 sys_clock_nanosleep +408common timer_gettime64 sys_timer_gettime +409common timer_settime64 sys_timer_settime +410common timerfd_gettime64 sys_timerfd_gettime +411common timerfd_settime64 sys_timerfd_settime +412common utimensat_time64sys_utimensat +413common pselect6_time64 sys_pselect6 +414common ppoll_time64sys_ppoll +416common io_pgetevents_time64
