29 Apr, 2020
1 commit
-
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
(cherry picked from commit e33a814e772cdc36436c8c188d8c42d019fda639)
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
05 Nov, 2019
1 commit
-
The nsdeps script passes a list of the module source files to
generate_deps_for_ns() as a space delimited string named $mod_source_files,
which then passes it to spatch. But since $mod_source_files is not encased
in quotes, each source file in that string is treated as a separate shell
function argument (as $2, $3, $4, etc.). However, the spatch invocation
only refers to $2, so only the first file out of $mod_source_files is
processed by spatch.This causes problems (namely, the MODULE_IMPORT_NS() statement doesn't
get inserted) when a module is composed of many source files and the
"main" module file containing the MODULE_LICENSE() statement is not the
first file listed in $mod_source_files. Fix this by encasing
$mod_source_files in quotes so that the entirety of the string is
treated as a single argument and can be referred to as $2.In addition, put quotes in the variable assignment of mod_source_files
to prevent any shell interpretation and field splitting.Reviewed-by: Masahiro Yamada
Acked-by: Matthias Maennich
Signed-off-by: Jessica Yu
26 Oct, 2019
1 commit
-
Pull modules fixes from Jessica Yu:
- Revert __ksymtab_$namespace.$symbol naming scheme back to
__ksymtab_$symbol, as it was causing issues with depmod.Instead, have modpost extract a symbol's namespace from __kstrtabns
and __ksymtab_strings.- Fix `make nsdeps` for out of tree kernel builds (make O=...) caused
by unescaped '/'.Use a different sed delimiter to avoid this problem.
* tag 'modules-for-v5.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
scripts/nsdeps: use alternative sed delimiter
symbol namespaces: revert to previous __ksymtab name scheme
modpost: make updating the symbol namespace explicit
modpost: delegate updating namespaces to separate function
23 Oct, 2019
1 commit
-
When doing an out of tree build with O=, the nsdeps script constructs
the absolute pathname of the module source file so that it can insert
MODULE_IMPORT_NS statements in the right place. However, ${srctree}
contains an unescaped path to the source tree, which, when used in a sed
substitution, makes sed complain:++ sed 's/[^ ]* *//home/jeyu/jeyu-linux\/&/g'
sed: -e expression #1, char 12: unknown option to `s'The sed substitution command 's' ends prematurely with the forward
slashes in the pathname, and sed errors out when it encounters the 'h',
which is an invalid sed substitution option. To avoid escaping forward
slashes ${srctree}, we can use '|' as an alternative delimiter for
sed instead to avoid this error.Reviewed-by: Masahiro Yamada
Reviewed-by: Matthias Maennich
Tested-by: Matthias Maennich
Signed-off-by: Jessica Yu
21 Oct, 2019
1 commit
-
…/masahiroy/linux-kbuild
Pull more Kbuild fixes from Masahiro Yamada:
- fix a bashism of setlocalversion
- do not use the too new --sort option of tar
* tag 'kbuild-fixes-v5.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kheaders: substituting --sort in archive creation
scripts: setlocalversion: fix a bashism
kbuild: update comment about KBUILD_ALLDIRS
19 Oct, 2019
2 commits
-
Currently lx-symbols assumes that module text is always located at
module->core_layout->base, but s390 uses the following layout:+------+ core_layout->base
| GOT |
+------+ core_layout->base + module->arch->plt_offset
| PLT |
+------+ core_layout->base + module->arch->plt_offset +
| TEXT | module->arch->plt_size
+------+Therefore, when trying to debug modules on s390, all the symbol
addresses are skewed by plt_offset + plt_size.Fix by adding plt_offset + plt_size to module_addr in
load_module_symbols().Link: http://lkml.kernel.org/r/20191017085917.81791-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 -
When CONFIG_PRINTK_CALLER is set, struct printk_log contains an
additional member caller_id. This affects the offset of the log text.
Account for this by using the type information from gdb to determine all
the offsets instead of using hardcoded values.This fixes following error:
(gdb) lx-dmesg
Python Exception embedded null character:
Error occurred in Python command: embedded null characterThe read_u* utility functions now take an offset argument to make them
easier to use.Link: http://lkml.kernel.org/r/20191011142500.2339-1-joel.colledge@linbit.com
Signed-off-by: Joel Colledge
Reviewed-by: Jan Kiszka
Cc: Kieran Bingham
Cc: Leonard Crestez
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
18 Oct, 2019
4 commits
-
The introduction of Symbol Namespaces changed the naming schema of the
__ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol.That caused some breakages in tools that depend on the name layout in
either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod
would not be able to read System.map without a patch to support symbol
namespaces. A warning reported by depmod for namespaced symbols would
look likedepmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks
In order to address this issue, revert to the original naming scheme and
rather read the __kstrtabns_ entries and their corresponding
values from __ksymtab_strings to update the namespace values for
symbols. After having read all symbols and handled them in
handle_modversions(), the symbols are created. In a second pass, read
the __kstrtabns_ entries and update the namespaces accordingly.Fixes: 8651ec01daed ("module: add support for symbol namespaces.")
Reported-by: Stefan Wahren
Suggested-by: Masahiro Yamada
Acked-by: Will Deacon
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Masahiro Yamada
Signed-off-by: Matthias Maennich
Signed-off-by: Jessica Yu -
Setting the symbol namespace of a symbol within sym_add_exported feels
displaced and lead to issues in the current implementation of symbol
namespaces. This patch makes updating the namespace an explicit call to
decouple it from adding a symbol to the export list.Acked-by: Will Deacon
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Masahiro Yamada
Signed-off-by: Matthias Maennich
Signed-off-by: Jessica Yu -
Let the function 'sym_update_namespace' take care of updating the
namespace for a symbol. While this currently only replaces one single
location where namespaces are updated, in a following patch, this
function will get more call sites.The function signature is intentionally close to sym_update_crc and
taking the name by char* seems like unnecessary work as the symbol has
to be looked up again. In a later patch of this series, this concern
will be addressed.This function ensures that symbol::namespace is either NULL or has a
valid non-empty value. Previously, the empty string was considered 'no
namespace' as well and this lead to confusion.Acked-by: Will Deacon
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Masahiro Yamada
Signed-off-by: Matthias Maennich
Signed-off-by: Jessica Yu -
While it is useful for new drivers to use devm_platform_ioremap_resource,
this script is currently used to spam maintainers, often updating very
old drivers. The net benefit is the removal of 2 lines of code in the
driver but the review load for the maintainers is huge. As of now, more
that 560 patches have been sent, some of them obviously broken, as in:https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/
Remove the script to reduce the spam.
Signed-off-by: Alexandre Belloni
Acked-by: Julia Lawall
Signed-off-by: Linus Torvalds
15 Oct, 2019
1 commit
-
Fix bashism reported by checkbashisms by using only one '=':
possible bashism in scripts/setlocalversion line 96 (should be 'b = a'):
if [ "`hg log -r . --template '{latesttagdistance}'`" == "1" ]; thenFixes: 38b3439d84f4 ("setlocalversion: update mercurial tag parsing")
Signed-off-by: Randy Dunlap
Cc: Mike Crowe
Signed-off-by: Masahiro Yamada
14 Oct, 2019
1 commit
-
Pull tracing fixes from Steven Rostedt:
"A few tracing fixes:- Remove lockdown from tracefs itself and moved it to the trace
directory. Have the open functions there do the lockdown checks.- Fix a few races with opening an instance file and the instance
being deleted (Discovered during the lockdown updates). Kept
separate from the clean up code such that they can be backported to
stable easier.- Clean up and consolidated the checks done when opening a trace
file, as there were multiple checks that need to be done, and it
did not make sense having them done in each open instance.- Fix a regression in the record mcount code.
- Small hw_lat detector tracer fixes.
- A trace_pipe read fix due to not initializing trace_seq"
* tag 'trace-v5.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Initialize iter->seq after zeroing in tracing_read_pipe()
tracing/hwlat: Don't ignore outer-loop duration when calculating max_latency
tracing/hwlat: Report total time spent in all NMIs during the sample
recordmcount: Fix nop_mcount() function
tracing: Do not create tracefs files if tracefs lockdown is in effect
tracing: Add locked_down checks to the open calls of files created for tracefs
tracing: Add tracing_check_open_get_tr()
tracing: Have trace events system open call tracing_open_generic_tr()
tracing: Get trace_array reference for available_tracers files
ftrace: Get a reference counter for the trace_array on filter files
tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")
13 Oct, 2019
1 commit
-
The removal of the longjmp code in recordmcount.c mistakenly made the return
of make_nop() being negative an exit of nop_mcount(). It should not exit the
routine, but instead just not process that part of the code. By exiting with
an error code, it would cause the update of recordmcount to fail some files
which would fail the build if ftrace function tracing was enabled.Link: http://lkml.kernel.org/r/20191009110538.5909fec6@gandalf.local.home
Reported-by: Uwe Kleine-König
Tested-by: Uwe Kleine-König
Fixes: 3f1df12019f3 ("recordmcount: Rewrite error/success handling")
Signed-off-by: Steven Rostedt (VMware)
12 Oct, 2019
1 commit
-
Pull module fixes from Jessica Yu:
"Code cleanups and kbuild/namespace related fixups from Masahiro.Most importantly, it fixes a namespace-related modpost issue for
external module builds- Fix broken external module builds due to a modpost bug in
read_dump(), where the namespace was not being strdup'd and
sym->namespace would be set to bogus data.- Various namespace-related kbuild fixes and cleanups thanks to
Masahiro Yamada"* tag 'modules-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
doc: move namespaces.rst from kbuild/ to core-api/
nsdeps: make generated patches independent of locale
nsdeps: fix hashbang of scripts/nsdeps
kbuild: fix build error of 'make nsdeps' in clean tree
module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol conflict
modpost: fix broken sym->namespace for external module builds
module: swap the order of symbol.namespace
scripts: add_namespace: Fix coccicheck failed
08 Oct, 2019
4 commits
-
scripts/nsdeps automatically generates a patch to add MODULE_IMPORT_NS
tags, and what is nicer, it sorts the lines alphabetically with the
'sort' command. However, the output from the 'sort' command depends on
locale.For example, I got this:
$ { echo usbstorage; echo usb_storage; } | LANG=en_US.UTF-8 sort
usbstorage
usb_storage
$ { echo usbstorage; echo usb_storage; } | LANG=C sort
usb_storage
usbstorageSo, this means people might potentially send different patches.
This kind of issue was reported in the past, for example,
commit f55f2328bb28 ("kbuild: make sorting initramfs contents
independent of locale").Adding 'LANG=C' is a conventional way of fixing when a deterministic
result is desirable.I added 'LANG=C' very close to the 'sort' command since changing
locale affects the language of error messages etc. We should respect
users' choice as much as possible.Reviewed-by: Matthias Maennich
Signed-off-by: Masahiro Yamada
Signed-off-by: Jessica Yu -
This script does not use bash-extension. I am guessing this hashbang
was copied from scripts/coccicheck, which really uses bash-extension./bin/sh is enough for this script.
Reviewed-by: Matthias Maennich
Signed-off-by: Masahiro Yamada
Signed-off-by: Jessica Yu -
Currently, external module builds produce tons of false-positives:
WARNING: module uses symbol from namespace , but does not import it.
Here, the part shows a random string.
When you build external modules, the symbol info of vmlinux and
in-kernel modules are read from $(objtree)/Module.symvers, but
read_dump() is buggy in multiple ways:[1] When the modpost is run for vmlinux and in-kernel modules,
sym_extract_namespace() allocates memory for the namespace. On the
other hand, read_dump() does not, then sym->namespace will point to
somewhere in the line buffer of get_next_line(). The data in the
buffer will be replaced soon, and sym->namespace will end up with
pointing to unrelated data. As a result, check_exports() will show
random strings in the warning messages.[2] When there is no namespace, sym_extract_namespace() returns NULL.
On the other hand, read_dump() sets namespace to an empty string "".
(but, it will be later replaced with unrelated data due to bug [1].)
The check_exports() shows a warning unless exp->namespace is NULL,
so every symbol read from read_dump() emits the warning, which is
mostly false positive.To address [1], sym_add_exported() calls strdup() for s->namespace.
The namespace from sym_extract_namespace() must be freed to avoid
memory leak.For [2], I changed the if-conditional in check_exports().
This commit also fixes sym_add_exported() to set s->namespace correctly
when the symbol is preloaded.Reviewed-by: Matthias Maennich
Signed-off-by: Masahiro Yamada
Signed-off-by: Jessica Yu -
Currently, EXPORT_SYMBOL_NS(_GPL) constructs the kernel symbol as
follows:__ksymtab_SYMBOL.NAMESPACE
The sym_extract_namespace() in modpost allocates memory for the part
SYMBOL.NAMESPACE when '.' is contained. One problem is that the pointer
returned by strdup() is lost because the symbol name will be copied to
malloc'ed memory by alloc_symbol(). No one will keep track of the
pointer of strdup'ed memory.sym->namespace still points to the NAMESPACE part. So, you can free it
with complicated code like this:free(sym->namespace - strlen(sym->name) - 1);
It complicates memory free.
To fix it elegantly, I swapped the order of the symbol and the
namespace as follows:__ksymtab_NAMESPACE.SYMBOL
then, simplified sym_extract_namespace() so that it allocates memory
only for the NAMESPACE part.I prefer this order because it is intuitive and also matches to major
languages. For example, NAMESPACE::NAME in C++, MODULE.NAME in Python.Reviewed-by: Matthias Maennich
Signed-off-by: Masahiro Yamada
Signed-off-by: Jessica Yu