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


16 Jun, 2018

1 commit


12 Jun, 2018

1 commit


05 Jun, 2018

3 commits

  • Greg Kroah-Hartman
     
  • commit 0a5f41767444cc3b4fc5573921ab914b4f78baaa upstream.

    Currently, GCC disables -Wunused-const-variable, but not
    -Wunused-variable, so warns unused variables if they are
    non-constant.

    While, Clang does not warn unused variables at all regardless of
    the const qualifier because -Wno-unused-const-variable is implied
    by the stronger option -Wno-unused-variable.

    Disable -Wunused-const-variable instead of -Wunused-variable so that
    GCC and Clang work in the same way.

    Signed-off-by: Prasad Sodagudi
    Signed-off-by: Masahiro Yamada
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Sodagudi Prasad
     
  • commit df16aaac26e92e97ab7234d3f93c953466adc4b5 upstream.

    When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
    that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
    targets. These were added in commit 61163efae020 ("kbuild: LLVMLinux:
    Add Kbuild support for building kernel with Clang").

    Clang does not support -fno-delete-null-pointer-checks, so adding it to
    HOSTCFLAGS if HOSTCC is clang does not make sense.

    It's not clear why the other warnings were disabled, and just for
    HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
    with clang just fine.

    Suggested-by: Masahiro Yamada
    Signed-off-by: Nick Desaulniers
    Signed-off-by: Masahiro Yamada
    Cc: Guenter Roeck
    Signed-off-by: Greg Kroah-Hartman

    Nick Desaulniers
     

31 May, 2018

1 commit


30 May, 2018

2 commits


25 May, 2018

1 commit