Skip to content
Snippets Groups Projects
  1. May 10, 2019
  2. May 05, 2019
  3. May 03, 2019
  4. Apr 15, 2019
  5. Apr 06, 2019
    • Helge Deller's avatar
      parisc: Detect QEMU earlier in boot process · d006e95b
      Helge Deller authored
      
      While adding LASI support to QEMU, I noticed that the QEMU detection in
      the kernel happens much too late. For example, when a LASI chip is found
      by the kernel, it registers the LASI LED driver as well.  But when we
      run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so
      we need to access the running_on_QEMU flag earlier than before.
      
      This patch now makes the QEMU detection the fist task of the Linux
      kernel by moving it to where the kernel enters the C-coding.
      
      Fixes: 310d8278 ("parisc: qemu idle sleep support")
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org # v4.14+
      d006e95b
  6. Feb 21, 2019
  7. Feb 06, 2019
    • 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: 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
  8. Jan 25, 2019
Loading