| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
kbuild: dummy-tools: avoid tmpdir leak in dummy gcc stable inclusion from stable-v5.10.139 commit 37c7f25fe2b79184f3a7a9f15fdcfbcf8f46913c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I63FCF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=37c7f25fe2b79184f3a7a9f15fdcfbcf8f46913c -------------------------------- commit aac289653fa5adf9e9985e4912c1d24a3e8cbab2 upstream When passed -print-file-name=plugin, the dummy gcc script creates a temporary directory that is never cleaned up. To avoid cluttering $TMPDIR, instead use a static directory included in the source tree. Fixes: 76426e238834 ("kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/9996285f-5a50-e56a-eb1c-645598381a20@kernel.org [ just the plugin-version.h portion as it failed to apply previously - gregkh ] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> | 3 年前 | |
kbuild: dummy-tools: adjust to stricter stackprotector check stable inclusion from stable-v5.10.215 commit 44900a8bec03aed77f23b374acb9103dcd3e7a3d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAJJ2D Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=44900a8bec03aed77f23b374acb9103dcd3e7a3d -------------------------------- commit c93db682cfb213501881072a9200a48ce1dc3c3f upstream. Commit 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable") modified the stackprotector check on 32-bit x86 to check if gcc supports using %fs as canary. Adjust dummy-tools gcc script to pass this new test by returning "%fs" rather than "%gs" if it detects -mstack-protector-guard-reg=fs on command line. Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable") Signed-off-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: sanglipeng1 <sanglipeng1@jd.com> | 1 年前 | |
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG options your compiler does not support. This works well if you configure and build the kernel on the same host machine. It is inconvenient if you prepare the .config that is carried to a different build environment (typically this happens when you package the kernel for distros) because using a different compiler potentially produces different CONFIG options than the real build environment. So, you probably want to make as many options visible as possible. In other words, you need to create a super-set of CONFIG options that cover any build environment. If some of the CONFIG options turned out to be unsupported on the build machine, they are automatically disabled by the nature of Kconfig. However, it is not feasible to get a full-featured compiler for every arch. This issue was discussed here: https://lkml.org/lkml/2019/12/9/620 Other than distros, savedefconfig is also a problem. Some arch sub-systems periodically resync defconfig files. If you use a less-capable compiler for savedefconfig, options that do not meet 'depends on $(cc-option,...)' will be forcibly disabled. So, 'make defconfig && make savedefconfig' may silently change the behavior. This commit adds a set of dummy toolchains that pretend to support any feature. Most of compiler features are tested by cc-option, which simply checks the exit code of $(CC). The dummy tools are shell scripts that always exit with 0. So, $(cc-option, ...) is evaluated as 'y'. There are more complicated checks such as: scripts/gcc-x86_{32,64}-has-stack-protector.sh scripts/gcc-plugin.sh scripts/tools-support-relr.sh scripts/dummy-tools/gcc passes all checks. From the top directory of the source tree, you can do: $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Tested-by: Jeremy Cline <jcline@redhat.com> | 6 年前 | |
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG options your compiler does not support. This works well if you configure and build the kernel on the same host machine. It is inconvenient if you prepare the .config that is carried to a different build environment (typically this happens when you package the kernel for distros) because using a different compiler potentially produces different CONFIG options than the real build environment. So, you probably want to make as many options visible as possible. In other words, you need to create a super-set of CONFIG options that cover any build environment. If some of the CONFIG options turned out to be unsupported on the build machine, they are automatically disabled by the nature of Kconfig. However, it is not feasible to get a full-featured compiler for every arch. This issue was discussed here: https://lkml.org/lkml/2019/12/9/620 Other than distros, savedefconfig is also a problem. Some arch sub-systems periodically resync defconfig files. If you use a less-capable compiler for savedefconfig, options that do not meet 'depends on $(cc-option,...)' will be forcibly disabled. So, 'make defconfig && make savedefconfig' may silently change the behavior. This commit adds a set of dummy toolchains that pretend to support any feature. Most of compiler features are tested by cc-option, which simply checks the exit code of $(CC). The dummy tools are shell scripts that always exit with 0. So, $(cc-option, ...) is evaluated as 'y'. There are more complicated checks such as: scripts/gcc-x86_{32,64}-has-stack-protector.sh scripts/gcc-plugin.sh scripts/tools-support-relr.sh scripts/dummy-tools/gcc passes all checks. From the top directory of the source tree, you can do: $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Tested-by: Jeremy Cline <jcline@redhat.com> | 6 年前 | |
kbuild: add dummy toolchains to enable all cc-option etc. in Kconfig Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG options your compiler does not support. This works well if you configure and build the kernel on the same host machine. It is inconvenient if you prepare the .config that is carried to a different build environment (typically this happens when you package the kernel for distros) because using a different compiler potentially produces different CONFIG options than the real build environment. So, you probably want to make as many options visible as possible. In other words, you need to create a super-set of CONFIG options that cover any build environment. If some of the CONFIG options turned out to be unsupported on the build machine, they are automatically disabled by the nature of Kconfig. However, it is not feasible to get a full-featured compiler for every arch. This issue was discussed here: https://lkml.org/lkml/2019/12/9/620 Other than distros, savedefconfig is also a problem. Some arch sub-systems periodically resync defconfig files. If you use a less-capable compiler for savedefconfig, options that do not meet 'depends on $(cc-option,...)' will be forcibly disabled. So, 'make defconfig && make savedefconfig' may silently change the behavior. This commit adds a set of dummy toolchains that pretend to support any feature. Most of compiler features are tested by cc-option, which simply checks the exit code of $(CC). The dummy tools are shell scripts that always exit with 0. So, $(cc-option, ...) is evaluated as 'y'. There are more complicated checks such as: scripts/gcc-x86_{32,64}-has-stack-protector.sh scripts/gcc-plugin.sh scripts/tools-support-relr.sh scripts/dummy-tools/gcc passes all checks. From the top directory of the source tree, you can do: $ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Tested-by: Jeremy Cline <jcline@redhat.com> | 6 年前 |