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, 22 Sep 2017 11:29:18 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     j.alglave@....ac.uk, luc.maranget@...ia.fr, parri.andrea@...il.com,
        stern@...land.harvard.edu, dhowells@...hat.com,
        will.deacon@....com, boqun.feng@...il.com, npiggin@...il.com,
        linux-kernel@...r.kernel.org
Subject: Re: Memory-ordering recipes

On Thu, Sep 21, 2017 at 09:40:46AM -0700, Paul E. McKenney wrote:
> > Also, none of these cover 'simple' stuff like a ring-buffer.
> 
> Control dependencies are now 'simple'?  ;-)

They're not particularly harder than any other barrier I find.

But again, this comes back to the purpose of this recipes thing. I'm
thinking its meant to be how-to crib sheet for people who really don't
want to understand this stuff.

So it should include common, robust patterns and leave it at that. And
explain them through the code, not through litmus tests -- because those
are a royal friggin pain to learn to read in any case ;-)

So, 'how do I do a lockless ring-buffer' is a simple enough question
with a fairly straight forward answer. The how do I prove that answer is
correct is a whole other thing, but one I suspect most people really
don't care about.

So, once again, what is the intended purpose of his document? A gentle
introduction to memory ordering, or a crib sheet for the working code
monkey?

Because if people _want_ to understand this stuff, memory-barriers.txt
should be their document. If its become too hard to read, we should look
at fixing that, but adding another document doesn't seem like a solution
to that problem.

For the people who really don't care and just want to get their thing
done; we could have a document explaining common patterns.. maybe.

So once again, what's the purpose of this new document?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ