linux-kernel - Re: Question regarding "Control Dependencies" in memory-barriers.txt

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: <20140805073237.GX3935@laptop>
Date:	Tue, 5 Aug 2014 09:32:37 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Pranith Kumar <pranith@...ech.edu>
Cc:	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question regarding "Control Dependencies" in memory-barriers.txt

On Mon, Aug 04, 2014 at 05:03:00PM -0400, Pranith Kumar wrote:
> On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> >>
> >> Given that there is an explicit barrier() in both the branches of
> >> if/else statement, how can the above transformation happen? The
> >> compiler cannot just remove the barrier(), right?
> >
> > No, the compiler cannot just remove the barrier().  However, it can
> > notice that "q % MAX" is always zero, which allows it to throw away
> > the then-clause entirely.
> >
> >> I think it will transform to the following if MAX is defined to 1:
> >>
> >> q = ACCESS_ONCE(a);
> >> barrier();
> >> ACCESS_ONCE(b) = p;
> >> do_something_else();
> >
> > Good point, the "barrier()" must be retained, but...
> >
> >> and hence the ordering will be preserved. What am I missing here?
> >
> > Because the barrier() primitive affects only the compiler, the CPU
> > can still reorder things.
> >
> > In contrast, in the original, the control dependency implied by the "if"
> > statement prevents the CPU from reordering.
> >
> > I fixed the example to retain the barrier() with your Reported-by.
> >
> 
> Thank you for fixing it and explaining this. I have one related
> question. Just after the above piece of text, there is the following:
> 
> 685 This transformation loses the ordering between the load from variable 'a'
> 686 and the store to variable 'b'.  If you are relying on this ordering, you
> 687 should do something like the following:
> 688
> 689         q = ACCESS_ONCE(a);
> 690         BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
> 691         if (q % MAX) {
> 692                 ACCESS_ONCE(b) = p;
> 693                 do_something();
> 694         } else {
> 695                 ACCESS_ONCE(b) = p;
> 696                 do_something_else();
> 697         }
> 698
> 
> How is the BUILD_BUG_ON(MAX <= 1) guaranteeing the ordering w.r.t 'a'
> and 'b'. Shouldn't it have barrier() in both the legs of the if()
> statement like follows:

The BUILD_BUG_ON guarantees that 'q % MAX' isn't a constant, and
therefore the compiler cannot take the conditional out.

And no barrier() doesn't order anything except compiler output. The
ordering here happens by the conditional, CPUs do not do speculative
writes, this means it has to complete the load of q to compute the
branch before it can execute the store of b.


--
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/