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:   Mon, 24 Apr 2017 12:17:03 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "Maciej W. Rozycki" <macro@...ux-mips.org>,
        Kees Cook <keescook@...omium.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kernel-build-reports@...ts.linaro.org, kvmarm@...ts.cs.columbia.edu
Subject: Re: [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?

Hi Arnd,

On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <arnd@...db.de> wrote:
>>> Based on what I found so far, gcc-4 can be pretty much ruled out from
>>> being the minimum version based on the number of failures I got.
>>> It's much better than 3.4 but much worse than 4.1 or 4.2 which seem
>>> fixable on MIPS and x86 at least, and may or may not work depending
>>> on configuration. So the best two possible (but conflicting) answers I
>>> have are
>>>
>>> a) There are known users on gcc-4.1, and we never break things that
>>>     work for users, so gcc-4.1 (or possibly 4.0 if a user shows up) would
>>>     be the minimum version.
>>> b) gcc-4.1 and 4.2 have too many problems, so users are better off
>>>     when we tell them to upgrade to something newer, and a minimum
>>>     version of gcc-4.3 has fewer surprises. We should remove all
>>>     workarounds for pre-gcc-4.3 compilers and just force a build error
>>>     message.
>>
>> If there's no real good reason (brokenness) to deprecate gcc-4.1, I would not
>> do it.I guess most people using old compilers know what they're doing.
>
> What I'm trying to find out first is whether "people regularly using 10+
> year old compilers for the latest kernels" is a strict subset of "people in
> Geert's household".

Fair enough.

>> My main motivation for keep on using gcc-4.1 is that it gives many warnings
>> that were disabled in later gcc versions.  I do look at all new warnings, and
>> send patches when they are real bugs, or are trivial to silence.
>
> What kind of warnings do you see that disappeared with later versions?
> Do you know what caused them to disappear in later versions (different
> optimization decisions, warning getting disabled by default but still available
> for turning on manually, ...)? Do you know if the disabled warnings are
> still there in gcc-4.3 (I can try it out if you give me examples)?

Mostly the "may be used uninitialized" warnings. I believe they were disabled
in gcc-4.3 (4.2?) and later due to too many false positives, which is not an
issue for me, as I look at differences.
They were re-enabled lately (with much less false-positives), that's why you
see them, and fix them.

For example, do you see the warning fixed by commit 1b8c1012142d8322
("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning")
with gcc-4.3? Yes, that was a false positive.

Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in
fsl_lpspi_transfer_one_msg()"). That one was a real bug.

I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for
avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help.

And as long as I find real bugs this way, I'd like to continue doing it.

>> BTW, below is the diff I use to avoid an ICE.
>> After that, it builds and (test)boots fine on ARAnyM ;-)
>
> I guess this means that even your builds require extra patches and you
> can't strictly build a defconfig and expect that to work ;-)

No sane people enable GFS in defconfig, so it's not affected.

Oh wait, some mips, powerpc, s390, and tile do ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists