1. 19 Feb, 2019 3 commits
    • Arnd Bergmann's avatar
      asm-generic: Make time32 syscall numbers optional · c8ce48f0
      Arnd Bergmann authored
      We don't want new architectures to even provide the old 32-bit time_t
      based system calls any more, or define the syscall number macros.
      
      Add a new __ARCH_WANT_TIME32_SYSCALLS macro that gets enabled for all
      existing 32-bit architectures using the generic system call table,
      so we don't change any current behavior.
      Since this symbol is evaluated in user space as well, we cannot use
      a Kconfig CONFIG_* macro but have to define it in uapi/asm/unistd.h.
      
      On 64-bit architectures, the same system call numbers mostly refer to
      the system calls we want to keep, as they already pass 64-bit time_t.
      
      As new architectures no longer provide these, we need new exceptions
      in checksyscalls.sh.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c8ce48f0
    • Yury Norov's avatar
      asm-generic: Drop getrlimit and setrlimit syscalls from default list · 80d7da1c
      Yury Norov authored
      The newer prlimit64 syscall provides all the functionality of getrlimit
      and setrlimit syscalls and adds the pid of target process, so future
      architectures won't need to include getrlimit and setrlimit.
      
      Therefore drop getrlimit and setrlimit syscalls from the generic syscall
      list unless __ARCH_WANT_SET_GET_RLIMIT is defined by the architecture's
      unistd.h prior to including asm-generic/unistd.h, and adjust all
      architectures using the generic syscall list to define it so that no
      in-tree architectures are affected.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-hexagon@vger.kernel.org
      Cc: uclinux-h8-devel@lists.sourceforge.jp
      Signed-off-by: default avatarYury Norov <ynorov@caviumnetworks.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: James Hogan <james.hogan@imgtec.com> [metag]
      Acked-by: Ley Foon Tan <lftan@altera.com> [nios2]
      Acked-by: Stafford Horne <shorne@gmail.com> [openrisc]
      Acked-by: Will Deacon <will.deacon@arm.com> [arm64]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> #arch/arc bits
      Signed-off-by: default avatarYury Norov <ynorov@marvell.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      80d7da1c
    • Yury Norov's avatar
      32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option · 942fa985
      Yury Norov authored
      All new 32-bit architectures should have 64-bit userspace off_t type, but
      existing architectures has 32-bit ones.
      
      To enforce the rule, new config option is added to arch/Kconfig that defaults
      ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
      32-bit architectures enable it explicitly.
      
      New option affects force_o_largefile() behaviour. Namely, if userspace
      off_t is 64-bits long, we have no reason to reject user to open big files.
      
      Note that even if architectures has only 64-bit off_t in the kernel
      (arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
      a libc may use 32-bit off_t, and therefore want to limit the file size
      to 4GB unless specified differently in the open flags.
      Signed-off-by: default avatarYury Norov <ynorov@caviumnetworks.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarYury Norov <ynorov@marvell.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      942fa985
  2. 18 Feb, 2019 1 commit
  3. 06 Feb, 2019 13 commits
    • Arnd Bergmann's avatar
      y2038: add 64-bit time_t syscalls to all 32-bit architectures · 48166e6e
      Arnd Bergmann authored
      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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      48166e6e
    • Arnd Bergmann's avatar
      y2038: rename old time and utime syscalls · d33c577c
      Arnd Bergmann authored
      The time, stime, utime, utimes, and futimesat system calls are only
      used on older architectures, and we do not provide y2038 safe variants
      of them, as they are replaced by clock_gettime64, clock_settime64,
      and utimensat_time64.
      
      However, for consistency it seems better to have the 32-bit architectures
      that still use them call the "time32" entry points (leaving the
      traditional handlers for the 64-bit architectures), like we do for system
      calls that now require two versions.
      
      Note: We used to always define __ARCH_WANT_SYS_TIME and
      __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and
      __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is
      reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while
      we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
      mode. The resulting asm/unistd.h changes look a bit counterintuitive.
      
      This is only a cleanup patch and it should not change any behavior.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      d33c577c
    • Arnd Bergmann's avatar
      y2038: remove struct definition redirects · c70a772f
      Arnd Bergmann authored
      We now use 64-bit time_t on all architectures, so the __kernel_timex,
      __kernel_timeval and __kernel_timespec redirects can be removed
      after having served their purpose.
      
      This makes it all much less confusing, as the __kernel_* types
      now always refer to the same layout based on 64-bit time_t across
      all 32-bit and 64-bit architectures.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      c70a772f
    • Arnd Bergmann's avatar
      y2038: use time32 syscall names on 32-bit · 00bf25d6
      Arnd Bergmann authored
      This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
      and use the _time32 system calls from the former compat layer instead
      of the system calls that take __kernel_timespec and similar arguments.
      
      The temporary redirects for __kernel_timespec, __kernel_itimerspec
      and __kernel_timex can get removed with this.
      
      It would be easy to split this commit by architecture, but with the new
      generated system call tables, it's easy enough to do it all at once,
      which makes it a little easier to check that the changes are the same
      in each table.
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      00bf25d6
    • Arnd Bergmann's avatar
      y2038: syscalls: rename y2038 compat syscalls · 8dabe724
      Arnd Bergmann authored
      A lot of system calls that pass a time_t somewhere have an implementation
      using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have
      been reworked so that this implementation can now be used on 32-bit
      architectures as well.
      
      The missing step is to redefine them using the regular SYSCALL_DEFINEx()
      to get them out of the compat namespace and make it possible to build them
      on 32-bit architectures.
      
      Any system call that ends in 'time' gets a '32' suffix on its name for
      that version, while the others get a '_time32' suffix, to distinguish
      them from the normal version, which takes a 64-bit time argument in the
      future.
      
      In this step, only 64-bit architectures are changed, doing this rename
      first lets us avoid touching the 32-bit architectures twice.
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      8dabe724
    • Arnd Bergmann's avatar
      x86/x32: use time64 versions of sigtimedwait and recvmmsg · 7948450d
      Arnd Bergmann authored
      x32 has always followed the time64 calling conventions of these
      syscalls, which required a special hack in compat_get_timespec
      aka get_old_timespec32 to continue working.
      
      Since we now have the time64 syscalls, use those explicitly.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      7948450d
    • Deepa Dinamani's avatar
      timex: change syscalls to use struct __kernel_timex · 3876ced4
      Deepa Dinamani authored
      struct timex is not y2038 safe.
      Switch all the syscall apis to use y2038 safe __kernel_timex.
      
      Note that sys_adjtimex() does not have a y2038 safe solution.  C libraries
      can implement it by calling clock_adjtime(CLOCK_REALTIME, ...).
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      3876ced4
    • Deepa Dinamani's avatar
      timex: use __kernel_timex internally · ead25417
      Deepa Dinamani authored
      struct timex is not y2038 safe.
      Replace all uses of timex with y2038 safe __kernel_timex.
      
      Note that struct __kernel_timex is an ABI interface definition.
      We could define a new structure based on __kernel_timex that
      is only available internally instead. Right now, there isn't
      a strong motivation for this as the structure is isolated to
      a few defined struct timex interfaces and such a structure would
      be exactly the same as struct timex.
      
      The patch was generated by the following coccinelle script:
      
      virtual patch
      
      @depends on patch forall@
      identifier ts;
      expression e;
      @@
      (
      - struct timex ts;
      + struct __kernel_timex ts;
      |
      - struct timex ts = {};
      + struct __kernel_timex ts = {};
      |
      - struct timex ts = e;
      + struct __kernel_timex ts = e;
      |
      - struct timex *ts;
      + struct __kernel_timex *ts;
      |
      (memset \| copy_from_user \| copy_to_user \)(...,
      - sizeof(struct timex))
      + sizeof(struct __kernel_timex))
      )
      
      @depends on patch forall@
      identifier ts;
      identifier fn;
      @@
      fn(...,
      - struct timex *ts,
      + struct __kernel_timex *ts,
      ...) {
      ...
      }
      
      @depends on patch forall@
      identifier ts;
      identifier fn;
      @@
      fn(...,
      - struct timex *ts) {
      + struct __kernel_timex *ts) {
      ...
      }
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Cc: linux-alpha@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ead25417
    • Arnd Bergmann's avatar
      sparc64: add custom adjtimex/clock_adjtime functions · 1a596398
      Arnd Bergmann authored
      sparc64 is the only architecture on Linux that has a 'timeval'
      definition with a 32-bit tv_usec but a 64-bit tv_sec. This causes
      problems for sparc32 compat mode when we convert it to use the
      new __kernel_timex type that has the same layout as all other
      64-bit architectures.
      
      To avoid adding sparc64 specific code into the generic adjtimex
      implementation, this adds a wrapper in the sparc64 system call handling
      that converts the sparc64 'timex' into the new '__kernel_timex'.
      
      At this point, the two structures are defined to be identical,
      but that will change in the next step once we convert sparc32.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1a596398
    • Arnd Bergmann's avatar
      time: fix sys_timer_settime prototype · 50b93f30
      Arnd Bergmann authored
      A small typo has crept into the y2038 conversion of the timer_settime
      system call. So far this was completely harmless, but once we start
      using the new version, this has to be fixed.
      
      Fixes: 6ff84735 ("time: Change types to new y2038 safe __kernel_itimerspec")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      50b93f30
    • Deepa Dinamani's avatar
      time: Add struct __kernel_timex · 2c620ff9
      Deepa Dinamani authored
      struct timex uses struct timeval internally.
      struct timeval is not y2038 safe.
      Introduce a new UAPI type struct __kernel_timex
      that is y2038 safe.
      
      struct __kernel_timex uses a timeval type that is
      similar to struct __kernel_timespec which preserves the
      same structure size across 32 bit and 64 bit ABIs.
      struct __kernel_timex also restructures other members of the
      structure to make the structure the same on 64 bit and 32 bit
      architectures.
      Note that struct __kernel_timex is the same as struct timex
      on a 64 bit architecture.
      
      The above solution is similar to other new y2038 syscalls
      that are being introduced: both 32 bit and 64 bit ABIs
      have a common entry, and the compat entry supports the old 32 bit
      syscall interface.
      
      Alternatives considered were:
      1. Add new time type to struct timex that makes use of padded
         bits. This time type could be based on the struct __kernel_timespec.
         modes will use a flag to notify which time structure should be
         used internally.
         This needs some application level changes on both 64 bit and 32 bit
         architectures. Although 64 bit machines could continue to use the
         older timeval structure without any changes.
      
      2. Add a new u8 type to struct timex that makes use of padded bits. This
         can be used to save higher order tv_sec bits. modes will use a flag to
         notify presence of such a type.
         This will need some application level changes on 32 bit architectures.
      
      3. Add a new compat_timex structure that differs in only the size of the
         time type; keep rest of struct timex the same.
         This requires extra syscalls to manage all 3 cases on 64 bit
         architectures. This will not need any application level changes but will
         add more complexity from kernel side.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      2c620ff9
    • Arnd Bergmann's avatar
      time: make adjtime compat handling available for 32 bit · 4d5f007e
      Arnd Bergmann authored
      We want to reuse the compat_timex handling on 32-bit architectures the
      same way we are using the compat handling for timespec when moving to
      64-bit time_t.
      
      Move all definitions related to compat_timex out of the compat code
      into the normal timekeeping code, along with a rename to old_timex32,
      corresponding to the timespec/timeval structures, and make it controlled
      by CONFIG_COMPAT_32BIT_TIME, which 32-bit architectures will then select.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      4d5f007e
    • Arnd Bergmann's avatar
      syscalls: remove obsolete __IGNORE_ macros · 805089c2
      Arnd Bergmann authored
      These are all for ignoring the lack of obsolete system calls,
      which have been marked the same way in scripts/checksyscall.sh,
      so these can be removed.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      805089c2
  4. 25 Jan, 2019 16 commits
    • Arnd Bergmann's avatar
      alpha: add generic get{eg,eu,g,p,u,pp}id() syscalls · ecf7e0a4
      Arnd Bergmann authored
      Alpha has traditionally followed the OSF1 calling conventions
      here, with its getxpid, getxuid, getxgid system calls returning
      two different values in separate registers.
      
      Following what glibc has done here, we can define getpid,
      getuid and getgid to be aliases for getxpid, getxuid and getxgid
      respectively, and add new system call numbers for getppid, geteuid
      and getegid.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      ecf7e0a4
    • Arnd Bergmann's avatar
      alpha: add standard statfs64/fstatfs64 syscalls · 6691f16a
      Arnd Bergmann authored
      As Joseph Myers points out, alpha has never had a standard statfs64
      interface and instead returns only 32-bit numbers here.
      
      While there is an old osf_statfs64 system call that returns additional
      data, this has some other quirks and does not get used in glibc.
      
      I considered making the stat64 structure layout compatible with
      with the one used by the kernel on most other 64 bit architecture that
      implement it (ia64, parisc, powerpc, and sparc), but in the end
      decided to stay with the one that was traditionally defined in
      the alpha headers but not used, since this is also what glibc
      exposes to user space.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      6691f16a
    • Arnd Bergmann's avatar
      arch: add pkey and rseq syscall numbers everywhere · b41c51c8
      Arnd Bergmann authored
      Most architectures define system call numbers for the rseq and pkey system
      calls, even when they don't support the features, and perhaps never will.
      
      Only a few architectures are missing these, so just define them anyway
      for consistency. If we decide to add them later to one of these, the
      system call numbers won't get out of sync then.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      b41c51c8
    • Arnd Bergmann's avatar
      arch: add split IPC system calls where needed · 0d6040d4
      Arnd Bergmann authored
      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 addition of a y2038 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: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      0d6040d4
    • Arnd Bergmann's avatar
      ipc: rename old-style shmctl/semctl/msgctl syscalls · 275f2214
      Arnd Bergmann authored
      The behavior of these system calls is slightly different between
      architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
      symbol. Most architectures that implement the split IPC syscalls don't set
      that symbol and only get the modern version, but alpha, arm, microblaze,
      mips-n32, mips-n64 and xtensa expect the caller to pass the IPC_64 flag.
      
      For the architectures that so far only implement sys_ipc(), i.e. m68k,
      mips-o32, powerpc, s390, sh, sparc, and x86-32, we want the new behavior
      when adding the split syscalls, so we need to distinguish between the
      two groups of architectures.
      
      The method I picked for this distinction is to have a separate system call
      entry point: sys_old_*ctl() now uses ipc_parse_version, while sys_*ctl()
      does not. The system call tables of the five architectures are changed
      accordingly.
      
      As an additional benefit, we no longer need the configuration specific
      definition for ipc_parse_version(), it always does the same thing now,
      but simply won't get called on architectures with the modern interface.
      
      A small downside is that on architectures that do set
      ARCH_WANT_IPC_PARSE_VERSION, we now have an extra set of entry points
      that are never called. They only add a few bytes of bloat, so it seems
      better to keep them compared to adding yet another Kconfig symbol.
      I considered adding new syscall numbers for the IPC_64 variants for
      consistency, but decided against that for now.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      275f2214
    • Arnd Bergmann's avatar
      sparc64: fix sparc_ipc type conversion · 73a66023
      Arnd Bergmann authored
      __kernel_timespec and timespec are currently the same type, but once
      they are different, the type cast has to be changed here.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      73a66023
    • Arnd Bergmann's avatar
      sh: add statx system call · d25a122a
      Arnd Bergmann authored
      statx is available on almost all other architectures but
      got missed on sh, so add it now.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d25a122a
    • Arnd Bergmann's avatar
      sh: remove duplicate unistd_32.h file · 83f60913
      Arnd Bergmann authored
      When I merged this patch, the file was accidentally left intact
      instead of being removed, which means any changes to syscall.tbl
      have no effect.
      
      Fixes: 2b3c5a99 ("sh: generate uapi header and syscall table header files")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      83f60913
    • Arnd Bergmann's avatar
      m68k: assign syscall number for seccomp · 09ac1260
      Arnd Bergmann authored
      Most architectures have assigned a numbers for the seccomp syscall
      even when they do not implement it.
      
      m68k is an exception here, so for consistency lets add the number.
      Unless CONFIG_SECCOMP is implemented, the system call just
      returns -ENOSYS.
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      09ac1260
    • Arnd Bergmann's avatar
      ARM: add kexec_file_load system call number · 4ab65ba7
      Arnd Bergmann authored
      A couple of architectures including arm64 already implement the
      kexec_file_load system call, on many others we have assigned a system
      call number for it, but not implemented it yet.
      
      Adding the number in arch/arm/ lets us use the system call on arm64
      systems in compat mode, and also reduces the number of differences
      between architectures. If we want to implement kexec_file_load on ARM
      in the future, the number assignment means that kexec tools can already
      be built with the now current set of kernel headers.
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      4ab65ba7
    • Arnd Bergmann's avatar
      ARM: add migrate_pages() system call · 78594b95
      Arnd Bergmann authored
      The migrate_pages system call has an assigned number on all architectures
      except ARM. When it got added initially in commit d80ade7b ("ARM:
      Fix warning: #warning syscall migrate_pages not implemented"), it was
      intentionally left out based on the observation that there are no 32-bit
      ARM NUMA systems.
      
      However, there are now arm64 NUMA machines that can in theory run 32-bit
      kernels (actually enabling NUMA there would require additional work)
      as well as 32-bit user space on 64-bit kernels, so that argument is no
      longer very strong.
      
      Assigning the number lets us use the system call on 64-bit kernels as well
      as providing a more consistent set of syscalls across architectures.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      78594b95
    • Arnd Bergmann's avatar
      alpha: update syscall macro definitions · 12b57c5c
      Arnd Bergmann authored
      Other architectures commonly use __NR_umount2 for sys_umount,
      only ia64 and alpha use __NR_umount here. In order to synchronize
      the generated tables, use umount2 like everyone else, and add back
      the old name from asm/unistd.h for compatibility.
      
      For shmat, alpha uses the osf_shmat name, we can do the same thing
      here, which means we don't have to add an entry in the __IGNORE
      list now that shmat is mandatory everywhere
      
      alarm, creat, pause, time, and utime are optional everywhere
      these days, no need to list them here any more.
      
      I considered also adding the regular versions of the get*id system
      calls that have different names and calling conventions on alpha,
      which would further help unify the syscall ABI, but for now
      I decided against that.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      12b57c5c
    • Arnd Bergmann's avatar
      alpha: wire up io_pgetevents system call · d012d132
      Arnd Bergmann authored
      The io_pgetevents system call was added in linux-4.18 but has
      no entry for alpha:
      
      warning: #warning syscall io_pgetevents not implemented [-Wcpp]
      
      Assign a the next system call number here.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d012d132
    • Arnd Bergmann's avatar
      ia64: assign syscall numbers for perf and seccomp · acce2f71
      Arnd Bergmann authored
      Most architectures have assigned numbers for both seccomp and
      perf_event_open, even when they do not implement either.
      
      ia64 is an exception here, so for consistency lets add numbers for both
      of them. Unless CONFIG_PERF_EVENTS and CONFIG_SECCOMP are implemented,
      the system calls just return -ENOSYS.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      acce2f71
    • Arnd Bergmann's avatar
      ia64: add statx and io_pgetevents syscalls · 7349ee3a
      Arnd Bergmann authored
      All architectures should implement these two, so assign numbers
      and hook them up on ia64.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      7349ee3a
    • Arnd Bergmann's avatar
      ia64: add __NR_umount2 definition · 74cd2184
      Arnd Bergmann authored
      Other architectures commonly use __NR_umount2 for sys_umount,
      only ia64 and alpha use __NR_umount here. In order to synchronize
      the generated tables, use umount2 like everyone else, and add back
      the old name from asm/unistd.h for compatibility.
      
      The __IGNORE_* lines are now all obsolete and can be removed as
      a side-effect.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      74cd2184
  5. 18 Jan, 2019 5 commits
  6. 13 Jan, 2019 2 commits