linux-kernel - Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231107095745.GD19790@gate.crashing.org>
Date:   Tue, 7 Nov 2023 03:57:45 -0600
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>, j.alglave@....ac.uk,
        will@...nel.org, catalin.marinas@....com, linux@...linux.org.uk,
        mpe@...erman.id.au, npiggin@...il.com, palmer@...belt.com,
        parri.andrea@...il.com, linux-kernel@...r.kernel.org,
        linux-toolchains@...r.kernel.org, boqun.feng@...il.com,
        davidtgoldblatt@...il.com
Subject: Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

On Mon, Nov 06, 2023 at 06:16:24PM -0800, Paul E. McKenney wrote:
> On Mon, Nov 06, 2023 at 12:08:59AM +0100, Peter Zijlstra wrote:
> > Which is a contradiction if ever I saw one. It both claims this atrocity
> > fixes our volatile_if() woes while at the same time saying we're
> > unaffected because we don't use any of the C/C++ atomic batshit.
> 
> I guess that my traditional reply would be that if you are properly
> confused by all this, that just means that you were reading carefully.

I'll put that in my quote box :-)

> I am very much against incurring real overhead to solve an issue that is
> an issue only in theory and not in practice.  I wish I could confidently
> say that my view will prevail, but...

Given enough time most theory turns out to be practice.  If what you
are writing has a constrained scope, or a limited impact, or both, you
can ignore this "we'll deal with it later if/when it shows up".  But a
compiler does not have that luxury at all: it has to make correct
translations from source code to assembler code (or machine code
directly, for some compilers), or refuse to compile something.  Making
an incorrect translation is not an option.

> If this goes through and if developers see any overhead from relaxed
> atomics in a situation that matters to them, they will reach for some
> other tool.  Inline assembly and volatile accesses, I suppose.  Or the
> traditional approach of a compiler flag.

And I understand you want the standards to be more useful for the kernel
concurrency model?  Why, exactly?  I can think of many reasons, but I'm
a bit lost as to what motivates you here :-)


Segher