01 Dec, 2018

2 commits

  • Greg Kroah-Hartman
     
  • commit ef8c4ed9db80261f397f0c0bf723684601ae3b52 upstream.

    When using a GCC cross toolchain which is not in a compiled in
    Clang search path, Clang reverts to the system assembler and
    linker. This leads to assembler or linker errors, depending on
    which tool is first used for a given architecture.

    It seems that Clang is not searching $PATH for a matching
    assembler or linker.

    Make sure that Clang picks up the correct assembler or linker by
    passing the cross compilers bin directory as search path.

    This allows to use Clang provided by distributions with GCC
    toolchains not in /usr/bin.

    Link: https://github.com/ClangBuiltLinux/linux/issues/78
    Signed-off-by: Stefan Agner
    Reviewed-and-tested-by: Nick Desaulniers
    Signed-off-by: Masahiro Yamada
    [nc: Adjust context]
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Greg Kroah-Hartman

    Stefan Agner
     

27 Nov, 2018

1 commit


23 Nov, 2018

1 commit


21 Nov, 2018

1 commit


14 Nov, 2018

1 commit


10 Nov, 2018

1 commit


04 Nov, 2018

2 commits


20 Oct, 2018

1 commit


18 Oct, 2018

1 commit


13 Oct, 2018

1 commit


10 Oct, 2018

1 commit


04 Oct, 2018

1 commit


29 Sep, 2018

1 commit


26 Sep, 2018

1 commit


20 Sep, 2018

1 commit


15 Sep, 2018

1 commit


10 Sep, 2018

1 commit


05 Sep, 2018

2 commits

  • Greg Kroah-Hartman
     
  • commit 2e549b2ee0e358bc758480e716b881f9cabedb6a upstream.

    Currently, if the vDSO ends up containing an indirect branch or
    call, GCC will emit the "external thunk" style of retpoline, and it
    will fail to link.

    Fix it by building the vDSO with inline retpoline thunks.

    I haven't seen any reports of this triggering on an unpatched
    kernel.

    Fixes: commit 76b043848fd2 ("x86/retpoline: Add initial retpoline support")
    Signed-off-by: Andy Lutomirski
    Signed-off-by: Thomas Gleixner
    Acked-by: Matt Rickard
    Cc: Borislav Petkov
    Cc: Jason Vas Dias
    Cc: David Woodhouse
    Cc: Peter Zijlstra
    Cc: Andi Kleen
    Cc: stable@vger.kernel.org
    Link: https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.luto@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Andy Lutomirski
     

24 Aug, 2018

2 commits

  • Greg Kroah-Hartman
     
  • [ Upstream commit 6d79a7b424a5630a6fcab31fd7c38af4ea9c9a0f ]

    Suppress warnings for systems that do not recognize LFS_*.

    getconf: no such configuration parameter `LFS_CFLAGS'
    getconf: no such configuration parameter `LFS_LDFLAGS'
    getconf: no such configuration parameter `LFS_LIBS'

    Fixes: d7f14c66c273 ("kbuild: Enable Large File Support for hostprogs")
    Reported-by: Chen Feng
    Signed-off-by: Masahiro Yamada
    Acked-by: Uwe Kleine-König
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     

22 Aug, 2018

1 commit


18 Aug, 2018

2 commits


16 Aug, 2018

1 commit


09 Aug, 2018

1 commit


06 Aug, 2018

1 commit


03 Aug, 2018

1 commit


28 Jul, 2018

2 commits

  • Greg Kroah-Hartman
     
  • Starting with gcc-8.1, we get a warning about all system call definitions,
    which use an alias between functions with incompatible prototypes, e.g.:

    In file included from ../mm/process_vm_access.c:19:
    ../include/linux/syscalls.h:211:18: warning: 'sys_process_vm_readv' alias between functions of incompatible types 'long int(pid_t, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)' {aka 'long int(int, const struct iovec *, long unsigned int, const struct iovec *, long unsigned int, long unsigned int)'} and 'long int(long int, long int, long int, long int, long int, long int)' [-Wattribute-alias]
    asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
    ^~~
    ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
    __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
    ^~~~~~~~~~~~~~~~~
    ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
    #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
    ^~~~~~~~~~~~~~~
    ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
    SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,
    ^~~~~~~~~~~~~~~
    ../include/linux/syscalls.h:215:18: note: aliased declaration here
    asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
    ^~~
    ../include/linux/syscalls.h:207:2: note: in expansion of macro '__SYSCALL_DEFINEx'
    __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
    ^~~~~~~~~~~~~~~~~
    ../include/linux/syscalls.h:201:36: note: in expansion of macro 'SYSCALL_DEFINEx'
    #define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
    ^~~~~~~~~~~~~~~
    ../mm/process_vm_access.c:300:1: note: in expansion of macro 'SYSCALL_DEFINE6'
    SYSCALL_DEFINE6(process_vm_readv, pid_t, pid, const struct iovec __user *, lvec,

    This is really noisy and does not indicate a real problem. In the latest
    mainline kernel, this was addressed by commit bee20031772a ("disable
    -Wattribute-alias warning for SYSCALL_DEFINEx()"), which seems too invasive
    to backport.

    This takes a much simpler approach and just disables the warning across the
    kernel.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

25 Jul, 2018

1 commit


22 Jul, 2018

1 commit


17 Jul, 2018

1 commit


11 Jul, 2018

1 commit


08 Jul, 2018

1 commit


03 Jul, 2018

1 commit


26 Jun, 2018

1 commit


21 Jun, 2018

1 commit