29 Jul, 2020
2 commits
-
[ 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 -
[ 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
01 Jul, 2020
2 commits
-
[ 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 -
[ 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
.gcnoSigned-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
24 Jun, 2020
2 commits
-
[ 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 -
[ 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_lockThe 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
17 Jun, 2020
1 commit
-
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
27 May, 2020
3 commits
-
[ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ]
When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend
time collecting and writing the dwarf sections to the temporary output
files. kallsyms does not need this information, and leaving it off
halves their linking time. This is especially noticeable without
CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still
need those details.Refactor the BTF and kallsyms generation stages slightly for more
regularized temporary names. Skip debug during kallsyms links.
Additionally move "info BTF" to the correct place since commit
8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct
reporting"), which added "info LD ..." to vmlinux_link calls.For a full debug info build with BTF, my link time goes from 1m06s to
0m54s, saving about 12 seconds, or 18%.Signed-off-by: Kees Cook
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook
Signed-off-by: Sasha Levin -
[ Upstream commit 50e36be1fb9572b2e4f2753340bdce3116bf2ce7 ]
The current implementations of the rb_first() and rb_last() gdb
functions have a variable that references itself in its instanciation,
which causes the function to throw an error if a specific condition on
the argument is met. The original author rather intended to reference
the argument and made a typo. Referring the argument instead makes the
function work as intended.Signed-off-by: Aymeric Agon-Rambosson
Signed-off-by: Andrew Morton
Reviewed-by: Stephen Boyd
Cc: Jan Kiszka
Cc: Kieran Bingham
Cc: Douglas Anderson
Cc: Nikolay Borisov
Cc: Jackie Liu
Cc: Jason Wessel
Link: http://lkml.kernel.org/r/20200427051029.354840-1-aymeric.agon@yandex.com
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin -
[ Upstream commit c7527373fe28f97d8a196ab562db5589be0d34b9 ]
Remove "params.h" include, which has been dropped in GCC 10.
Remove is_a_helper() macro, which is now defined in gimple.h, as seen
when running './scripts/gcc-plugin.sh g++ g++ gcc':In file included from :1:
./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’
852 | inline bool is_a_helper::test(const_gimple gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./gcc-plugins/gcc-common.h:125,
from :1:
/usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here
1037 | is_a_helper ::test (const gimple *gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid
meaningless warnings from error() formats used by plugins:scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’:
scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag]
253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Signed-off-by: Frédéric Pierret (fepitre)
Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org
[kees: include -Wno-format-diag for plugin builds]
Signed-off-by: Kees Cook
Signed-off-by: Sasha Levin
14 May, 2020
1 commit
-
commit e08df079b23e2e982df15aa340bfbaf50f297504 upstream.
If the trapping instruction contains a ':', for a memory access through
segment registers for example, the sed substitution will insert the '*'
marker in the middle of the instruction instead of the line address:2b: 65 48 0f c7 0f cmpxchg16b %gs:*(%rdi)
Signed-off-by: Andrew Morton
Reviewed-by: Borislav Petkov
Link: http://lkml.kernel.org/r/20200419223653.GA31248@visor
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
10 May, 2020
1 commit
-
[ Upstream commit e461bc9f9ab105637b86065d24b0b83f182d477c ]
Sed broke on some strings as it used colon as a separator.
I made it more robust by using \001, which is legit POSIX AFAIK.E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01"
failed with: sed: -e expression #1, char 55: unknown option to `s'Signed-off-by: Jeremie Francois (on alpha)
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
02 May, 2020
1 commit
-
commit 3d4b2238684ac919394eba7fb51bb7eeeec6ab57 upstream.
Since commit 7a0496056064 ("kbuild: fix DT binding schema rule to detect
command line changes"), this rule is every time re-run even if you change
nothing.cmd_dtc takes one additional parameter to pass to the -O option of dtc.
We need to pass 'yaml' to if_changed_rule. Otherwise, cmd-check invoked
from if_changed_rule is false positive.Fixes: 7a0496056064 ("kbuild: fix DT binding schema rule to detect command line changes")
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
29 Apr, 2020
1 commit
-
[ Upstream commit 60969f02f07ae1445730c7b293c421d179da729c ]
There are a few items with wrong alignments. Solve them.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
08 Apr, 2020
1 commit
-
[ Upstream commit 8cc4fd73501d9f1370c3eebb70cfe8cc9e24062b ]
When a compiler supports multiple architectures, some compiler features
can be dependent on the target architecture.This is typical for Clang, which supports multiple LLVM backends.
Even for GCC, we need to take care of biarch compiler cases.It is not a problem when we evaluate cc-option in Makefiles because
cc-option is tested against the flag in question + $(KBUILD_CFLAGS).The cc-option in Kconfig, on the other hand, does not accumulate
tested flags. Due to this simplification, it could potentially test
cc-option against a different target.At first, Kconfig always evaluated cc-option against the host
architecture.Since commit e8de12fb7cde ("kbuild: Check for unknown options with
cc-option usage in Kconfig and clang"), in case of cross-compiling
with Clang, the target triple is correctly passed to Kconfig.The case with biarch GCC (and native build with Clang) is still not
handled properly. We need to pass some flags to specify the target
machine bit.Due to the design, all the macros in Kconfig are expanded in the
parse stage, where we do not know the target bit size yet.For example, arch/x86/Kconfig allows a user to toggle CONFIG_64BIT.
If a compiler flag -foo depends on the machine bit, it must be tested
twice, one with -m32 and the other with -m64.However, -m32/-m64 are not always recognized. So, this commits adds
m64-flag and m32-flag macros. They expand to -m32, -m64, respectively
if supported. Or, they expand to an empty string if unsupported.The typical usage is like this:
config FOO
bool
default $(cc-option,$(m64-flag) -foo) if 64BIT
default $(cc-option,$(m32-flag) -foo)This is clumsy, but there is no elegant way to handle this in the
current static macro expansion.There was discussion for static functions vs dynamic functions.
The consensus was to go as far as possible with the static functions.
(https://lkml.org/lkml/2018/3/2/22)Signed-off-by: Masahiro Yamada
Tested-by: George Spelvin
Reviewed-by: Nathan Chancellor
Signed-off-by: Sasha Levin
01 Apr, 2020
1 commit
-
commit e33a814e772cdc36436c8c188d8c42d019fda639 upstream.
gcc 10 will default to -fno-common, which causes this error at link
time:(.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here
This is because both dtc-lexer as well as dtc-parser define the same
global symbol yyloc. Before with -fcommon those were merged into one
defintion. The proper solution would be to to mark this as "extern",
however that leads to:dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls]
26 | extern YYLTYPE yylloc;
| ^~~~~~
In file included from dtc-lexer.l:24:
dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here
127 | extern YYLTYPE yylloc;
| ^~~~~~
cc1: all warnings being treated as errorswhich means the declaration is completely redundant and can just be
dropped.Signed-off-by: Dirk Mueller
Signed-off-by: David Gibson
[robh: cherry-pick from upstream]
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
25 Mar, 2020
3 commits
-
commit 5190044c2965514a973184ca68ef5fad57a24670 upstream.
In order to preserve backwards compatability with kmod tools, we have to
move the namespace field in Module.symvers last, as the depmod -e -E
option looks at the first three fields in Module.symvers to check symbol
versions (and it's expected they stay in the original order of crc,
symbol, module).In addition, update an ancient comment above read_dump() in modpost that
suggested that the export type field in Module.symvers was optional. I
suspect that there were historical reasons behind that comment that are
no longer accurate. We have been unconditionally printing the export
type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now.Fix up read_dump() to treat each field as non-optional. I suspect the
original read_dump() code treated the export field as optional in order
to support pre
Reviewed-by: Matthias Maennich
Reviewed-by: Lucas De Marchi
Signed-off-by: Jessica Yu
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman -
commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/887
Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84
Signed-off-by: Nathan Chancellor
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 611d61f9ac99dc9e1494473fb90117a960a89dfa ]
This makes the script more convenient to run.
Signed-off-by: Jonathan Neuschäfer
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
05 Mar, 2020
3 commits
-
commit 7ecaf069da52e472d393f03e79d721aabd724166 upstream.
Currently, some sanity checks for uapi headers are done by
scripts/headers_check.pl, which is wired up to the 'headers_check'
target in the top Makefile.It is true compiling headers has better test coverage, but there
are still several headers excluded from the compile test. I like
to keep headers_check.pl for a while, but we can delete a lot of
code by moving the build rule to usr/include/Makefile.Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman -
commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream.
There are both positive and negative options about this feature.
At first, I thought it was a good idea, but actually Linus stated a
negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
is ugly and annoying.The baseline I'd like to keep is the compile-test of uapi headers.
(Otherwise, kernel developers have no way to ensure the correctness
of the exported headers.)I will maintain a small build rule in usr/include/Makefile.
Remove the other header test functionality.Signed-off-by: Masahiro Yamada
[ added to 5.4.y due to start of build warnings from backported patches
because of this feature - gregkh]
Signed-off-by: Greg Kroah-Hartman -
commit 7a04960560640ac5b0b89461f7757322b57d0c7a upstream.
This if_change_rule is not working properly; it cannot detect any
command line change.The reason is because cmd-check in scripts/Kbuild.include compares
$(cmd_$@) and $(cmd_$1), but cmd_dtc_dt_yaml does not exist here.For if_change_rule to work properly, the stem part of cmd_* and rule_*
must match. Because this cmd_and_fixdep invokes cmd_dtc, this rule must
be named rule_dtc.Fixes: 4f0e3a57d6eb ("kbuild: Add support for DT binding schema checks")
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
24 Feb, 2020
4 commits
-
[ Upstream commit 2a67a6ccb01f21b854715d86ff6432a18b97adb3 ]
When trying to compile with CONFIG_DEBUG_INFO_BTF enabled, I got this
error:% make -s
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make[3]: *** [vmlinux] Error 1Compiling again without -s shows the true error (that pahole is
missing), but since this is fatal, we should show the error
unconditionally on stderr as well, not silence it using the `info`
function. With this patch:% make -s
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make[3]: *** [vmlinux] Error 1Signed-off-by: Chris Down
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20200122000110.GA310073@chrisdown.name
Signed-off-by: Sasha Levin -
[ Upstream commit 3bed1b7b9d79ca40e41e3af130931a3225e951a3 ]
Currently, -E (stop after the preprocessing stage) is used to check
whether the given compiler flag is supported.While it is faster than -S (or -c), it can be false-positive. You need
to run the compilation proper to check the flag more precisely.For example, -E and -S disagree about the support of
"--param asan-instrument-allocas=1".$ gcc -Werror --param asan-instrument-allocas=1 -E -x c /dev/null -o /dev/null
$ echo $?
0$ gcc -Werror --param asan-instrument-allocas=1 -S -x c /dev/null -o /dev/null
cc1: error: invalid --param name ‘asan-instrument-allocas’; did you mean ‘asan-instrument-writes’?
$ echo $?
1Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit 88fe89a47153facd8cb2d06d5c8727f7224c43c2 ]
Bartosz Golaszewski reports that when "make {menu,n,g,x}config" fails
due to missing packages, a temporary file is left over, which is not
ignored by git.For example, if GTK+ is not installed:
$ make gconfig
*
* Unable to find the GTK+ installation. Please make sure that
* the GTK+ 2.0 development package is correctly installed.
* You need gtk+-2.0 gmodule-2.0 libglade-2.0
*
scripts/kconfig/Makefile:208: recipe for target 'scripts/kconfig/gconf-cfg' failed
make[1]: *** [scripts/kconfig/gconf-cfg] Error 1
Makefile:567: recipe for target 'gconfig' failed
make: *** [gconfig] Error 2
$ git status
HEAD detached at v5.4
Untracked files:
(use "git add ..." to include in what will be committed)scripts/kconfig/gconf-cfg.tmp
nothing added to commit but untracked files present (use "git add" to track)
This is because the check scripts are run with filechk, which misses
to clean up the temporary file on failure.When the line
{ $(filechk_$(1)); } > $@.tmp;
... fails, it exits immediately due to the 'set -e'. Use trap to make
sure to delete the temporary file on exit.For extra safety, I replaced $@.tmp with $(dot-target).tmp to make it
a hidden file.Reported-by: Bartosz Golaszewski
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit c8fb7d7e48d11520ad24808cfce7afb7b9c9f798 ]
Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5)
produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y,
which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency.This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs
CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the
value of CONFIG_EFI is calculated.When this happens, the has_changed flag should be set.
Currently, it takes the result from the last iteration. It should
accumulate all the results of the loop.Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig")
Reported-by: Vincenzo Frascino
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
11 Feb, 2020
1 commit
-
commit 1630146db2111412e7524d05d812ff8f2c75977e upstream.
scripts/find-unused-docs.sh invokes scripts/kernel-doc to find out if a
source file contains kerneldoc or not.However, as it passes the no longer supported "-text" option to
scripts/kernel-doc, the latter prints out its help text, causing all
files to be considered containing kerneldoc.Get rid of these false positives by removing the no longer supported
"-text" option from the scripts/kernel-doc invocation.Cc: stable@vger.kernel.org # 4.16+
Fixes: b05142675310d2ac ("scripts: kernel-doc: get rid of unused output formats")
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20200127093107.26401-1-geert+renesas@glider.be
Signed-off-by: Jonathan Corbet
Signed-off-by: Greg Kroah-Hartman
29 Jan, 2020
1 commit
-
commit 927d780ee371d7e121cea4fc7812f6ef2cea461c upstream.
Scenario 1, ARMv7
=================If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:00000230 :
230: b5f8 push {r3, r4, r5, r6, r7, lr}
232: b500 push {lr}
234: f7ff fffe bl 0
234: R_ARM_THM_CALL __gnu_mcount_nc
238: f240 0600 movw r6, #0
238: R_ARM_THM_MOVW_ABS_NC __gnu_mcount_nc
23c: f8d0 1180 ldr.w r1, [r0, #384] ; 0x180FTRACE currently is not able to deal with it:
WARNING: CPU: 0 PID: 0 at .../kernel/trace/ftrace.c:1979 ftrace_bug+0x1ad/0x230()
...
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.116-... #1
...
[] (unwind_backtrace) from [] (show_stack+0x11/0x14)
[] (show_stack) from [] (dump_stack+0x81/0xa8)
[] (dump_stack) from [] (warn_slowpath_common+0x69/0x90)
[] (warn_slowpath_common) from [] (warn_slowpath_null+0x17/0x1c)
[] (warn_slowpath_null) from [] (ftrace_bug+0x1ad/0x230)
[] (ftrace_bug) from [] (ftrace_process_locs+0x27d/0x444)
[] (ftrace_process_locs) from [] (ftrace_init+0x91/0xe8)
[] (ftrace_init) from [] (start_kernel+0x34b/0x358)
[] (start_kernel) from [] (0x308095)
---[ end trace cb88537fdc8fa200 ]---
ftrace failed to modify [] prealloc_fixed_plts+0x8/0x60
actual: 44:f2:e1:36
ftrace record flags: 0
(0) expected tramp: c03143e9Scenario 2, ARMv4T
==================ftrace: allocating 14435 entries in 43 pages
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:2029 ftrace_bug+0x204/0x310
CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.5 #1
Hardware name: Cirrus Logic EDB9302 Evaluation Board
[] (unwind_backtrace) from [] (show_stack+0x20/0x2c)
[] (show_stack) from [] (dump_stack+0x20/0x30)
[] (dump_stack) from [] (__warn+0xdc/0x104)
[] (__warn) from [] (warn_slowpath_null+0x4c/0x5c)
[] (warn_slowpath_null) from [] (ftrace_bug+0x204/0x310)
[] (ftrace_bug) from [] (ftrace_init+0x3b4/0x4d4)
[] (ftrace_init) from [] (start_kernel+0x20c/0x410)
[] (start_kernel) from [] ( (null))
---[ end trace 0506a2f5dae6b341 ]---
ftrace failed to modify
[] perf_trace_sys_exit+0x5c/0xe8
actual: 1e:ff:2f:e1
Initializing ftrace call sites
ftrace record flags: 0
(0)
expected tramp: c000fb24The analysis for this problem has been already performed previously,
refer to the link below.Fix the above problems by allowing only selected reloc types in
__mcount_loc. The list itself comes from the legacy recordmcount.pl
script.Link: https://lore.kernel.org/lkml/56961010.6000806@pengutronix.de/
Cc: stable@vger.kernel.org
Fixes: ed60453fa8f8 ("ARM: 6511/1: ftrace: add ARM support for C version of recordmcount")
Signed-off-by: Alexander Sverdlin
Acked-by: Steven Rostedt (VMware)
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
26 Jan, 2020
1 commit
-
commit df786c9b947639aedbc7bb44b5dae2a7824af360 upstream.
While trying to figure out why fentry_fexit selftest doesn't pass for me
(old pahole, broken BTF), I found out that my latest patch can break vmlinux
.BTF generation. objcopy preserves section start when doing --only-section,
so there is a chance (depending on where pahole inserts .BTF section) to
have leading empty zeroes. Let's explicitly force section offset to zero.Before:
$ objcopy --set-section-flags .BTF=alloc -O binary \
--only-section=.BTF vmlinux .btf.vmlinux.bin
$ xxd .btf.vmlinux.bin | head -n1
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................After:
$ objcopy --change-section-address .BTF=0 \
--set-section-flags .BTF=alloc -O binary \
--only-section=.BTF vmlinux .btf.vmlinux.bin
$ xxd .btf.vmlinux.bin | head -n1
00000000: 9feb 0100 1800 0000 0000 0000 80e1 1c00 ................
^BTF magicAs part of this change, I'm also dropping '2>/dev/null' from objcopy
invocation to be able to catch possible other issues (objcopy doesn't
produce any warnings for me anymore, it did before with --dump-section).Fixes: da5fb18225b4 ("bpf: Support pre-2.25-binutils objcopy for vmlinux BTF")
Signed-off-by: Stanislav Fomichev
Signed-off-by: Daniel Borkmann
Acked-by: John Fastabend
Cc: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20191127225759.39923-1-sdf@google.com
Signed-off-by: Greg Kroah-Hartman
18 Jan, 2020
2 commits
-
[ Upstream commit 8ffdc54b6f4cd718a45802e645bb853e3a46a078 ]
Cross compiling the x86 kernel on a non-x86 build machine produces
the following error when CONFIG_UNWINDER_ORC is enabled, regardless
of whether libelf-dev is installed or not.dpkg-checkbuilddeps: error: Unmet build dependencies: libelf-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)Since this is a build time dependency for a build tool, we need to
depend on the native version of libelf-dev so add the appropriate
annotation.Signed-off-by: Ard Biesheuvel
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
commit da5fb18225b49b97bb37c51bcbbb2990a507c364 upstream.
If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set,
.BTF section of vmlinux is empty and kernel will prohibit
BPF loading and return "in-kernel BTF is malformed".--dump-section argument to binutils' objcopy was added in version 2.25.
When using pre-2.25 binutils, BTF generation silently fails. Convert
to --only-section which is present on pre-2.25 binutils.Documentation/process/changes.rst states that binutils 2.21+
is supported, not sure those standards apply to BPF subsystem.v2:
* exit and print an error if gen_btf fails (John Fastabend)v3:
* resend with Andrii's Acked-by/Tested-by tagsFixes: 341dfcf8d78ea ("btf: expose BTF info through sysfs")
Signed-off-by: Stanislav Fomichev
Signed-off-by: Alexei Starovoitov
Tested-by: Andrii Nakryiko
Acked-by: Andrii Nakryiko
Cc: John Fastabend
Link: https://lore.kernel.org/bpf/20191127161410.57327-1-sdf@google.com
Signed-off-by: Greg Kroah-Hartman
12 Jan, 2020
2 commits
-
[ Upstream commit a11391b6f50689adb22c65df783e09143fafb794 ]
We've missed the dependency to rsync, so build fails on
minimal containers.Fixes: 59b2bd05f5f4 ("kbuild: add 'headers' target to build up uapi headers in usr/include")
Signed-off-by: Enrico Weigelt, metux IT consult
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit 272a72103012862e3a24ea06635253ead0b6e808 ]
NULL expressions are taken to always be true, as implemented by the
expr_is_yes() macro and by several other functions in expr.c. As such,
they ought to be valid inputs to expr_eq(), which compares two
expressions.Signed-off-by: Thomas Hebb
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
09 Jan, 2020
1 commit
-
commit a5b0dc5a46c221725c43bd9b01570239a4cd78b1 upstream.
I noticed that randconfig builds with gcc no longer produce a lot of
ccache hits, unlike with clang, and traced this back to plugins
now being enabled unconditionally if they are supported.I am now working around this by adding
export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler%
to my top-level Makefile. This changes the heuristic that ccache uses
to determine whether the plugins are the same after a 'make clean'.However, it also seems that being able to just turn off the plugins is
generally useful, at least for build testing it adds noticeable overhead
but does not find a lot of bugs additional bugs, and may be easier for
ccache users than my workaround.Fixes: 9f671e58159a ("security: Create "kernel hardening" config area")
Signed-off-by: Arnd Bergmann
Acked-by: Ard Biesheuvel
Reviewed-by: Masahiro Yamada
Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook
Signed-off-by: Greg Kroah-Hartman
05 Jan, 2020
2 commits
-
[ Upstream commit 21915eca088dc271c970e8351290e83d938114ac ]
build_initial_tok_table() overwrites unused sym_entry to shrink the
table size. Before the entry is overwritten, table[i].sym must be freed
since it is malloc'ed data.This fixes the 'definitely lost' report from valgrind. I ran valgrind
against x86_64_defconfig of v5.4-rc8 kernel, and here is the summary:[Before the fix]
LEAK SUMMARY:
definitely lost: 53,184 bytes in 2,874 blocks[After the fix]
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocksSigned-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin -
[ Upstream commit 067c650c456e758f933aaf87a202f841d34be269 ]
Using Makefile's wildcard with absolute path to detect
the presence of libyaml results in false-positive
detection when cross-compiling e.g. in yocto environment.
The latter results in build error:
| scripts/dtc/yamltree.o: In function `yaml_propval_int':
| yamltree.c: undefined reference to `yaml_sequence_start_event_initialize'
| yamltree.c: undefined reference to `yaml_emitter_emit'
| yamltree.c: undefined reference to `yaml_scalar_event_initialize'
...
Use pkg-config to locate libyaml to address this scenario.Signed-off-by: Pavel Modilaynen
[robh: silence stderr]
Signed-off-by: Rob Herring
Signed-off-by: Sasha Levin
16 Nov, 2019
1 commit
-
Pull arm64 fix from Will Deacon:
"One trivial fix for -rc8/final that ensures that the script used to
detect RELR relocation support in the toolchain works correctly when
$CC contains quotes. Although it fails safely (by failing to detect
the support when it exists), it would be nice to have this fixed in
5.4 given that it was only introduced in the last merge window.Summary:
- Handle CC variables containing quotes in tools-support-relr.sh
script"* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
scripts/tools-support-relr.sh: un-quote variables
13 Nov, 2019
1 commit
-
When the CC variable contains quotes, e.g. when using
ccache (make CC="ccache "), this script always
fails, so CONFIG_RELR is never enabled, even when the
toolchain supports this feature. Removing the /dev/null
redirect and invoking the script manually shows the issue:$ CC='/usr/bin/ccache clang' ./scripts/tools-support-relr.sh
./scripts/tools-support-relr.sh: 7: ./scripts/tools-support-relr.sh: /usr/bin/ccache clang: not foundFix this by un-quoting the variables.
Before:
$ make ARCH=arm64 CC='/usr/bin/ccache clang' LD=ld.lld \
NM=llvm-nm OBJCOPY=llvm-objcopy defconfig
$ grep RELR .config
CONFIG_ARCH_HAS_RELR=yWith this change:
$ make ARCH=arm64 CC='/usr/bin/ccache clang' LD=ld.lld \
NM=llvm-nm OBJCOPY=llvm-objcopy defconfig
$ grep RELR .config
CONFIG_TOOLS_SUPPORT_RELR=y
CONFIG_ARCH_HAS_RELR=y
CONFIG_RELR=yFixes: 5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
Reported-by: Dmitry Golovin
Reviewed-by: Nathan Chancellor
Reviewed-by: Masahiro Yamada
Link: https://github.com/ClangBuiltLinux/linux/issues/769
Cc: Peter Collingbourne
Signed-off-by: Ilie Halip
Signed-off-by: Will Deacon
09 Nov, 2019
1 commit
-
Pull modules fix from Jessica Yu:
"Fix `make nsdeps` for modules composed of multiple source files.Since $mod_source_files was not in quotes in the call to
generate_deps_for_ns(), not all the source files for a module were
being passed to spatch"* tag 'modules-for-v5.4-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
scripts/nsdeps: make sure to pass all module source files to spatch
07 Nov, 2019
1 commit
-
gcc's -freorder-blocks-and-partition option makes it group frequently
and infrequently used code in .text.hot and .text.unlikely sections
respectively. At least when building modules on s390, this option is
used by default.gdb assumes that all code is located in .text section, and that .text
section is located at module load address. With such modules this is no
longer the case: there is code in .text.hot and .text.unlikely, and
either of them might precede .text.Fix by explicitly telling gdb the addresses of code sections.
It might be tempting to do this for all sections, not only the ones in
the white list. Unfortunately, gdb appears to have an issue, when
telling it about e.g. loadable .note.gnu.build-id section causes it to
think that non-loadable .note.Linux section is loaded at address 0,
which in turn causes NULL pointers to be resolved to bogus symbols. So
keep using the white list approach for the time being.Link: http://lkml.kernel.org/r/20191028152734.13065-1-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich
Reviewed-by: Jan Kiszka
Cc: Kieran Bingham
Cc: Heiko Carstens
Cc: Vasily Gorbik
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
