Skip to content
Snippets Groups Projects
  1. Mar 08, 2019
  2. Mar 06, 2019
  3. Mar 01, 2019
    • Arnd Bergmann's avatar
      kasan: turn off asan-stack for clang-8 and earlier · 6baec880
      Arnd Bergmann authored
      Building an arm64 allmodconfig kernel with clang results in over 140
      warnings about overly large stack frames, the worst ones being:
      
        drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size of 20224 bytes in function 'st7789v_prepare'
        drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12: error: stack frame size of 13120 bytes in function 'td028ttec1_panel_enable'
        drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 10048 bytes in function 'max3421_spi_thread'
        drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 9664 bytes in function 'slic_ds26522_probe'
        drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832 bytes in function 'ccp_run_cmd'
        drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame size of 7840 bytes in function 'stv0367ter_algo'
      
      None of these happen with gcc today, and almost all of these are the
      result of a single known issue in llvm.  Hopefully it will eventually
      get fixed with the clang-9 release.
      
      In the meantime, the best idea I have is to turn off asan-stack for
      clang-8 and earlier, so we can produce a kernel that is safe to run.
      
      I have posted three patches that address the frame overflow warnings
      that are not addressed by turning off asan-stack, so in combination with
      this change, we get much closer to a clean allmodconfig build, which in
      turn is necessary to do meaningful build regression testing.
      
      It is still possible to turn on the CONFIG_ASAN_STACK option on all
      versions of clang, and it's always enabled for gcc, but when
      CONFIG_COMPILE_TEST is set, the option remains invisible, so
      allmodconfig and randconfig builds (which are normally done with a
      forced CONFIG_COMPILE_TEST) will still result in a mostly clean build.
      
      Link: http://lkml.kernel.org/r/20190222222950.3997333-1-arnd@arndb.de
      Link: https://bugs.llvm.org/show_bug.cgi?id=38809
      
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarQian Cai <cai@lca.pw>
      Reviewed-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6baec880
  4. Feb 19, 2019
    • Arnd Bergmann's avatar
      checksyscalls: fix up mq_timedreceive and stat exceptions · 1d5b8233
      Arnd Bergmann authored
      
      mq_timedreceive was spelled incorrectly, and we need exceptions
      for new architectures that leave out newstat or stat64, implementing
      only statx() now.
      
      Fixes: 48166e6e ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
      Fixes: bf4b6a7d ("y2038: Remove stat64 family from default syscall set")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      1d5b8233
    • 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
  5. Feb 13, 2019
    • Mark Rutland's avatar
      locking/atomics: Check atomic headers with sha1sum · 0cf264b3
      Mark Rutland authored
      
      We currently check the atomic headers at build-time to ensure they
      haven't been modified directly, and these checks require regenerating
      the headers in full. As this takes a few seconds, even when
      parallelized, this is too slow to run for every kernel build.
      
      Instead, we can generate a hash of each header as we generate them,
      which we can cheaply check at build time (~0.16s for all headers).
      
      This patch does so, updating headers with their hashes using the new
      gen-atomics.sh script. As some users apparently build the kernel wihout
      coreutils, lacking sha1sum, the checks are skipped in this case.
      Presumably, most developers have a working coreutils installation.
      
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: anders.roxell@linaro.org
      Cc: linux-kernel@vger.kernel.rg
      Cc: naresh.kamboju@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0cf264b3
  6. Feb 11, 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
  8. Feb 01, 2019
    • Sumit Garg's avatar
      tee: add bus driver framework for TEE based devices · 0fc1db9d
      Sumit Garg authored
      
      Introduce a generic TEE bus driver concept for TEE based kernel drivers
      which would like to communicate with TEE based devices/services. Also
      add support in module device table for these new TEE based devices.
      
      In this TEE bus concept, devices/services are identified via Universally
      Unique Identifier (UUID) and drivers register a table of device UUIDs
      which they can support.
      
      So this TEE bus framework registers following apis:
      - match(): Iterates over the driver UUID table to find a corresponding
        match for device UUID. If a match is found, then this particular device
        is probed via corresponding probe api registered by the driver. This
        process happens whenever a device or a driver is registered with TEE
        bus.
      - uevent(): Notifies user-space (udev) whenever a new device is registered
        on this bus for auto-loading of modularized drivers.
      
      Also this framework allows for device enumeration to be specific to
      corresponding TEE implementation like OP-TEE etc.
      
      Signed-off-by: default avatarSumit Garg <sumit.garg@linaro.org>
      Reviewed-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Reviewed-by: default avatarBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: default avatarJens Wiklander <jens.wiklander@linaro.org>
      0fc1db9d
  9. Jan 28, 2019
  10. Jan 22, 2019
  11. Jan 20, 2019
  12. Jan 14, 2019
  13. Jan 09, 2019
    • WANG Chao's avatar
      x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE · e4f35891
      WANG Chao authored
      
      Commit
      
        4cd24de3 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
      
      replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
      remaining pieces.
      
       [ bp: Massage commit message. ]
      
      Fixes: 4cd24de3 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
      Signed-off-by: default avatarWANG Chao <chao.wang@ucloud.cn>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarZhenzhong Duan <zhenzhong.duan@oracle.com>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Woodhouse <dwmw@amazon.co.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: linux-kbuild@vger.kernel.org
      Cc: srinivas.eeda@oracle.com
      Cc: stable <stable@vger.kernel.org>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
      e4f35891
  14. Jan 08, 2019
  15. Jan 06, 2019
  16. Jan 04, 2019
  17. Dec 28, 2018
Loading