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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 2 Jun 2023 02:38:43 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Helge Deller <deller@....de>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>, dennis@...nel.org,
        Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
        Heiko Carstens <hca@...ux.ibm.com>, gor@...ux.ibm.com,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        borntraeger@...ux.ibm.com, Sven Schnelle <svens@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, Joerg Roedel <joro@...tes.org>,
        suravee.suthikulpanit@....com, Robin Murphy <robin.murphy@....com>,
        David Woodhouse <dwmw2@...radead.org>,
        Baolu Lu <baolu.lu@...ux.intel.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S . Miller" <davem@...emloft.net>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-s390@...r.kernel.org, iommu@...ts.linux.dev,
        Linux-Arch <linux-arch@...r.kernel.org>,
        linux-crypto@...r.kernel.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Michael Ellerman <mpe@...erman.id.au>,
        "James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
        linux-parisc@...r.kernel.org,
        John David Anglin <dave.anglin@...l.net>,
        Sam James <sam@...too.org>
Subject: Re: [PATCH v2 07/12] parisc/percpu: Work around the lack of __SIZEOF_INT128__

On Thu, Jun 1, 2023 at 10:29 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Thu, Jun 1, 2023 at 6:32 AM Helge Deller <deller@....de> wrote:
> >
> > I don't think we need to care about gcc-10 on parisc.
> > Debian and Gentoo are the only supported distributions, while Debian
> > requires gcc-12 to build > 6.x kernels, and I assume Gentoo uses at least
> > gcc-12 as well.
> >
> > So raising the gcc limit for parisc only (at least temporarily for now)
> > should be fine and your workaround below wouldn't be necessary, right?
>
> This absolutely sounds like the right option. Let's simplify the
> problem space by just saying that parisc needs the newer compiler.
>
> Right now we have that "minimum gcc version" in a somewhat annoying
> place: it's in the ./scripts/min-tool-version.sh file as a shell
> script.
>
> I wonder if we could move the gcc minimum version check into the
> Kconfig file instead, and make it easier to let architectures override
> the minimum version.

Currently, it is invoked in the Kconfig time,
but not directly in Kconfig files.

scripts/Kconfig.include
 -> scripts/cc-version.sh
    -> scripts/min-tool-version.sh

It would be ugly if we wrote the equivalent code
directly in Kconfig files.


>
> I don't quite know how to do that sanely, though. I don't think we
> have a sane way to error out at Kconfig time (except by forcing some
> syntax error inside an 'if' statement or something horrendously hacky
> like that).

The parse stage can fail by $(error-if ) macro, but
the evaluation stage never fails. I think it is a design.

I think checking the compiler version during the parse stage
makes sense given the current situation. The compiler version is
fixed when Kconfig starts. If the compiler is found to be too old,
there is no meaning to proceed.


You suggested to choose a compiler in the Kconfig time:
https://lore.kernel.org/lkml/CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com/

When we achieve that, moving the min version to Kconfig files will be
the right thing to do. Then, everything will be evaluated dynamically.


>
> Added Masahiro to the (already overlong) participants list.
>
>                    Linus



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ