1. 01 Sep, 2019 2 commits
    • Max Filippov's avatar
      xtensa: add support for call0 ABI in userspace · 09f8a6db
      Max Filippov authored
      Provide a Kconfig choice to select whether only the default ABI, only
      call0 ABI or both are supported. The default for XEA2 is windowed, but
      it may change for XEA3. Call0 only runs userspace with PS.WOE disabled.
      Supporting both windowed and call0 ABIs is tricky, as there's no
      indication in the ELF binaries which ABI they use. So it is done by
      probing: each process is started with PS.WOE disabled, but the handler
      of an illegal instruction exception taken with PS.WOE retries faulting
      instruction after enabling PS.WOE. It must happen before any signal is
      delivered to the process, otherwise it may be delivered incorrectly.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
    • Max Filippov's avatar
      xtensa: clean up PS_WOE_BIT usage · 9e1e41c4
      Max Filippov authored
      PS_WOE_BIT is mainly used to generate PS.WOE mask in the code. Introduce
      PS_WOE_MASK macro and use it instead.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
  2. 27 Aug, 2019 1 commit
    • Mike Rapoport's avatar
      xtensa: remove free_initrd_mem · f348f5c2
      Mike Rapoport authored
      The xtensa free_initrd_mem() verifies that initrd is mapped and then
      frees its memory using free_reserved_area().
      The initrd is considered mapped when its memory was successfully reserved
      with mem_reserve().
      Resetting initrd_start to 0 in case of mem_reserve() failure allows to
      switch to generic free_initrd_mem() implementation.
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Message-Id: <1563977432-8376-1-git-send-email-rppt@linux.ibm.com>
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
  3. 12 Aug, 2019 1 commit
  4. 25 Jul, 2019 1 commit
  5. 08 Jul, 2019 1 commit
    • Max Filippov's avatar
      xtensa: abstract 'entry' and 'retw' in assembly code · d6d5f19e
      Max Filippov authored
      Provide abi_entry, abi_entry_default, abi_ret and abi_ret_default macros
      that allocate aligned stack frame in windowed and call0 ABIs.
      Provide XTENSA_SPILL_STACK_RESERVE macro that specifies required stack
      frame size when register spilling is involved.
      Replace all uses of 'entry' and 'retw' with the above macros.
      This makes most of the xtensa assembly code ready for XEA3 and call0 ABI.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
  6. 28 Jun, 2019 1 commit
    • Christian Brauner's avatar
      arch: wire-up pidfd_open() · 7615d9e1
      Christian Brauner authored
      This wires up the pidfd_open() syscall into all arches at once.
      Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      Reviewed-by: default avatarDavid Howells <dhowells@redhat.com>
      Reviewed-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Joel Fernandes (Google) <joel@joelfernandes.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jann Horn <jannh@google.com>
      Cc: Andy Lutomirsky <luto@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Aleksa Sarai <cyphar@cyphar.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-mips@vger.kernel.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: sparclinux@vger.kernel.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: linux-arch@vger.kernel.org
      Cc: x86@kernel.org
  7. 25 Jun, 2019 1 commit
  8. 19 Jun, 2019 1 commit
  9. 17 Jun, 2019 3 commits
  10. 09 Jun, 2019 1 commit
    • Christian Brauner's avatar
      arch: wire-up clone3() syscall · 8f3220a8
      Christian Brauner authored
      Wire up the clone3() call on all arches that don't require hand-rolled
      Some of the arches look like they need special assembly massaging and it is
      probably smarter if the appropriate arch maintainers would do the actual
      wiring. Arches that are wired-up are:
      - x86{_32,64}
      - arm{64}
      - xtensa
      Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Adrian Reber <adrian@lisas.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Florian Weimer <fweimer@redhat.com>
      Cc: linux-api@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: x86@kernel.org
  11. 30 May, 2019 2 commits
  12. 29 May, 2019 1 commit
    • Eric W. Biederman's avatar
      signal: Remove the task parameter from force_sig_fault · 2e1661d2
      Eric W. Biederman authored
      As synchronous exceptions really only make sense against the current
      task (otherwise how are you synchronous) remove the task parameter
      from from force_sig_fault to make it explicit that is what is going
      The two known exceptions that deliver a synchronous exception to a
      stopped ptraced task have already been changed to
      The callers have been changed with the following emacs regular expression
      (with obvious variations on the architectures that take more arguments)
      to avoid typos:
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  13. 27 May, 2019 1 commit
  14. 16 May, 2019 1 commit
  15. 15 May, 2019 1 commit
  16. 07 May, 2019 2 commits
  17. 15 Apr, 2019 1 commit
  18. 04 Apr, 2019 2 commits
  19. 07 Feb, 2019 5 commits
  20. 06 Feb, 2019 3 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: Catalin Marinas's avatarCatalin Marinas <catalin.marinas@arm.com>
    • 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_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>
    • 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>
  21. 27 Jan, 2019 1 commit
    • Max Filippov's avatar
      xtensa: SMP: limit number of possible CPUs by NR_CPUS · 25384ce5
      Max Filippov authored
      This fixes the following warning at boot when the kernel is booted on a
      board with more CPU cores than was configured in NR_CPUS:
        smp_init_cpus: Core Count = 8
        smp_init_cpus: Core Id = 0
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 0 at include/linux/cpumask.h:121 smp_init_cpus+0x54/0x74
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc3-00015-g1459333f88a0 #124
        Call Trace:
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
  22. 26 Jan, 2019 2 commits
  23. 25 Jan, 2019 3 commits
    • 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>
    • 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
      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>
    • Max Filippov's avatar
      xtensa: SMP: fix ccount_timer_shutdown · 4fe8713b
      Max Filippov authored
      ccount_timer_shutdown is called from the atomic context in the
      secondary_start_kernel, resulting in the following BUG:
      BUG: sleeping function called from invalid context
      in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/1
      Preemption disabled at:
      Call Trace:
      Use disable_irq_nosync instead of disable_irq to avoid it.
      This is safe because the ccount timer IRQ is per-CPU, and once IRQ is
      masked the ISR will not be called.
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
  24. 06 Jan, 2019 1 commit
    • Masahiro Yamada's avatar
      jump_label: move 'asm goto' support test to Kconfig · e9666d10
      Masahiro Yamada authored
      Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label".
      The jump label is controlled by HAVE_JUMP_LABEL, which is defined
      like this:
        #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
        # define HAVE_JUMP_LABEL
      We can improve this by testing 'asm goto' support in Kconfig, then
      make JUMP_LABEL depend on CC_HAS_ASM_GOTO.
      Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will
      match to the real kernel capability.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
  25. 04 Jan, 2019 1 commit
    • Linus Torvalds's avatar
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds authored
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      There were a couple of notable cases:
       - csky still had the old "verify_area()" name as an alias.
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
       - microblaze used the type argument for a debug printout
      but other than those oddities this should be a total no-op patch.
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>