kernel/linux.git/scripts, branch v4.9.254

scripts/gdb: fix lx-version string output

2021-01-12T18:49:03+00:00

commit b058809bfc8faeb7b7cae047666e23375a060059 upstream A bug is present in GDB which causes early string termination when parsing variables. This has been reported [0], but we should ensure that we can support at least basic printing of the core kernel strings. For current gdb version (has been tested with 7.3 and 8.1), 'lx-version' only prints one character. (gdb) lx-version L(gdb) This can be fixed by casting 'linux_banner' as (char *). (gdb) lx-version Linux version 4.19.0-rc1+ (changbin@acer) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21 SMP Sat Sep 1 21:43:30 CST 2018 [0] https://sourceware.org/bugzilla/show_bug.cgi?id=20077 [kbingham@kernel.org: add detail to commit message] Link: http://lkml.kernel.org/r/20181111162035.8356-1-kieran.bingham@ideasonboard.com Fixes: 2d061d999424 ("scripts/gdb: add version command") Signed-off-by: Du Changbin Signed-off-by: Kieran Bingham Acked-by: Jan Kiszka Cc: Jan Kiszka Cc: Jason Wessel Cc: Daniel Thompson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin

scripts/gdb: lx-dmesg: use explicit encoding=utf8 errors=replace

2021-01-12T18:49:03+00:00

commit 46d10a094353c05144f3b0530516bdac3ce7c435 upstream Use errors=replace because it is never desirable for lx-dmesg to fail on string decoding errors, not even if the log buffer is corrupt and we show incorrect info. The kernel will sometimes print utf8, for example the copyright symbol from jffs2. In order to make this work specify 'utf8' everywhere because python2 otherwise defaults to 'ascii'. In theory the second errors='replace' is not be required because everything that can be decoded as utf8 should also be encodable back to utf8. But it's better to be extra safe here. It's worth noting that this is definitely not true for encoding='ascii', unknown characters are replaced with U+FFFD REPLACEMENT CHARACTER and they fail to encode back to ascii. Link: http://lkml.kernel.org/r/acee067f3345954ed41efb77b80eebdc038619c6.1498481469.git.leonard.crestez@nxp.com Signed-off-by: Leonard Crestez Acked-by: Jan Kiszka Cc: Jason Wessel Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin

scripts/gdb: lx-dmesg: cast log_buf to void* for addr fetch

2021-01-12T18:49:03+00:00

commit c454756f47277b651ad41a5a163499294529e35d upstream In some cases it is possible for the str() conversion here to throw encoding errors because log_buf might not point to valid ascii. For example: (gdb) python print str(gdb.parse_and_eval("log_buf")) Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode character u'\u0303' in position 24: ordinal not in range(128) Avoid this by explicitly casting to (void *) inside the gdb expression. Link: http://lkml.kernel.org/r/ba6f85dbb02ca980ebd0e2399b0649423399b565.1498481469.git.leonard.crestez@nxp.com Signed-off-by: Leonard Crestez Reviewed-by: Jan Kiszka Cc: Jason Wessel Cc: Kieran Bingham Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin

scripts/gdb: make lx-dmesg command work (reliably)

2021-01-12T18:49:02+00:00

commit d6c9708737c2107c38bd75f133d14d5801b8d6d5 upstream lx-dmesg needs access to the log_buf symbol from printk.c. Unfortunately, the symbol log_buf also exists in BPF's verifier.c and hence gdb can pick one or the other. If it happens to pick BPF's log_buf, lx-dmesg doesn't work: (gdb) lx-dmesg Python Exception Cannot access memory at address 0x0: Error occurred in Python command: Cannot access memory at address 0x0 (gdb) p log_buf $15 = 0x0 Luckily, GDB has a way to deal with this, see https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html (gdb) info variables ^log_buf$ All variables matching regular expression "^log_buf$": File /kernel/bpf/verifier.c: static char *log_buf; File /kernel/printk/printk.c: static char *log_buf; (gdb) p 'verifier.c'::log_buf $1 = 0x0 (gdb) p 'printk.c'::log_buf $2 = 0x811a6aa0 <__log_buf> "" (gdb) p &log_buf $3 = (char **) 0x8120fe40 (gdb) p &'verifier.c'::log_buf $4 = (char **) 0x8120fe40 (gdb) p &'printk.c'::log_buf $5 = (char **) 0x8048b7d0 By being explicit about the location of the symbol, we can make lx-dmesg work again. While at it, do the same for the other symbols we need from printk.c Link: http://lkml.kernel.org/r/20170526112222.3414-1-git@andred.net Signed-off-by: André Draszik Tested-by: Kieran Bingham Acked-by: Jan Kiszka Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin

depmod: handle the case of /sbin/depmod without /sbin in PATH

2021-01-12T18:49:01+00:00

[ Upstream commit cedd1862be7e666be87ec824dabc6a2b05618f36 ] Commit 436e980e2ed5 ("kbuild: don't hardcode depmod path") stopped hard-coding the path of depmod, but in the process caused trouble for distributions that had that /sbin location, but didn't have it in the PATH (generally because /sbin is limited to the super-user path). Work around it for now by just adding /sbin to the end of PATH in the depmod.sh script. Reported-and-tested-by: Sedat Dilek Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

checkpatch: fix unescaped left brace

2020-12-29T12:45:01+00:00

[ Upstream commit 03f4935135b9efeb780b970ba023c201f81cf4e6 ] There is an unescaped left brace in a regex in OPEN_BRACE check. This throws a runtime error when checkpatch is run with --fix flag and the OPEN_BRACE check is executed. Fix it by escaping the left brace. Link: https://lkml.kernel.org/r/20201115202928.81955-1-dwaipayanray1@gmail.com Fixes: 8d1824780f2f ("checkpatch: add --fix option for a couple OPEN_BRACE misuses") Signed-off-by: Dwaipayan Ray Acked-by: Joe Perches Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

scripts/setlocalversion: make git describe output more reliable

2020-11-10T09:23:50+00:00

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

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

2020-09-12T09:47:38+00:00

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

scripts/decode_stacktrace: strip basepath from all paths

2020-07-31T14:44:03+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

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

2020-06-30T19:38:43+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