linux-kernel - Re: [RFC] Bumping the minimum supported version of LLVM to 13.0.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK7LNAT1GBr1pKRuJp2YKZdQQ_TDSKdbHojbPtBvt7cRQdCReg@mail.gmail.com>
Date: Sat, 13 Jan 2024 18:57:45 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: llvm@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	linux-kbuild@...r.kernel.org
Subject: Re: [RFC] Bumping the minimum supported version of LLVM to 13.0.1

On Thu, Jan 11, 2024 at 1:53 AM Nathan Chancellor <nathan@...nel.org> wrote:
>
> Hi all,
>
> It has been some time since we have bumped the minimum supported version
> of LLVM for building the kernel, the last time being commit df05c0e9496c
> ("Documentation: Raise the minimum supported version of LLVM to 11.0.0")
> in November of 2021. While I think we have done a pretty good job around
> supporting the current range of LLVM versions, it may be worth
> considering bumping the minimum supported version to 13.0.1 for a few
> reasons:
>
> 1. It would immediately resolve the massive build breakage with LLVM 11
>    in -next:
>
>    https://github.com/ClangBuiltLinux/linux/issues/1958#issuecomment-1836559075
>
> 2. It would immediately save us almost 1300 builds per week with our
>    current CI matrix, as we would be able to drop mainline and -next,
>    which are our most frequently built trees.
>
> 3. It allows us to drop a good number of Kconfig and source workarounds.
>    I have included a sample diff below.
>
> The downside of upgrading the minimum version is leaving distributions
> that have an older clang version behind. However, based on examining
> Docker images for the currently supported versions of the big
> distributions, I do not believe this upgrade should impact distribution
> support too much.
>
>     archlinux:latest              clang version 16.0.6
>     debian:oldoldstable-slim      clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
>     debian:oldstable-slim         Debian clang version 11.0.1-2
>     debian:stable-slim            Debian clang version 14.0.6
>     debian:testing-slim           Debian clang version 16.0.6 (19)
>     debian:unstable-slim          Debian clang version 16.0.6 (19)
>     fedora:38                     clang version 16.0.6 (Fedora 16.0.6-3.fc38)
>     fedora:latest                 clang version 17.0.6 (Fedora 17.0.6-1.fc39)
>     fedora:rawhide                clang version 17.0.6 (Fedora 17.0.6-1.fc40)
>     opensuse/leap:latest          clang version 15.0.7
>     opensuse/tumbleweed:latest    clang version 17.0.6
>     ubuntu:focal                  clang version 10.0.0-4ubuntu1
>     ubuntu:latest                 Ubuntu clang version 14.0.0-1ubuntu1.1
>     ubuntu:rolling                Ubuntu clang version 16.0.6 (15)
>     ubuntu:devel                  Ubuntu clang version 17.0.6 (3)
>
> As we can see, the only distribution in that list that would be impacted
> by this change would be Debian Bullseye (oldstable), as its clang
> version in the default repositories is 11.0.1. Other distributions that
> have a clang older than 11.0.1 already cannot build the upstream kernel.
> In Debian's case, access to newer versions of LLVM is relatively simple
> because of https://apt.llvm.org. There is also the kernel.org LLVM
> toolchains I publish: https://mirrors.edge.kernel.org/pub/tools/llvm/
>
> Thoughts or concerns?



No objection from me.


>
> I have posted this on GitHub as well in case people want to chime in
> there instead of here for some reason:
>
> https://github.com/ClangBuiltLinux/linux/issues/1975
>
> Cheers,
> Nathan
>
> diff --git a/Makefile b/Makefile
> index f1b2fd977275..32f42f4470ec 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -948,15 +948,6 @@ CC_FLAGS_LTO       += -fvisibility=hidden
>  # Limit inlining across translation units to reduce binary size
>  KBUILD_LDFLAGS += -mllvm -import-instr-limit=5
>
> -# Check for frame size exceeding threshold during prolog/epilog insertion
> -# when using lld < 13.0.0.
> -ifneq ($(CONFIG_FRAME_WARN),0)
> -ifeq ($(call test-lt, $(CONFIG_LLD_VERSION), 130000),y)
> -KBUILD_LDFLAGS += -plugin-opt=-warn-stack-size=$(CONFIG_FRAME_WARN)
> -endif
> -endif
> -endif
> -

The last 'endif' should be kept.








--
Best Regards
Masahiro Yamada