linux-stable.git/scripts, branch v5.4.60

recordmcount: Fix build failure on non arm64

2020-08-21T11:05:36+00:00

[ Upstream commit 3df14264ad9930733a8166e5bd0eccc1727564bb ]

Commit ea0eada45632 leads to the following build failure on powerpc:

  HOSTCC  scripts/recordmcount
scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in this function)
scripts/recordmcount.c:440: error: (Each undeclared identifier is reported only once
scripts/recordmcount.c:440: error: for each function it appears in.)
make[2]: *** [scripts/recordmcount] Error 1

Make sure R_AARCH64_CALL26 is always defined.

Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
Signed-off-by: Christophe Leroy 
Acked-by: Steven Rostedt (VMware) 
Acked-by: Gregory Herrero 
Cc: Gregory Herrero 
Link: https://lore.kernel.org/r/5ca1be21fa6ebf73203b45fd9aadd2bafb5e6b15.1597049145.git.christophe.leroy@csgroup.eu
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.

2020-08-19T06:15:57+00:00

[ Upstream commit ea0eada45632f4807b2f49de951072283e2d781c ]

Currently, if a section has a relocation to '_mcount' symbol, a new
__mcount_loc entry will be added whatever the relocation type is.
This is problematic when a relocation to '_mcount' is in the middle of a
section and is not a call for ftrace use.

Such relocation could be generated with below code for example:
    bool is_mcount(unsigned long addr)
    {
        return (target == (unsigned long) &_mcount);
    }

With this snippet of code, ftrace will try to patch the mcount location
generated by this code on module load and fail with:

    Call trace:
     ftrace_bug+0xa0/0x28c
     ftrace_process_locs+0x2f4/0x430
     ftrace_module_init+0x30/0x38
     load_module+0x14f0/0x1e78
     __do_sys_finit_module+0x100/0x11c
     __arm64_sys_finit_module+0x28/0x34
     el0_svc_common+0x88/0x194
     el0_svc_handler+0x38/0x8c
     el0_svc+0x8/0xc
    ---[ end trace d828d06b36ad9d59 ]---
    ftrace failed to modify
    [] 0xffffa2dbf3a3a41c
     actual:   66:a9:3c:90
    Initializing ftrace call sites
    ftrace record flags: 2000000
     (0)
    expected tramp: ffffa2dc6cf66724

So Limit the relocation type to R_AARCH64_CALL26 as in perl version of
recordmcount.

Fixes: af64d2aa872a ("ftrace: Add arm64 support to recordmcount")
Signed-off-by: Gregory Herrero 
Acked-by: Steven Rostedt (VMware) 
Link: https://lore.kernel.org/r/20200717143338.19302-1-gregory.herrero@oracle.com
Signed-off-by: Catalin Marinas 
Signed-off-by: Sasha Levin

scripts: add dummy report mode to add_namespace.cocci

2020-08-11T13:33:35+00:00

commit 55c7549819e438f40a3ef1d8ac5c38b73390bcb7 upstream.

When running `make coccicheck` in report mode using the
add_namespace.cocci file, it will fail for files that contain
MODULE_LICENSE. Those match the replacement precondition, but spatch
errors out as virtual.ns is not set.

In order to fix that, add the virtual rule nsdeps and only do search and
replace if that rule has been explicitly requested.

In order to make spatch happy in report mode, we also need a dummy rule,
as otherwise it errors out with "No rules apply". Using a script:python
rule appears unrelated and odd, but this is the shortest I could come up
with.

Adjust scripts/nsdeps accordingly to set the nsdeps rule when run trough
`make nsdeps`.

Suggested-by: Julia Lawall 
Fixes: c7c4e29fb5a4 ("scripts: add_namespace: Fix coccicheck failed")
Cc: YueHaibing 
Cc: jeyu@kernel.org
Cc: cocci@systeme.lip6.fr
Cc: stable@vger.kernel.org
Signed-off-by: Matthias Maennich 
Reported-by: Shuah Khan 
Acked-by: Julia Lawall 
Link: https://lore.kernel.org/r/20200604164145.173925-1-maennich@google.com
Signed-off-by: Greg Kroah-Hartman

scripts/gdb: fix lx-symbols 'gdb.error' while loading modules

2020-07-29T08:18:35+00:00

[ Upstream commit 7359608a271ce81803de148befefd309baf88c76 ]

Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
removed the 'name' field from 'struct module_sect_attr' triggering the
following error when invoking lx-symbols:

  (gdb) lx-symbols
  loading vmlinux
  scanning for modules in linux/build
  loading @0xffffffffc014f000: linux/build/drivers/net/tun.ko
  Python Exception  There is no member named name.:
  Error occurred in Python: There is no member named name.

This patch fixes the issue taking the module name from the 'struct
attribute'.

Fixes: ed66f991bb19 ("module: Refactor section attr into bin attribute")
Signed-off-by: Stefano Garzarella 
Signed-off-by: Andrew Morton 
Reviewed-by: Jan Kiszka 
Reviewed-by: Kieran Bingham 
Link: http://lkml.kernel.org/r/20200722102239.313231-1-sgarzare@redhat.com
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

scripts/decode_stacktrace: strip basepath from all paths

2020-07-29T08:18:35+00:00

[ Upstream commit d178770d8d21489abf5bafefcbb6d5243b482e9a ]

Currently the basepath is removed only from the beginning of the string.
When the symbol is inlined and there's multiple line outputs of
addr2line, only the first line would have basepath removed.

Change to remove the basepath prefix from all lines.

Fixes: 31013836a71e ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex")
Co-developed-by: Shik Chen 
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Shik Chen 
Signed-off-by: Andrew Morton 
Reviewed-by: Stephen Boyd 
Cc: Sasha Levin 
Cc: Nicolas Boichat 
Cc: Jiri Slaby 
Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.org
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

recordmcount: support >64k sections

2020-06-30T19:37:05+00:00

[ Upstream commit 4ef57b21d6fb49d2b25c47e4cff467a0c2c8b6b7 ]

When compiling a kernel with Clang and LTO, we need to run
recordmcount on vmlinux.o with a large number of sections, which
currently fails as the program doesn't understand extended
section indexes. This change adds support for processing binaries
with >64k sections.

Link: https://lkml.kernel.org/r/20200424193046.160744-1-samitolvanen@google.com
Link: https://lore.kernel.org/lkml/CAK7LNARbZhoaA=Nnuw0=gBrkuKbr_4Ng_Ei57uafujZf7Xazgw@mail.gmail.com/

Cc: Kees Cook 
Reviewed-by: Matt Helsley 
Signed-off-by: Sami Tolvanen 
Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Sasha Levin

kbuild: improve cc-option to clean up all temporary files

2020-06-30T19:37:05+00:00

[ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ]

When cc-option and friends evaluate compiler flags, the temporary file
$$TMP is created as an output object, and automatically cleaned up.
The actual file path of $$TMP is ..tmp, here  is the process
ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the
escape sequence of $$).

Such garbage files are cleaned up in most cases, but some compiler flags
create additional output files.

For example, -gsplit-dwarf creates a .dwo file.

When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of ..dwo files
left in the top of build directories. You may not notice them unless you
do 'ls -a', but the garbage files will increase every time you run 'make'.

This commit changes the temporary object path to .tmp_/tmp, and
removes .tmp_ directory when exiting. Separate build artifacts such
as *.dwo will be cleaned up all together because their file paths are
usually determined based on the base name of the object.

Another example is -ftest-coverage, which outputs the coverage data into
.gcno

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

scripts: headers_install: Exit with error on config leak

2020-06-24T15:50:33+00:00

[ Upstream commit 5967577231f9b19acd5a59485e9075964065bbe3 ]

Misuse of CONFIG_* in UAPI headers should result in an error. These config
options can be set in userspace by the user application which includes
these headers to control the APIs and structures being used in a kernel
which supports multiple targets.

Signed-off-by: Siddharth Gupta 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

mksysmap: Fix the mismatch of '.L' symbols in System.map

2020-06-24T15:50:19+00:00

[ Upstream commit 72d24accf02add25e08733f0ecc93cf10fcbd88c ]

When System.map was generated, the kernel used mksysmap to
filter the kernel symbols, but all the symbols with the
second letter 'L' in the kernel were filtered out, not just
the symbols starting with 'dot + L'.

For example:
ashimida@ubuntu:~/linux$ cat System.map |grep ' .L'
ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L'
ffff0000088028e0 t bLength_show
......
ffff0000092e0408 b PLLP_OUTC_lock
ffff0000092e0410 b PLLP_OUTA_lock

The original intent should be to filter out all local symbols
starting with '.L', so the dot should be escaped.

Fixes: 00902e984732 ("mksysmap: Add h8300 local symbol pattern")
Signed-off-by: ashimida 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin

bpf: Support llvm-objcopy for vmlinux BTF

2020-06-17T14:40:20+00:00

commit 90ceddcb495008ac8ba7a3dce297841efcd7d584 upstream.

Simplify gen_btf logic to make it work with llvm-objcopy. The existing
'file format' and 'architecture' parsing logic is brittle and does not
work with llvm-objcopy/llvm-objdump.

'file format' output of llvm-objdump>=11 will match GNU objdump, but
'architecture' (bfdarch) may not.

.BTF in .tmp_vmlinux.btf is non-SHF_ALLOC. Add the SHF_ALLOC flag
because it is part of vmlinux image used for introspection. C code
can reference the section via linker script defined __start_BTF and
__stop_BTF. This fixes a small problem that previous .BTF had the
SHF_WRITE flag (objcopy -I binary -O elf* synthesized .data).

Additionally, `objcopy -I binary` synthesized symbols
_binary__btf_vmlinux_bin_start and _binary__btf_vmlinux_bin_stop (not
used elsewhere) are replaced with more commonplace __start_BTF and
__stop_BTF.

Add 2>/dev/null because GNU objcopy (but not llvm-objcopy) warns
"empty loadable segment detected at vaddr=0xffffffff81000000, is this intentional?"

We use a dd command to change the e_type field in the ELF header from
ET_EXEC to ET_REL so that lld will accept .btf.vmlinux.bin.o.  Accepting
ET_EXEC as an input file is an extremely rare GNU ld feature that lld
does not intend to support, because this is error-prone.

The output section description .BTF in include/asm-generic/vmlinux.lds.h
avoids potential subtle orphan section placement issues and suppresses
--orphan-handling=warn warnings.

Fixes: df786c9b9476 ("bpf: Force .BTF section start to zero when dumping from vmlinux")
Fixes: cb0cc635c7a9 ("powerpc: Include .BTF section")
Reported-by: Nathan Chancellor 
Signed-off-by: Fangrui Song 
Signed-off-by: Daniel Borkmann 
Tested-by: Stanislav Fomichev 
Tested-by: Andrii Nakryiko 
Reviewed-by: Stanislav Fomichev 
Reviewed-by: Kees Cook 
Acked-by: Andrii Nakryiko 
Acked-by: Michael Ellerman  (powerpc)
Link: https://github.com/ClangBuiltLinux/linux/issues/871
Link: https://lore.kernel.org/bpf/20200318222746.173648-1-maskray@google.com
Signed-off-by: Maria Teguiani 
Tested-by: Matthias Maennich 
Signed-off-by: Greg Kroah-Hartman