• Nathan Chancellor's avatar
    kbuild: raise the minimum supported version of LLVM to 13.0.1 · 9c1b86f8
    Nathan Chancellor authored
    Patch series "Bump the minimum supported version of LLVM to 13.0.1".
    
    This series bumps the minimum supported version of LLVM for building the
    kernel to 13.0.1.  The first patch does the bump and all subsequent
    patches clean up all the various workarounds and checks for earlier
    versions.
    
    Quoting the first patch's commit message for those that were only on CC
    for the clean ups:
    
      When __builtin_mul_overflow() has arguments that differ in terms of
      signedness and width, LLVM may generate a libcall to __muloti4 because
      it performs the checks in terms of 65-bit multiplication. This issue
      becomes harder to hit (but still possible) after LLVM 12.0.0, which
      includes a special case for matching widths but different signs.
    
      To gain access to this special case, which the kernel can take advantage
      of when calls to __muloti4 appear, bump the minimum supported version of
      LLVM for building the kernel to 13.0.1. 13.0.1 was chosen because there
      is minimal impact to distribution support while allowing a few more
      workarounds to be dropped in the kernel source than if 12.0.0 were
      chosen. Looking at container images of up to date distribution versions:
    
        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)
    
      The only distribution that gets left behind is Debian Bullseye, as the
      default version is 11.0.1; other distributions either have a newer
      version than 13.0.1 or one older than the current minimum of 11.0.0.
      Debian has easy access to more recent LLVM versions through
      apt.llvm.org, so this is not as much of a concern. There are also the
      kernel.org LLVM toolchains, which should work with distributions with
      glibc 2.28 and newer.
    
      Another benefit of slimming up the number of supported versions of LLVM
      for building the kernel is reducing the build capacity needed to support
      a matrix that builds with each supported version, which allows a matrix
      to reallocate the freed up build capacity towards something else, such
      as more configuration combinations.
    
    This passes my build matrix with all supported versions.
    
    This is based on Andrew's mm-nonmm-unstable to avoid trivial conflicts
    with my series to update the LLVM links across the repository [1] but I
    can easily rebase it to linux-kbuild if Masahiro would rather these
    patches go through there (and defer the conflict resolution to the merge
    window).
    
    [1]: https://lore.kernel.org/20240109-update-llvm-links-v1-0-eb09b59db071@kernel.org/
    
    
    This patch (of 11):
    
    When __builtin_mul_overflow() has arguments that differ in terms of
    signedness and width, LLVM may generate a libcall to __muloti4 because it
    performs the checks in terms of 65-bit multiplication.  This issue becomes
    harder to hit (but still possible) after LLVM 12.0.0, which includes a
    special case for matching widths but different signs.
    
    To gain access to this special case, which the kernel can take advantage
    of when calls to __muloti4 appear, bump the minimum supported version of
    LLVM for building the kernel to 13.0.1.  13.0.1 was chosen because there
    is minimal impact to distribution support while allowing a few more
    workarounds to be dropped in the kernel source than if 12.0.0 were chosen.
    Looking at container images of up to date distribution versions:
    
      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)
    
    The only distribution that gets left behind is Debian Bullseye, as the
    default version is 11.0.1; other distributions either have a newer version
    than 13.0.1 or one older than the current minimum of 11.0.0.  Debian has
    easy access to more recent LLVM versions through apt.llvm.org, so this is
    not as much of a concern.  There are also the kernel.org LLVM toolchains,
    which should work with distributions with glibc 2.28 and newer.
    
    Another benefit of slimming up the number of supported versions of LLVM
    for building the kernel is reducing the build capacity needed to support a
    matrix that builds with each supported version, which allows a matrix to
    reallocate the freed up build capacity towards something else, such as
    more configuration combinations.
    
    Link: https://lkml.kernel.org/r/20240125-bump-min-llvm-ver-to-13-0-1-v1-0-f5ff9bda41c5@kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1975
    Link: https://github.com/llvm/llvm-project/issues/38013
    Link: https://github.com/llvm/llvm-project/commit/3203143f1356a4e4e3ada231156fc6da6e1a9f9d
    Link: https://mirrors.edge.kernel.org/pub/tools/llvm/
    Link: https://lkml.kernel.org/r/20240125-bump-min-llvm-ver-to-13-0-1-v1-1-f5ff9bda41c5@kernel.orgSigned-off-by: default avatarNathan Chancellor <nathan@kernel.org>
    Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    Cc: Albert Ou <aou@eecs.berkeley.edu>
    Cc: "Aneesh Kumar K.V (IBM)" <aneesh.kumar@kernel.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Conor Dooley <conor@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masahiro Yamada <masahiroy@kernel.org>
    Cc: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Nicolas Schier <nicolas@fjasle.eu>
    Cc: Palmer Dabbelt <palmer@dabbelt.com>
    Cc: Paul Walmsley <paul.walmsley@sifive.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Will Deacon <will@kernel.org>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    9c1b86f8
min-tool-version.sh 630 Bytes