linux-kernel - Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros

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]

Message-ID: <875y8ok9b5.fsf@rcn-XPS-13-9305.i-did-not-set--mail-host-address--so-tickle-me>
Date:   Fri, 19 May 2023 10:35:42 +0200
From:   Ricardo Cañuelo <ricardo.canuelo@...labora.com>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Shreeya Patel <shreeya.patel@...labora.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        clang-built-linux <llvm@...ts.linux.dev>,
        Bill Wendling <morbo@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        regressions@...ts.linux.dev,
        "gustavo.padovan\@collabora.com" <gustavo.padovan@...labora.com>,
        Guillaume Charles Tucker <guillaume.tucker@...labora.com>,
        denys.f@...labora.com, kernelci@...ts.linux.dev
Subject: Re: [PATCH v4] Makefile.compiler: replace cc-ifversion with compiler-specific macros

On jue, may 18 2023 at 14:12:30, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> That's a higher risk change (and has my name on the tested-by tag, yikes).
>
> So is that the culprit of the boot failure you're observing?

Right now it is.

Here's a test run using that commit
(5750121ae7382ebac8d47ce6d68012d6cd1d7926):
https://lava.collabora.dev/scheduler/job/10373216

Here's one with the commit right after that one
(26ef40de5cbb24728a34a319e8d42cdec99f186c):
https://lava.collabora.dev/scheduler/job/10371513

Then one with 26ef40de5cbb24728a34a319e8d42cdec99f186c with a revert
commit for 5750121ae7382ebac8d47ce6d68012d6cd1d7926 on top:
https://lava.collabora.dev/scheduler/job/10371882

But I'm not confident enough to jump ahead and call this a kernel
regression, specially after the bisector confidently said that about
your commit and then it turned out none of us could reproduce it.

There have been some cases where a commit made a test fail (kernel
failing to load, for instance) and the real problem was that the kernel
got bigger than the target was capable of handling. So not a problem
with the commit at all, it was just that the memory mappings needed to
be redefined for that target. What I'm saying is that sometimes a
regression report is really uncovering a problem in the test setup
rather than introducing a bug. Maybe this is one of those cases.

Cheers,
Ricardo