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

kbuild: dummy-tools: fix inverted tests for gcc

2021-03-30T12:31:50Z

[ Upstream commit b3d9fc1436808a4ef9927e558b3415e728e710c5 ] There is a test in Kconfig which takes inverted value of a compiler check: * config CC_HAS_INT128 def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0) This results in CC_HAS_INT128 not being in super-config generated by dummy-tools. So take this into account in the gcc script. Signed-off-by: Jiri Slaby Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount

2021-03-09T10:11:14Z

[ Upstream commit 999340d51174ce4141dd723105d4cef872b13ee9 ] On little endian system, Use aarch64_be(gcc v7.3) downloaded from linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y, CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y. gcc will create symbols of _mcount but recordmcount can not create mcount_loc for *.o. aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount 00000000000000d0 R_AARCH64_CALL26 _mcount ... 0000000000007190 R_AARCH64_CALL26 _mcount The reason is than funciton arm64_is_fake_mcount can not work correctly. A symbol of _mcount in *.o compiled with big endian compiler likes: 00 00 00 2d 00 00 01 1b w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes uint32_t as parameter, which truncates rp->r_info. Use w8() instead w() to read relp->r_info Link: https://lkml.kernel.org/r/20210222135840.56250-1-chenjun102@huawei.com Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.") Acked-by: Will Deacon Signed-off-by: Chen Jun Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin

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

2021-02-26T09:13:02Z

[ 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

kbuild: fix CONFIG_TRIM_UNUSED_KSYMS build for ppc64

2021-02-26T09:13:01Z

[ Upstream commit 29500f15b54b63ad0ea60b58e85144262bd24df2 ] Stephen Rothwell reported a build error on ppc64 when CONFIG_TRIM_UNUSED_KSYMS is enabled. Jessica Yu pointed out the cause of the error with the reference to the ppc64 ELF ABI: "Symbol names with a dot (.) prefix are reserved for holding entry point addresses. The value of a symbol named ".FN", if it exists, is the entry point of the function "FN". As it turned out, CONFIG_TRIM_UNUSED_KSYMS has never worked for ppc64, but this issue has been unnoticed until recently because this option depends on !UNUSED_SYMBOLS hence is disabled by all{mod,yes}config. (Then, it was uncovered by another patch removing UNUSED_SYMBOLS.) Removing the dot prefix in scripts/gen_autoksyms.sh fixes the issue. Please note it must be done before 'sort -u' because modules have both ._mcount and _mcount undefined when CONFIG_FUNCTION_TRACER=y. Link: https://lore.kernel.org/lkml/20210209210843.3af66662@canb.auug.org.au/ Reported-by: Stephen Rothwell Signed-off-by: Masahiro Yamada Tested-by: Jessica Yu Signed-off-by: Sasha Levin

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

2021-02-17T10:02:28Z

commit fe968c41ac4f4ec9ffe3c4cf16b72285f5e9674f upstream. Fixes: 2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto") Signed-off-by: Rolf Eike Beer Cc: stable@vger.kernel.org # 5.6.x Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kallsyms: fix nonconverging kallsyms table with lld

2021-02-17T10:02:24Z

[ Upstream commit efe6e3068067212b85c2d0474b5ee3b2d0c7adab ] ARM randconfig builds with lld sometimes show a build failure from kallsyms: Inconsistent kallsyms data Try make KALLSYMS_EXTRA_PASS=1 as a workaround The problem is the veneers/thunks getting added by the linker extend the symbol table, which in turn leads to more veneers being needed, so it may take a few extra iterations to converge. This bug has been fixed multiple times before, but comes back every time a new symbol name is used. lld uses a different set of identifiers from ld.bfd, so the additional ones need to be added as well. I looked through the sources and found that arm64 and mips define similar prefixes, so I'm adding those as well, aside from the ones I observed. I'm not sure about powerpc64, which seems to already be handled through a section match, but if it comes back, the "__long_branch_" and "__plt_" prefixes would have to get added as well. Signed-off-by: Arnd Bergmann Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

scripts: use pkg-config to locate libcrypto

2021-02-10T08:29:17Z

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 Cc: stable@vger.kernel.org # 5.6.x Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

Revert "kconfig: remove 'kvmconfig' and 'xenconfig' shorthands"

2021-01-23T15:03:57Z

This reverts commit 17a08680ab6a6c057949cb48c352933e09ea377a which is commit 9bba03d4473df0b707224d4d2067b62d1e1e2a77 upstream. As Pavel says at Link: https://lore.kernel.org/r/20210119182837.GA18123@duo.ucw.cz I don't believe this is suitable for stable. And he's right. It is "after" 5.10.0, but we want to keep these targets for all of the 5.10.y series. Reported-by: Pavel Machek Cc: Masahiro Yamada Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kconfig: remove 'kvmconfig' and 'xenconfig' shorthands

2021-01-19T17:27:25Z

[ Upstream commit 9bba03d4473df0b707224d4d2067b62d1e1e2a77 ] Linux 5.10 is out. Remove the 'kvmconfig' and 'xenconfig' shorthands as previously announced. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

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

2021-01-12T19:18:16Z

[ 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