user/sven/linux.git/scripts, branch v4.14.236

scripts: switch explicitly to Python 3

2021-06-03T06:36:11Z

commit 51839e29cb5954470ea4db7236ef8c3d77a6e0bb upstream. Some distributions are about to switch to Python 3 support only. This means that /usr/bin/python, which is Python 2, is not available anymore. Hence, switch scripts to use Python 3 explicitly. Signed-off-by: Andy Shevchenko Signed-off-by: Masahiro Yamada Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman

tweewide: Fix most Shebang lines

2021-06-03T06:36:11Z

commit c25ce589dca10d64dde139ae093abc258a32869c upstream. Change every shebang which does not need an argument to use /usr/bin/env. This is needed as not every distro has everything under /usr/bin, sometimes not even bash. Signed-off-by: Finn Behrens Signed-off-by: Masahiro Yamada [nicolas@fjasle.eu: update contexts for v4.14, adapt for old scripts] Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman

kconfig: nconf: stop endless search loops

2021-05-22T08:57:37Z

[ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts/recordmcount.{c,pl}: support -ffunction-sections .text.* section names

2021-03-17T15:34:28Z

commit 9c8e2f6d3d361439cc6744a094f1c15681b55269 upstream. When building with -ffunction-sections, the compiler will place each function into its own ELF section, prefixed with ".text". For example, a simple test module with functions test_module_do_work() and test_module_wq_func(): % objdump --section-headers test_module.o | awk '/\.text/{print $2}' .text .text.test_module_do_work .text.test_module_wq_func .init.text .exit.text Adjust the recordmcount scripts to look for ".text" as a section name prefix. This will ensure that those functions will be included in the __mcount_loc relocations: % objdump --reloc --section __mcount_loc test_module.o OFFSET TYPE VALUE 0000000000000000 R_X86_64_64 .text.test_module_do_work 0000000000000008 R_X86_64_64 .text.test_module_wq_func 0000000000000010 R_X86_64_64 .init.text Link: http://lkml.kernel.org/r/1542745158-25392-2-git-send-email-joe.lawrence@redhat.com Signed-off-by: Joe Lawrence Signed-off-by: Steven Rostedt (VMware) Cc: Manoj Gupta Signed-off-by: Greg Kroah-Hartman

scripts: set proper OpenSSL include dir also for sign-file

2021-03-07T10:27:41Z

commit fe968c41ac4f4ec9ffe3c4cf16b72285f5e9674f upstream. Fixes: 2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto") Signed-off-by: Rolf Eike Beer Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

scripts: use pkg-config to locate libcrypto

2021-03-07T10:27:41Z

commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream. Otherwise build fails if the headers are not in the default location. While at it also ask pkg-config for the libs, with fallback to the existing value. Signed-off-by: Rolf Eike Beer Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

scripts/recordmcount.pl: support big endian for ARCH sh

2021-03-03T17:22:36Z

[ Upstream commit 93ca696376dd3d44b9e5eae835ffbc84772023ec ] The kernel test robot reported the following issue: CC [M] drivers/soc/litex/litex_soc_ctrl.o sh4-linux-objcopy: Unable to change endianness of input file(s) sh4-linux-ld: cannot find drivers/soc/litex/.tmp_gl_litex_soc_ctrl.o: No such file or directory sh4-linux-objcopy: 'drivers/soc/litex/.tmp_mx_litex_soc_ctrl.o': No such file The problem is that the format of input file is elf32-shbig-linux, but sh4-linux-objcopy wants to output a file which format is elf32-sh-linux: $ sh4-linux-objdump -d drivers/soc/litex/litex_soc_ctrl.o | grep format drivers/soc/litex/litex_soc_ctrl.o: file format elf32-shbig-linux Link: https://lkml.kernel.org/r/20210210150435.2171567-1-rong.a.chen@intel.com Link: https://lore.kernel.org/linux-mm/202101261118.GbbYSlHu-lkp@intel.com Signed-off-by: Rong Chen Reported-by: kernel test robot Cc: Yoshinori Sato Cc: Rich Felker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

tracing: Avoid calling cc-option -mrecord-mcount for every Makefile

2021-02-23T13:00:33Z

commit 07d0408120216b60625c9a5b8012d1c3a907984d upstream. Currently if CONFIG_FTRACE_MCOUNT_RECORD is enabled -mrecord-mcount compiler flag support is tested for every Makefile. Top 4 cc-option usages: 511 -mrecord-mcount 11 -fno-stack-protector 9 -Wno-override-init 2 -fsched-pressure To address that move cc-option from scripts/Makefile.build to top Makefile and export CC_USING_RECORD_MCOUNT to be used in original place. While doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc actually supports it). Link: http://lkml.kernel.org/r/patch-2.thread-aa7b8d.git-de935bace15a.your-ad-here.call-01533557518-ext-9465@work.hours Acked-by: Andi Kleen Signed-off-by: Vasily Gorbik Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman

tracing: Fix SKIP_STACK_VALIDATION=1 build due to bad merge with -mrecord-mcount

2021-02-23T13:00:33Z

commit ed7d40bc67b8353c677b38c6cdddcdc310c0f452 upstream. Non gcc-5 builds with CONFIG_STACK_VALIDATION=y and SKIP_STACK_VALIDATION=1 fail. Example output: /bin/sh: init/.tmp_main.o: Permission denied commit 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace"), added a mismatched endif. This causes cmd_objtool to get mistakenly set. Relocate endif to balance the newly added -record-mcount check. Link: http://lkml.kernel.org/r/20180608214746.136554-1-gthelen@google.com Fixes: 96f60dfa5819 ("trace: Use -mcount-record for dynamic ftrace") Acked-by: Andi Kleen Tested-by: David Rientjes Signed-off-by: Greg Thelen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman

trace: Use -mcount-record for dynamic ftrace

2021-02-23T13:00:33Z

commit 96f60dfa5819a065bfdd2f2ba0df7d9cbce7f4dd upstream. gcc 5 supports a new -mcount-record option to generate ftrace tables directly. This avoids the need to run record_mcount manually. Use this option when available. So far doesn't use -mcount-nop, which also exists now. This is needed to make ftrace work with LTO because the normal record-mcount script doesn't run over the link time output. It should also improve build times slightly in the general case. Link: http://lkml.kernel.org/r/20171127213423.27218-12-andi@firstfloor.org Signed-off-by: Andi Kleen Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman