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


23 May, 2018

1 commit


19 May, 2018

1 commit


16 May, 2018

1 commit


09 May, 2018

1 commit


02 May, 2018

1 commit


29 Apr, 2018

1 commit


26 Apr, 2018

1 commit


24 Apr, 2018

1 commit


19 Apr, 2018

1 commit


12 Apr, 2018

1 commit


08 Apr, 2018

1 commit


01 Apr, 2018

1 commit


29 Mar, 2018

2 commits

  • Greg Kroah-Hartman
     
  • commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79 upstream.

    Prasad reported that he has seen crashes in BPF subsystem with netd
    on Android with arm64 in the form of (note, the taint is unrelated):

    [ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
    [ 4134.820925] Mem abort info:
    [ 4134.901283] Exception class = DABT (current EL), IL = 32 bits
    [ 4135.016736] SET = 0, FnV = 0
    [ 4135.119820] EA = 0, S1PTW = 0
    [ 4135.201431] Data abort info:
    [ 4135.301388] ISV = 0, ISS = 0x00000021
    [ 4135.359599] CM = 0, WnR = 0
    [ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
    [ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
    [ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
    [ 4135.674610] Modules linked in:
    [ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1
    [ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
    [ 4135.731599] PC is at bpf_prog_add+0x20/0x68
    [ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
    [ 4135.751788] pc : [] lr : [] pstate: 60400145
    [ 4135.769062] sp : ffffff801d4e3ce0
    [...]
    [ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
    [ 4136.273746] Call trace:
    [...]
    [ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
    [ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
    [ 4136.479241] [] bpf_prog_add+0x20/0x68
    [ 4136.491767] [] bpf_prog_inc+0x20/0x2c
    [ 4136.504536] [] bpf_obj_get_user+0x204/0x22c
    [ 4136.518746] [] SyS_bpf+0x5a8/0x1a88

    Android's netd was basically pinning the uid cookie BPF map in BPF
    fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
    again resulting in above panic. Issue is that the map was wrongly
    identified as a prog! Above kernel was compiled with clang 4.0,
    and it turns out that clang decided to merge the bpf_prog_iops and
    bpf_map_iops into a single memory location, such that the two i_ops
    could then not be distinguished anymore.

    Reason for this miscompilation is that clang has the more aggressive
    -fmerge-all-constants enabled by default. In fact, clang source code
    has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
    to do so:

    Pointers with different bases cannot represent the same object.
    (Note that clang defaults to -fmerge-all-constants, which can
    lead to inconsistent results for comparisons involving the address
    of a constant; this generally doesn't matter in practice.)

    The issue never appeared with gcc however, since gcc does not enable
    -fmerge-all-constants by default and even *explicitly* states in
    it's option description that using this flag results in non-conforming
    behavior, quote from man gcc:

    Languages like C or C++ require each variable, including multiple
    instances of the same variable in recursive calls, to have distinct
    locations, so using this option results in non-conforming behavior.

    There are also various clang bug reports open on that matter [1],
    where clang developers acknowledge the non-conforming behavior,
    and refer to disabling it with -fno-merge-all-constants. But even
    if this gets fixed in clang today, there are already users out there
    that triggered this. Thus, fix this issue by explicitly adding
    -fno-merge-all-constants to the kernel's Makefile to generically
    disable this optimization, since potentially other places in the
    kernel could subtly break as well.

    Note, there is also a flag called -fmerge-constants (not supported
    by clang), which is more conservative and only applies to strings
    and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
    gcc's code, the two flags -fmerge-{all-,}constants share the same
    variable internally, so when disabling it via -fno-merge-all-constants,
    then we really don't merge any const data (e.g. strings), and text
    size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).

    $ gcc -fverbose-asm -O2 foo.c -S -o foo.S
    -> foo.S lists -fmerge-constants under options enabled
    $ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
    -> foo.S doesn't list -fmerge-constants under options enabled
    $ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
    -> foo.S lists -fmerge-constants under options enabled

    Thus, as a workaround we need to set both -fno-merge-all-constants
    *and* -fmerge-constants in the Makefile in order for text size to
    stay as is.

    [1] https://bugs.llvm.org/show_bug.cgi?id=18538

    Reported-by: Prasad Sodagudi
    Signed-off-by: Daniel Borkmann
    Cc: Linus Torvalds
    Cc: Chenbo Feng
    Cc: Richard Smith
    Cc: Chandler Carruth
    Cc: linux-kernel@vger.kernel.org
    Tested-by: Prasad Sodagudi
    Acked-by: Alexei Starovoitov
    Signed-off-by: Alexei Starovoitov
    Signed-off-by: Greg Kroah-Hartman

    Daniel Borkmann
     

24 Mar, 2018

1 commit


21 Mar, 2018

1 commit


19 Mar, 2018

1 commit


15 Mar, 2018

6 commits

  • Greg Kroah-Hartman
     
  • commit d5028ba8ee5a18c9d0bb926d883c28b370f89009 upstream.

    Disable retpoline validation in objtool if your compiler sucks, and otherwise
    select the validation stuff for CONFIG_RETPOLINE=y (most builds would already
    have it set due to ORC).

    Signed-off-by: Peter Zijlstra (Intel)
    Acked-by: Thomas Gleixner
    Cc: Andy Lutomirski
    Cc: Arjan van de Ven
    Cc: Borislav Petkov
    Cc: Dan Williams
    Cc: Dave Hansen
    Cc: David Woodhouse
    Cc: Greg Kroah-Hartman
    Cc: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Peter Zijlstra
     
  • commit cfe17c9bbe6a673fdafdab179c32b355ed447f66 upstream.

    Geert reported commit ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before
    incl. arch Makefile") broke cross-compilation using a cross-compiler
    that supports less compiler options than the host compiler.

    For example,

    cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"

    This problem happens on architectures that setup CROSS_COMPILE in their
    arch/*/Makefile.

    Move the cc-option and cc-disable-warning back to the original position,
    but keep the Clang target options untouched.

    Fixes: ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before incl. arch Makefile")
    Reported-by: Geert Uytterhoeven
    Signed-off-by: Masahiro Yamada
    Tested-by: Geert Uytterhoeven
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • commit ae6b289a37890909fea0e4a1666e19377fa0ed2c upstream.

    Set the clang KBUILD_CFLAGS up before including arch/ Makefiles,
    so that ld-options (etc.) can work correctly.

    This fixes errors with clang such as ld-options trying to CC
    against your host architecture, but LD trying to link against
    your target architecture.

    Signed-off-by: Chris Fries
    Signed-off-by: Nick Desaulniers
    Reviewed-by: Matthias Kaehlcke
    Tested-by: Matthias Kaehlcke
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Chris Fries
     
  • commit 2c1f4f125159f10521944cea23e33a00fcf85ede upstream.

    The top Makefile is divided into some sections such as mixed targets,
    config targets, build targets, etc.

    When we build mixed targets, Kbuild just invokes submake to process
    them one by one. In this case, compiler-related variables like CC,
    KBUILD_CFLAGS, etc. are unneeded.

    Check what kind of targets we are building first, and parse variables
    for building only when necessary.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • commit ba634eceb535d95e87ef09caae7814b3687c6036 upstream.

    The first "_all" occurrence around line 120 is only visible when
    KBUILD_SRC is unset.

    If O=... is specified, the working directory is relocated, then the
    only second occurrence around line 193 is visible, that is not set
    to PHONY.

    Move the first one to an always visible place. This clarifies "_all"
    is our default target and it is always set to PHONY.

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Douglas Anderson
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     

11 Mar, 2018

1 commit