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
| ||
|
Message-ID: <CAJhHMCBes7Y2x-=M7or13_m07fR4+RBV4KMUpiZJVB0f9CPaqA@mail.gmail.com> Date: Wed, 13 Aug 2014 21:03:18 -0400 From: Pranith Kumar <bobby.prani@...il.com> To: Paul McKenney <paulmck@...ux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: Question regarding "Control Dependencies" in memory-barriers.txt On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote: >> >> If the stores to 'b' differ, then there is no issue. Why not document how to >> avoid re-ordering in the case where both the stores are the same? In that case >> using a stronger barrier like mb() should be sufficient for both the compiler >> and the CPU to avoid re-ordering, right? > > Like this? (On top of the earlier patch.) > That looks good, thank you! > Thanx, Paul > > ------------------------------------------------------------------------ > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index 6062f175abc6..22a969cdd476 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -625,9 +625,20 @@ Now there is no conditional between the load from 'a' and the store to > 'b', which means that the CPU is within its rights to reorder them: > The conditional is absolutely required, and must be present in the > assembly code even after all compiler optimizations have been applied. > +Therefore, if you need ordering in this example, you need explicit > +memory barriers, for example, smp_store_release(): > > -So two-legged-if control ordering is guaranteed only when the stores > -differ, for example: > + q = ACCESS_ONCE(a); > + if (q) { > + smp_store_release(&b, p); > + do_something(); > + } else { > + smp_store_release(&b, p); > + do_something_else(); > + } > + > +In contrast, without explicit memory barriers, two-legged-if control > +ordering is guaranteed only when the stores differ, for example: > > q = ACCESS_ONCE(a); > if (q) { > -- Pranith -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists