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, 20 Oct 2023 23:36:36 +0300
To:     Jan Kara <>
Cc:     Andy Shevchenko <>,
        Baokun Li <>,
        Josh Poimboeuf <>, Jan Kara <>,
        Nathan Chancellor <>,
        Nick Desaulniers <>,
        Kees Cook <>,
        Ferry Toth <>,,
Subject: Re: [GIT PULL] ext2, quota, and udf fixes for 6.6-rc1

Fri, Oct 20, 2023 at 12:43:56PM -0700, Linus Torvalds kirjoitti:
> On Fri, 20 Oct 2023 at 11:29, Andy Shevchenko
> <> wrote:
> >
> > I'll reply to this with the attached object file, I assume it won't go to the
> > mailing list, but should be available in your mailbox.
> Honestly, both cases (that function gets inlined twice) look
> *identical* from a quick look, apart from obviously the extra call to
> __quota_error().
> I might be missing something, but this most definitely is not a "gcc
> ends up creating very different code when it doesn't need to
> synchronize around the call" thing.
> So a compiler issue looks very unlikely. No absolute guarantees - I
> didn't do *that* kind of walk-through instruction by instruction - but
> the results actually seem to line up perfectly.
> Even register allocation didn't change, making the compare between #if
> 0 and without rather easy.
> There's one extra spill/reload due to the call in the "non-#if0" case,
> and that actually made me look twice (because it spilled %eax, and
> then reloaded it as %rcx), but it turns that %eax/%ecx had the same
> value at the time of the spill, so even that was not a "real"
> difference.
> So I will claim that no, it's not the compiler. It's some unrelated
> subtle timing, or possibly just a random code layout issue (because
> the code addresses do obviously change).

Okay, but since now I can't use the certain configuration, the bug is
persistent to me after this merge with the GCC. Yet, you mentioned that
you would expect some reports but I don't think many people have a
configuration similar to what I have. In any case a bug is lurking somewhere

Let me check next week on different CPU (but I'm quite sceptical that it
may anyhow trigger the same behaviour as if it's a timing, many parameters
are involved, including hardware clocks, etc).

That said, if you or anyone has ideas how to debug futher, I'm all ears!

With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists