user/sven/linux.git/scripts, branch v5.4.76

scripts/setlocalversion: make git describe output more reliable

2020-11-01T11:01:01Z

commit 548b8b5168c90c42e88f70fcf041b4ce0b8e7aa8 upstream. When building for an embedded target using Yocto, we're sometimes observing that the version string that gets built into vmlinux (and thus what uname -a reports) differs from the path under /lib/modules/ where modules get installed in the rootfs, but only in the length of the -gabc123def suffix. Hence modprobe always fails. The problem is that Yocto has the concept of "sstate" (shared state), which allows different developers/buildbots/etc. to share build artifacts, based on a hash of all the metadata that went into building that artifact - and that metadata includes all dependencies (e.g. the compiler used etc.). That normally works quite well; usually a clean build (without using any sstate cache) done by one developer ends up being binary identical to a build done on another host. However, one thing that can cause two developers to end up with different builds [and thus make one's vmlinux package incompatible with the other's kernel-dev package], which is not captured by the metadata hashing, is this `git describe`: The output of that can be affected by (1) git version: before 2.11 git defaulted to a minimum of 7, since 2.11 (git.git commit e6c587) the default is dynamic based on the number of objects in the repo (2) hence even if both run the same git version, the output can differ based on how many remotes are being tracked (or just lots of local development branches or plain old garbage) (3) and of course somebody could have a core.abbrev config setting in ~/.gitconfig So in order to avoid `uname -a` output relying on such random details of the build environment which are rather hard to ensure are consistent between developers and buildbots, make sure the abbreviated sha1 always consists of exactly 12 hex characters. That is consistent with the current rule for -stable patches, and is almost always enough to identify the head commit unambigously - in the few cases where it does not, the v5.4.3-00021- prefix would certainly nail it down. [Adapt to `` vs $() differences between 5.4 and upstream.] Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

scripts/dtc: only append to HOST_EXTRACFLAGS instead of overwriting

2020-10-07T06:01:29Z

[ Upstream commit efe84d408bf41975db8506d3a1cc02e794e2309c ] When building with $ HOST_EXTRACFLAGS=-g make the expectation is that host tools are built with debug informations. This however doesn't happen if the Makefile assigns a new value to the HOST_EXTRACFLAGS instead of appending to it. So use += instead of := for the first assignment. Fixes: e3fd9b5384f3 ("scripts/dtc: consolidate include path options in Makefile") Signed-off-by: Uwe Kleine-König Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

checkpatch: fix the usage of capture group ( ... )

2020-09-09T17:12:37Z

commit 13e45417cedbfc44b1926124b1846f5ee8c6ba4a upstream. The usage of "capture group (...)" in the immediate condition after `&&` results in `$1` being uninitialized. This issues a warning "Use of uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl line 2638". I noticed this bug while running checkpatch on the set of commits from v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in their commit message. This bug was introduced in the script by commit e518e9a59ec3 ("checkpatch: emit an error when there's a diff in a changelog"). It has been in the script since then. The author intended to store the match made by capture group in variable `$1`. This should have contained the name of the file as `[\w/]+` matched. However, this couldn't be accomplished due to usage of capture group and `$1` in the same regular expression. Fix this by placing the capture group in the condition before `&&`. Thus, `$1` can be initialized to the text that capture group matches thereby setting it to the desired and required value. Fixes: e518e9a59ec3 ("checkpatch: emit an error when there's a diff in a changelog") Signed-off-by: Mrinal Pandey Signed-off-by: Andrew Morton Tested-by: Lukas Bulwahn Reviewed-by: Lukas Bulwahn Cc: Joe Perches Link: https://lkml.kernel.org/r/20200714032352.f476hanaj2dlmiot@mrinalpandey Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

2020-09-03T09:27:10Z

commit e4a42c82e943b97ce124539fcd7a47445b43fa0d upstream. Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp. GZIP, BZIP2, LZOP env variables are reserved by the tools. The original attempt to redefine them internally doesn't work in makefiles/scripts intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in broken builds. There can be other broken build commands because of this, so the universal solution is to use non-reserved env variables for the compression tools. Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools") Signed-off-by: Denis Efremov Tested-by: Guenter Roeck Signed-off-by: Masahiro Yamada Cc: Matthias Maennich Signed-off-by: Greg Kroah-Hartman

kbuild: add variables for compression tools

2020-09-03T09:27:10Z

commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream. Allow user to use alternative implementations of compression tools, such as pigz, pbzip2, pxz. For example, multi-threaded tools to speed up the build: $ make GZIP=pigz BZIP2=pbzip2 Variables _GZIP, _BZIP2, _LZOP are used internally because original env vars are reserved by the tools. The use of GZIP in gzip tool is obsolete since 2015. However, alternative implementations (e.g., pigz) still rely on it. BZIP2, BZIP, LZOP vars are not obsolescent. The credit goes to @grsecurity. As a sidenote, for multi-threaded lzma, xz compression one can use: $ export XZ_OPT="--threads=0" Signed-off-by: Denis Efremov Signed-off-by: Masahiro Yamada Signed-off-by: Matthias Maennich Signed-off-by: Greg Kroah-Hartman

kconfig: qconf: fix signal connection to invalid slots

2020-08-26T08:41:04Z

[ Upstream commit d85de3399f97467baa2026fbbbe587850d01ba8a ] If you right-click in the ConfigList window, you will see the following messages in the console: QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:888 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:897 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:906 QObject::connect: (sender name: 'config') Right, there is no such slot in QAction. I think this is a typo of setChecked. Due to this bug, when you toggled the menu "Option->Show Name/Range/Data" the state of the context menu was not previously updated. Fix this. Fixes: d5d973c3f8a9 ("Port xconfig to Qt5 - Put back some of the old implementation(part 2)") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: qconf: do not limit the pop-up menu to the first row

2020-08-26T08:41:04Z

[ Upstream commit fa8de0a3bf3c02e6f00b7746e7e934db522cdda9 ] If you right-click the first row in the option tree, the pop-up menu shows up, but if you right-click the second row or below, the event is ignored due to the following check: if (e->y() <= header()->geometry().bottom()) { Perhaps, the intention was to show the pop-menu only when the tree header was right-clicked, but this handler is not called in that case. Since the origin of e->y() starts from the bottom of the header, this check is odd. Going forward, you can right-click anywhere in the tree to get the pop-up menu. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

recordmcount: Fix build failure on non arm64

2020-08-21T11:05:36Z

[ 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:57Z

[ 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:35Z

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