* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 17:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, Oleg Nesterov, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131101145634.GH19466@laptop.lan>
On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > > Now the whole crux of the question is if we need barrier A at all, since
> > > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > > read.
> >
> > The dependency you are talking about is via the "if" statement?
> > Even C/C++11 is not required to respect control dependencies.
> >
> > This one is a bit annoying. The x86 TSO means that you really only
> > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker
> > barrier, and so on -- but smp_mb() emits a full barrier.
> >
> > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered
> > before reads, writes before writes, and reads before writes, but not
> > writes before reads? Another approach would be to define a per-arch
> > barrier for this particular case.
>
> I suppose we can only introduce new barrier primitives if there's more
> than 1 use-case.
There probably are others.
> > > If the read shows no available space, we simply will not issue those
> > > writes -- therefore we could argue we can avoid the memory barrier.
> >
> > Proving that means iterating through the permitted combinations of
> > compilers and architectures... There is always hand-coded assembly
> > language, I suppose.
>
> I'm starting to think that while the C/C++ language spec says they can
> wreck the world by doing these silly optimization, real world users will
> push back for breaking their existing code.
>
> I'm fairly sure the GCC people _will_ get shouted at _loudly_ when they
> break the kernel by doing crazy shit like that.
>
> Given its near impossible to write a correct program in C/C++ and
> tagging the entire kernel with __atomic is equally not going to happen,
> I think we must find a practical solution.
>
> Either that, or we really need to consider forking the language and
> compiler :-(
Depends on how much benefit the optimizations provide. If they provide
little or no benefit, I am with you, otherwise we will need to bit some
bullet or another. Keep in mind that there is a lot of code in the
kernel that runs sequentially (e.g., due to being fully protected by
locks), and aggressive optimizations for that sort of code are harmless.
Can't say I know the answer at the moment, though.
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 17:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, tony.luck, Mathieu Desnoyers, Oleg Nesterov,
LKML, Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131101161819.GV16117@laptop.programming.kicks-ass.net>
On Fri, Nov 01, 2013 at 05:18:19PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > The dependency you are talking about is via the "if" statement?
> > Even C/C++11 is not required to respect control dependencies.
> >
> > This one is a bit annoying. The x86 TSO means that you really only
> > need barrier(), ARM (recent ARM, anyway) and Power could use a weaker
> > barrier, and so on -- but smp_mb() emits a full barrier.
> >
> > Perhaps a new smp_tmb() for TSO semantics, where reads are ordered
> > before reads, writes before writes, and reads before writes, but not
> > writes before reads? Another approach would be to define a per-arch
> > barrier for this particular case.
>
> Supposing a sane language where we can rely on control flow; would that
> change the story?
>
> I'm afraid I'm now terminally confused between actual proper memory
> model issues and fucked compilers.
Power and ARM won't speculate stores, but they will happily speculate
loads. Not sure about Itanium, perhaps Tony knows. And yes, reordering
by the compilers and CPUs does sometimes seem a bit intertwined.
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 17:26 UTC (permalink / raw)
To: Victor Kaplansky
Cc: mbatty, dhowells, Michael Neuling, Mathieu Desnoyers,
Peter Zijlstra, LKML, Oleg Nesterov, Linux PPC dev,
Anton Blanchard, Frederic Weisbecker, lfomicki
In-Reply-To: <20131102163618.GK4067@linux.vnet.ibm.com>
[ Adding David Howells, Lech Fomicki, and Mark Batty on CC for their
thoughts given previous discussions. ]
On Sat, Nov 02, 2013 at 09:36:18AM -0700, Paul E. McKenney wrote:
> On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
> > 08:16:02 AM:
> >
> > > > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > > > around
> > > > @head read.
> >
> > Just to be sure, that we are talking about the same code - I was
> > considering
> > ACCESS_ONCE() around @tail in point AAA in the following example from
> > Documentation/circular-buffers.txt for CONSUMER:
> >
> > unsigned long head = ACCESS_ONCE(buffer->head);
> > unsigned long tail = buffer->tail; /* AAA */
> >
> > if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> > /* read index before reading contents at that index */
> > smp_read_barrier_depends();
> >
> > /* extract one item from the buffer */
> > struct item *item = buffer[tail];
> >
> > consume_item(item);
> >
> > smp_mb(); /* finish reading descriptor before incrementing
> > tail */
> >
> > buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */
> > }
>
> Hmmm... I believe that we need to go back to the original code in
> Documentation/circular-buffers.txt. I do so at the bottom of this email.
>
> > > If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> > > its rights to combine adjacent operations and also to invent loads and
> > > stores, for example, in cases of register pressure.
> >
> > Right. And I was completely aware about these possible transformations when
> > said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
> > even
> > completely dismissed reads of @tail in consumer code, are not a problem at
> > all,
> > since @tail is written exclusively by CONSUMER side.
>
> I believe that the lack of ACCESS_ONCE() around the consumer's store
> to buffer->tail is at least a documentation problem. In the original
> consumer code, it is trapped between an smp_mb() and a spin_unlock(),
> but it is updating something that is read without synchronization by
> some other thread.
>
> > > It is also within
> > > its rights to do piece-at-a-time loads and stores, which might sound
> > > unlikely, but which can actually has happened when the compiler figures
> > > out exactly what is to be stored at compile time, especially on hardware
> > > that only allows small immediate values.
> >
> > As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
> > doesn't prevent in any way an imaginary super-optimizing compiler
> > from moving around the store to @tail (which appears in the code at point
> > BBB).
> >
> > It is why ACCESS_ONCE at point AAA is completely redundant.
>
> Agreed, it is under the lock that guards modifications, so AAA does not
> need ACCESS_ONCE().
>
> OK, here is the producer from Documentation/circular-buffers.txt, with
> some comments added:
>
> spin_lock(&producer_lock);
>
> unsigned long head = buffer->head;
The above is updated only under producer_lock, which we hold, so no
ACCESS_ONCE() is needed for buffer->head.
> unsigned long tail = ACCESS_ONCE(buffer->tail); /* PT */
>
> if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
> /* insert one item into the buffer */
> struct item *item = buffer[head];
>
> produce_item(item); /* PD */
>
> smp_wmb(); /* commit the item before incrementing the head */
>
> buffer->head = (head + 1) & (buffer->size - 1); /* PH */
The above needs to be something like:
ACCESS_ONCE(buffer->head) = (head + 1) & (buffer->size - 1);
This is because we are writing to a shared variable that might be being
read concurrently.
> /* wake_up() will make sure that the head is committed before
> * waking anyone up */
> wake_up(consumer);
> }
>
> spin_unlock(&producer_lock);
>
> And here is the consumer, also from Documentation/circular-buffers.txt:
>
> spin_lock(&consumer_lock);
>
> unsigned long head = ACCESS_ONCE(buffer->head); /* CH */
> unsigned long tail = buffer->tail;
The above is updated only under consumer_lock, which we hold, so no
ACCESS_ONCE() is needed for buffer->tail.
>
> if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> /* read index before reading contents at that index */
> smp_read_barrier_depends();
>
> /* extract one item from the buffer */
> struct item *item = buffer[tail]; /* CD */
>
> consume_item(item);
>
> smp_mb(); /* finish reading descriptor before incrementing tail */
>
> buffer->tail = (tail + 1) & (buffer->size - 1); /* CT */
And here, for no-execution-cost documentation, if nothing else:
ACCESS_ONCE(buffer->tail) = (tail + 1) & (buffer->size - 1);
> }
>
> spin_unlock(&consumer_lock);
>
> Here are the ordering requirements as I see them:
>
> 1. The producer is not allowed to clobber a location that the
> consumer is in the process of reading from.
>
> 2. The consumer is not allowed to read from a location that the
> producer has not yet completed writing to.
>
> #1 is helped out by the fact that there is always an empty element in
> the array, so that the producer will need to produce twice in a row
> to catch up to where the consumer is currently consuming. #2 has no
> such benefit: The consumer can consume an item that has just now been
> produced.
>
> #1 requires that CD is ordered before CT in a way that pairs with the
> ordering of PT and PD. There is of course no effective ordering between
> PT and PD within a given call to the producer, but we only need the
> ordering between the read from PT for one call to the producer and the
> PD of the -next- call to the producer, courtesy of the fact that there
> is always one empty cell in the array. Therefore, the required ordering
> between PT of one call and PD of the next is provided by the unlock-lock
> pair. The ordering of CD and CT is of course provided by the smp_mb().
> (And yes, I was missing the unlock-lock pair earlier. In my defense,
> you did leave this unlock-lock pair out of your example.)
>
> So ordering requirement #1 is handled by the original, but only if you
> leave the locking in place. The producer's smp_wmb() does not necessarily
> order prior loads against subsequent stores, and the wake_up() only
> guarantees ordering if something was actually awakened. As noted earlier,
> the "if" does not necessarily provide ordering.
>
> On to ordering requirement #2.
>
> This requires that CH and CD is ordered in a way that pairs with ordering
> between PD and PH. PD and PH are both writes, so the smp_wmb() does
> the trick there. The consumer side is a bit strange. On DEC Alpha,
> smp_read_barrier_dependes() turns into smp_mb(), so that case is covered
> (though by accident). On other architectures, smp_read_barrier_depends()
> generates no code, and there is no data dependency between the CH and CD.
> The dependency is instead between the read from ->tail and the write,
Sigh. Make that "The dependency is instead between the read from ->tail
and the read from the array."
> and as you noted, ->tail is written by the consumer, not the producer.
And non-dependent reads -can- be speculated, so the
smp_read_barrier_depends() needs to be at least an smp_rmb().
Again, don't take my word for it, try it with either ppcmem or real
weakly ordered hardware.
I am not 100% confident of the patch below, but am getting there.
If a change is really needed, it must of course be propagated to the
uses within the Linux kernel.
Thanx, Paul
> But my battery is dying, so more later, including ACCESS_ONCE().
documentation: Fix circular-buffer example.
The code sample in Documentation/circular-buffers.txt appears to have a
few ordering bugs. This patch therefore applies the needed fixes.
Reported-by: Lech Fomicki <lfomicki@poczta.fm>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt
index 8117e5bf6065..a36bed3db4ee 100644
--- a/Documentation/circular-buffers.txt
+++ b/Documentation/circular-buffers.txt
@@ -170,7 +170,7 @@ The producer will look something like this:
smp_wmb(); /* commit the item before incrementing the head */
- buffer->head = (head + 1) & (buffer->size - 1);
+ ACCESS_ONCE(buffer->head) = (head + 1) & (buffer->size - 1);
/* wake_up() will make sure that the head is committed before
* waking anyone up */
@@ -183,9 +183,14 @@ This will instruct the CPU that the contents of the new item must be written
before the head index makes it available to the consumer and then instructs the
CPU that the revised head index must be written before the consumer is woken.
-Note that wake_up() doesn't have to be the exact mechanism used, but whatever
-is used must guarantee a (write) memory barrier between the update of the head
-index and the change of state of the consumer, if a change of state occurs.
+Note that wake_up() does not guarantee any sort of barrier unless something
+is actually awakened. We therefore cannot rely on it for ordering. However,
+there is always one element of the array left empty. Therefore, the
+producer must produce two elements before it could possibly corrupt the
+element currently being read by the consumer. Therefore, the unlock-lock
+pair between consecutive invocations of the consumer provides the necessary
+ordering between the read of the index indicating that the consumer has
+vacated a given element and the write by the producer to that same element.
THE CONSUMER
@@ -200,7 +205,7 @@ The consumer will look something like this:
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */
- smp_read_barrier_depends();
+ smp_rmb();
/* extract one item from the buffer */
struct item *item = buffer[tail];
@@ -209,7 +214,7 @@ The consumer will look something like this:
smp_mb(); /* finish reading descriptor before incrementing tail */
- buffer->tail = (tail + 1) & (buffer->size - 1);
+ ACCESS_ONCE(buffer->tail) = (tail + 1) & (buffer->size - 1);
}
spin_unlock(&consumer_lock);
@@ -223,7 +228,10 @@ Note the use of ACCESS_ONCE() in both algorithms to read the opposition index.
This prevents the compiler from discarding and reloading its cached value -
which some compilers will do across smp_read_barrier_depends(). This isn't
strictly needed if you can be sure that the opposition index will _only_ be
-used the once.
+used the once. Similarly, ACCESS_ONCE() is used in both algorithms to
+write the thread's index. This documents the fact that we are writing
+to something that can be read concurrently and also prevents the compiler
+from tearing the store.
===============
^ permalink raw reply related
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 15:46 UTC (permalink / raw)
To: Victor Kaplansky
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <OF3CB471BA.BACC7843-ON42257C16.0055EF23-42257C16.0058875B@il.ibm.com>
On Fri, Nov 01, 2013 at 06:06:58PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
> 05:25:43 PM:
>
> > I really don't care about "fair" -- I care instead about the kernel
> > working reliably.
>
> Though I don't see how putting a memory barrier without deep understanding
> why it is needed helps kernel reliability, I do agree that reliability
> is more important than performance.
True enough. Of course, the same applies to removing memory barriers.
> > And it should also be easy for proponents of removing memory barriers to
> > clearly articulate what orderings their code does and does not need.
>
> I intentionally took a simplified example of circle buffer from
> Documentation/circular-buffers.txt. I think both sides agree about
> memory ordering requirements in the example. At least I didn't see anyone
> argued about them.
Hard to say. No one has actually stated them clearly, so how could we
know whether or not we agree.
> > You are assuming control dependencies that the C language does not
> > provide. Now, for all I know right now, there might well be some other
> > reason why a full barrier is not required, but the "if" statement cannot
> > be that reason.
> >
> > Please review section 1.10 of the C++11 standard (or the corresponding
> > section of the C11 standard, if you prefer). The point is that the
> > C/C++11 covers only data dependencies, not control dependencies.
>
> I feel you made a wrong assumption about my expertise in compilers. I don't
> need to reread section 1.10 of the C++11 standard, because I do agree that
> potentially compiler can break the code in our case. And I do agree that
> a compiler barrier() or some other means (including a change of the
> standard)
> can be required in future to prevent a compiler from moving memory accesses
> around.
I was simply reacting to what seemed to me to be your statement that
control dependencies affect ordering. They don't. The C/C++ standard
does not in any way respect control dependencies. In fact, there are
implementations that do not respect control dependencies. But don't
take my word for it, actually try it out on a weakly ordered system.
Or try out either ppcmem or armmem, which does a full state-space search.
Here is the paper:
http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/pldi105-sarkar.pdf
And here is the web-based tool:
http://www.cl.cam.ac.uk/~pes20/ppcmem/
And here is a much faster version that you can run locally:
http://www.cl.cam.ac.uk/~pes20/weakmemory/index.html
> But "broken" compiler is much wider issue to be deeply discussed in this
> thread. I'm pretty sure that kernel have tons of very subtle
> code that actually creates locks and memory ordering. Such code
> usually just use the "barrier()" approach to tell gcc not to combine
> or move memory accesses around it.
>
> Let's just agree for the sake of this memory barrier discussion that we
> *do* need compiler barrier to tell gcc not to combine or move memory
> accesses around it.
Sometimes barrier() is indeed all you need, other times more is needed.
> > Glad we agree on something!
>
> I'm glad too!
>
> > Did you miss the following passage in the paragraph you quoted?
> >
> > "... likewise, your consumer must issue a memory barrier
> > instruction after removing an item from the queue and before
> > reading from its memory."
> >
> > That is why DEC Alpha readers need a read-side memory barrier -- it says
> > so right there. And as either you or Peter noted earlier in this thread,
> > this barrier can be supplied by smp_read_barrier_depends().
>
> I did not miss that passage. That passage explains why consumer on Alpha
> processor after reading @head is required to execute an additional
> smp_read_barrier_depends() before it can *read* from memory pointed by
> @tail. And I think that I understand why - because the reader have to wait
> till local caches are fully updated and only then it can read data from
> the data buffer.
>
> But on the producer side, after we read @tail, we don't need to wait for
> update of local caches before we start *write* data to the buffer, since
> the
> producer is the only one who write data there!
Well, we cannot allow the producer to clobber data while the consumer
is reading it out. That said, I do agree that we should get some help
from the fact that one element of the array is left empty, so that the
producer goes through a full write before clobbering the cell that the
consumer just vacated.
> > I can sympathize if you are having trouble believing this. After all,
> > it took the DEC Alpha architects a full hour to convince me, and that was
> > in a face-to-face meeting instead of over email. (Just for the record,
> > it took me even longer to convince them that their earlier documentation
> > did not clearly indicate the need for these read-side barriers.) But
> > regardless of whether or not I sympathize, DEC Alpha is what it is.
>
> Again, I do understand quirkiness of the DEC Alpha, and I still think that
> there is no need in *full* memory barrier on producer side - the one
> before writing data to the buffer and which you've put in kfifo
> implementation.
There really does need to be some sort of memory barrier there to
order the read of the index before the write into the array element.
Now, it might well be that this barrier is supplied by the unlock-lock
pair guarding the producer, but either way, there does need to be some
ordering.
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 15:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, LKML, Oleg Nesterov,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131101103017.GF19466@laptop.lan>
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote:
> > > This is a completely untenable position.
> >
> > Indeed it is!
> >
> > C/C++ never was intended to be used for parallel programming,
>
> And yet pretty much all kernels ever written for SMP systems are written
> in it; what drugs are those people smoking?
There was a time when I wished that the C/C++ standards people had added
concurrency to the language 30 years ago, but I eventually realized that
any attempt at that time would have been totally broken.
> Furthermore there's a gazillion parallel userspace programs.
Most of which have very unaggressive concurrency designs.
> > and this is
> > but one of the problems that can arise when we nevertheless use it for
> > parallel programming. As compilers get smarter (for some definition of
> > "smarter") and as more systems have special-purpose hardware (such as
> > vector units) that are visible to the compiler, we can expect more of
> > this kind of trouble.
> >
> > This was one of many reasons that I decided to help with the C/C++11
> > effort, whatever anyone might think about the results.
>
> Well, I applaud your efforts, but given the results I think the C/C++
> people are all completely insane.
If it makes you feel any better, they have the same opinion of all of
us who use C/C++ for concurrency given that the standard provides no
guarantee.
> > > How do the C/C++ people propose to deal with this?
> >
> > By marking "ptr" as atomic, thus telling the compiler not to mess with it.
> > And thus requiring that all accesses to it be decorated, which in the
> > case of RCU could be buried in the RCU accessors.
>
> This seems contradictory; marking it atomic would look like:
>
> struct foo {
> unsigned long value;
> __atomic void *ptr;
> unsigned long value1;
> };
>
> Clearly we cannot hide this definition in accessors, because then
> accesses to value* won't see the annotation.
#define __rcu __atomic
Though there are probably placement restrictions for __atomic that
current use of __rcu doesn't pay attention to.
> That said; mandating we mark all 'shared' data with __atomic is
> completely untenable and is not backwards compatible.
>
> To be safe we must assume all data shared unless indicated otherwise.
Something similar to the compiler directives forcing twos-complement
interpretation of signed overflow could be attractive. Not sure what
it would do to code generation, though.
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 17:28 UTC (permalink / raw)
To: Victor Kaplansky
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <OF2F28411B.D04C5B5A-ON42257C16.004E02C5-42257C16.004F420C@il.ibm.com>
On Fri, Nov 01, 2013 at 04:25:42PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
> 08:40:15 AM:
>
> > > void ubuf_read(void)
> > > {
> > > u64 head, tail;
> > >
> > > tail = ACCESS_ONCE(ubuf->tail);
> > > head = ACCESS_ONCE(ubuf->head);
> > >
> > > /*
> > > * Ensure we read the buffer boundaries before the actual buffer
> > > * data...
> > > */
> > > smp_rmb(); /* C, matches with B */
> > >
> > > while (tail != head) {
> > > obj = ubuf->data + tail;
> > > /* process obj */
> > > tail += obj->size;
> > > tail %= ubuf->size;
> > > }
> > >
> > > /*
> > > * Ensure all data reads are complete before we issue the
> > > * ubuf->tail update; once that update hits, kbuf_write() can
> > > * observe and overwrite data.
> > > */
> > > smp_mb(); /* D, matches with A */
> > >
> > > ubuf->tail = tail;
> > > }
>
> > > Could we replace A and C with an smp_read_barrier_depends()?
> >
> > C, yes, given that you have ACCESS_ONCE() on the fetch from ->tail
> > and that the value fetch from ->tail feeds into the address used for
> > the "obj =" assignment.
>
> No! You must to have a full smp_rmb() at C. The race on the reader side
> is not between fetch of @tail and read from address pointed by @tail.
> The real race here is between a fetch of @head and read of obj from
> memory pointed by @tail.
I believe you are in fact correct, good catch.
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 16:36 UTC (permalink / raw)
To: Victor Kaplansky
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <OF6655E55D.554B7448-ON42257C16.00442B8B-42257C16.0048995E@il.ibm.com>
On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
> 08:16:02 AM:
>
> > > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > > around
> > > @head read.
>
> Just to be sure, that we are talking about the same code - I was
> considering
> ACCESS_ONCE() around @tail in point AAA in the following example from
> Documentation/circular-buffers.txt for CONSUMER:
>
> unsigned long head = ACCESS_ONCE(buffer->head);
> unsigned long tail = buffer->tail; /* AAA */
>
> if (CIRC_CNT(head, tail, buffer->size) >= 1) {
> /* read index before reading contents at that index */
> smp_read_barrier_depends();
>
> /* extract one item from the buffer */
> struct item *item = buffer[tail];
>
> consume_item(item);
>
> smp_mb(); /* finish reading descriptor before incrementing
> tail */
>
> buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */
> }
Hmmm... I believe that we need to go back to the original code in
Documentation/circular-buffers.txt. I do so at the bottom of this email.
> > If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> > its rights to combine adjacent operations and also to invent loads and
> > stores, for example, in cases of register pressure.
>
> Right. And I was completely aware about these possible transformations when
> said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
> even
> completely dismissed reads of @tail in consumer code, are not a problem at
> all,
> since @tail is written exclusively by CONSUMER side.
I believe that the lack of ACCESS_ONCE() around the consumer's store
to buffer->tail is at least a documentation problem. In the original
consumer code, it is trapped between an smp_mb() and a spin_unlock(),
but it is updating something that is read without synchronization by
some other thread.
> > It is also within
> > its rights to do piece-at-a-time loads and stores, which might sound
> > unlikely, but which can actually has happened when the compiler figures
> > out exactly what is to be stored at compile time, especially on hardware
> > that only allows small immediate values.
>
> As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
> doesn't prevent in any way an imaginary super-optimizing compiler
> from moving around the store to @tail (which appears in the code at point
> BBB).
>
> It is why ACCESS_ONCE at point AAA is completely redundant.
Agreed, it is under the lock that guards modifications, so AAA does not
need ACCESS_ONCE().
OK, here is the producer from Documentation/circular-buffers.txt, with
some comments added:
spin_lock(&producer_lock);
unsigned long head = buffer->head;
unsigned long tail = ACCESS_ONCE(buffer->tail); /* PT */
if (CIRC_SPACE(head, tail, buffer->size) >= 1) {
/* insert one item into the buffer */
struct item *item = buffer[head];
produce_item(item); /* PD */
smp_wmb(); /* commit the item before incrementing the head */
buffer->head = (head + 1) & (buffer->size - 1); /* PH */
/* wake_up() will make sure that the head is committed before
* waking anyone up */
wake_up(consumer);
}
spin_unlock(&producer_lock);
And here is the consumer, also from Documentation/circular-buffers.txt:
spin_lock(&consumer_lock);
unsigned long head = ACCESS_ONCE(buffer->head); /* CH */
unsigned long tail = buffer->tail;
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */
smp_read_barrier_depends();
/* extract one item from the buffer */
struct item *item = buffer[tail]; /* CD */
consume_item(item);
smp_mb(); /* finish reading descriptor before incrementing tail */
buffer->tail = (tail + 1) & (buffer->size - 1); /* CT */
}
spin_unlock(&consumer_lock);
Here are the ordering requirements as I see them:
1. The producer is not allowed to clobber a location that the
consumer is in the process of reading from.
2. The consumer is not allowed to read from a location that the
producer has not yet completed writing to.
#1 is helped out by the fact that there is always an empty element in
the array, so that the producer will need to produce twice in a row
to catch up to where the consumer is currently consuming. #2 has no
such benefit: The consumer can consume an item that has just now been
produced.
#1 requires that CD is ordered before CT in a way that pairs with the
ordering of PT and PD. There is of course no effective ordering between
PT and PD within a given call to the producer, but we only need the
ordering between the read from PT for one call to the producer and the
PD of the -next- call to the producer, courtesy of the fact that there
is always one empty cell in the array. Therefore, the required ordering
between PT of one call and PD of the next is provided by the unlock-lock
pair. The ordering of CD and CT is of course provided by the smp_mb().
(And yes, I was missing the unlock-lock pair earlier. In my defense,
you did leave this unlock-lock pair out of your example.)
So ordering requirement #1 is handled by the original, but only if you
leave the locking in place. The producer's smp_wmb() does not necessarily
order prior loads against subsequent stores, and the wake_up() only
guarantees ordering if something was actually awakened. As noted earlier,
the "if" does not necessarily provide ordering.
On to ordering requirement #2.
This requires that CH and CD is ordered in a way that pairs with ordering
between PD and PH. PD and PH are both writes, so the smp_wmb() does
the trick there. The consumer side is a bit strange. On DEC Alpha,
smp_read_barrier_dependes() turns into smp_mb(), so that case is covered
(though by accident). On other architectures, smp_read_barrier_depends()
generates no code, and there is no data dependency between the CH and CD.
The dependency is instead between the read from ->tail and the write,
and as you noted, ->tail is written by the consumer, not the producer.
But my battery is dying, so more later, including ACCESS_ONCE().
Thanx, Paul
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-11-02 17:46 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, Oleg Nesterov, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131101161129.GU16117@laptop.programming.kicks-ass.net>
On Fri, Nov 01, 2013 at 05:11:29PM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > > void kbuf_write(int sz, void *buf)
> > > {
> > > u64 tail = ACCESS_ONCE(ubuf->tail); /* last location userspace read */
> > > u64 offset = kbuf->head; /* we already know where we last wrote */
> > > u64 head = offset + sz;
> > >
> > > if (!space(tail, offset, head)) {
> > > /* discard @buf */
> > > return;
> > > }
> > >
> > > /*
> > > * Ensure that if we see the userspace tail (ubuf->tail) such
> > > * that there is space to write @buf without overwriting data
> > > * userspace hasn't seen yet, we won't in fact store data before
> > > * that read completes.
> > > */
> > >
> > > smp_mb(); /* A, matches with D */
> > >
> > > write(kbuf->data + offset, buf, sz);
> > > kbuf->head = head % kbuf->size;
> > >
> > > /*
> > > * Ensure that we write all the @buf data before we update the
> > > * userspace visible ubuf->head pointer.
> > > */
> > > smp_wmb(); /* B, matches with C */
> > >
> > > ubuf->head = kbuf->head;
> > > }
>
> > > Now the whole crux of the question is if we need barrier A at all, since
> > > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > > read.
> >
> > The dependency you are talking about is via the "if" statement?
> > Even C/C++11 is not required to respect control dependencies.
>
> But surely we must be able to make it so; otherwise you'd never be able
> to write:
>
> void *ptr = obj1;
>
> void foo(void)
> {
>
> /* create obj2, obj3 */
>
> smp_wmb(); /* ensure the objs are complete */
>
> /* expose either obj2 or obj3 */
> if (x)
> ptr = obj2;
> else
> ptr = obj3;
OK, the smp_wmb() orders the creation and the exposing. But the
compiler can do this:
ptr = obj3;
if (x)
ptr = obj2;
And that could momentarily expose obj3 to readers, and these readers
might be fatally disappointed by the free() below. If you instead said:
if (x)
ACCESS_ONCE(ptr) = obj2;
else
ACCESS_ONCE(ptr) = obj3;
then the general consensus appears to be that the compiler would not
be permitted to carry out the above optimization. Since you have
the smp_wmb(), readers that are properly ordered (e.g., smp_rmb() or
rcu_dereference()) would be prevented from seeing pre-initialization
state.
> /* free the unused one */
> if (x)
> free(obj3);
> else
> free(obj2);
> }
>
> Earlier you said that 'volatile' or '__atomic' avoids speculative
> writes; so would:
>
> volatile void *ptr = obj1;
>
> Make the compiler respect control dependencies again? If so, could we
> somehow mark that !space() condition volatile?
The compiler should, but the CPU is still free to ignore the control
dependencies in the general case.
We might be able to rely on weakly ordered hardware refraining
from speculating stores, but not sure that this applies across all
architectures of interest. We definitely can -not- rely on weakly
ordered hardware refraining from speculating loads.
> Currently the above would be considered a valid pattern. But you're
> saying its not because the compiler is free to expose both obj2 and obj3
> (for however short a time) and thus the free of the 'unused' object is
> incorrect and can cause use-after-free.
Yes, it is definitely unsafe and invalid in absence of ACCESS_ONCE().
> In fact; how can we be sure that:
>
> void *ptr = NULL;
>
> void bar(void)
> {
> void *obj = malloc(...);
>
> /* fill obj */
>
> if (!err)
> rcu_assign_pointer(ptr, obj);
> else
> free(obj);
> }
>
> Does not get 'optimized' into:
>
> void bar(void)
> {
> void *obj = malloc(...);
> void *old_ptr = ptr;
>
> /* fill obj */
>
> rcu_assign_pointer(ptr, obj);
> if (err) { /* because runtime profile data says this is unlikely */
> ptr = old_ptr;
> free(obj);
> }
> }
In this particular case, the barrier() implied by the smp_wmb() in
rcu_assign_pointer() will prevent this "optimization". However, other
"optimizations" are the reason why I am working to introduce ACCESS_ONCE()
into rcu_assign_pointer.
> We _MUST_ be able to rely on control flow, otherwise me might as well
> all go back to writing kernels in asm.
It isn't -that- bad! ;-)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 0/2] move of_find_next_cache_node to DT core
From: Grant Likely @ 2013-11-02 18:06 UTC (permalink / raw)
To: Sudeep KarkadaNagesha, Sudeep KarkadaNagesha
Cc: devicetree@vger.kernel.org, Rob Herring,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <524E9BA9.4000506@arm.com>
On Fri, 04 Oct 2013 11:42:49 +0100, Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com> wrote:
> Hi Grant,
>
> On 18/09/13 17:18, Sudeep KarkadaNagesha wrote:
> > On 18/09/13 15:51, Grant Likely wrote:
> >> On Wed, 18 Sep 2013 11:53:03 +0100, Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com> wrote:
> >>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
> >>>
> >>> Hi,
> >>>
> >>> The cache bindings are generic and used by many other architectures
> >>> apart from PPC. These patches fixes and move the existing definition
> >>> of of_find_next_cache_node to DT common code.
> >>>
> >>> Regards,
> >>> Sudeep
> >>
> >> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >>
> >> However, do you have a user for this function on other architectures
> >> yet? I'd like to see a user for the function in the same patch series..
> >>
> >
> > Yes I have posted an RFC[1] following this series implementing cacheinfo
> > for ARM similar to x86 implementation. I was not sure if it's good idea
> > to combine it as its still initial RFC version.
> >
>
> Do you prefer to have this a independent change or to go with the cache topology
> support patches[1] on ARM ?
Ben's already picked it up, so I'm fine with it.
g.
^ permalink raw reply
* Re: linux-next: manual merge of the dt-rh tree with the powerpc tree
From: Benjamin Herrenschmidt @ 2013-11-01 23:13 UTC (permalink / raw)
To: Rob Herring
Cc: Sudeep KarkadaNagesha, Stephen Rothwell, linux-next, linuxppc-dev,
linux-kernel
In-Reply-To: <52742A2A.9080008@gmail.com>
On Fri, 2013-11-01 at 17:24 -0500, Rob Herring wrote:
> On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> > Hi Rob,
> >
> > Today's linux-next merge of the dt-rh tree got a conflict in
> > arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> > Move definition of of_find_next_cache_node into common code") from
> > the powerpc tree and commit 0c3f061c195c ("of: implement
> > of_node_to_nid as a weak function") from the dt-rh tree.
>
> Ben, I can pick these 2 patches up instead if you want to drop them
> and avoid the conflict.
I'd rather not rebase my tree, the conflict seems to be rather trivial
to solve.
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: manual merge of the dt-rh tree with the powerpc tree
From: Stephen Rothwell @ 2013-11-01 22:27 UTC (permalink / raw)
To: Rob Herring; +Cc: Sudeep KarkadaNagesha, linux-next, linuxppc-dev, linux-kernel
In-Reply-To: <52742A2A.9080008@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Hi Rob,
On Fri, 01 Nov 2013 17:24:42 -0500 Rob Herring <robherring2@gmail.com> wrote:
>
> On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the dt-rh tree got a conflict in
> > arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> > Move definition of of_find_next_cache_node into common code") from
> > the powerpc tree and commit 0c3f061c195c ("of: implement
> > of_node_to_nid as a weak function") from the dt-rh tree.
>
> Ben, I can pick these 2 patches up instead if you want to drop them
> and avoid the conflict.
The conflict is pretty trivial and so should not require any action.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the dt-rh tree with the powerpc tree
From: Rob Herring @ 2013-11-01 22:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Sudeep KarkadaNagesha, linux-next, linuxppc-dev, linux-kernel
In-Reply-To: <20131101162002.4dd386299ec42e8d8d032be2@canb.auug.org.au>
On 11/01/2013 12:20 AM, Stephen Rothwell wrote:
> Hi Rob,
>
> Today's linux-next merge of the dt-rh tree got a conflict in
> arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of:
> Move definition of of_find_next_cache_node into common code") from
> the powerpc tree and commit 0c3f061c195c ("of: implement
> of_node_to_nid as a weak function") from the dt-rh tree.
Ben, I can pick these 2 patches up instead if you want to drop them
and avoid the conflict.
Rob
^ permalink raw reply
* Re: [PATCHv2 5/8] ASoC: SGTL5000: Enhance the SGTL5000 codec driver about regulator.
From: Mark Brown @ 2013-11-01 18:50 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1383289495-24523-6-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
On Fri, Nov 01, 2013 at 03:04:52PM +0800, Xiubo Li wrote:
> On VF610 series there are no regulators used, and now whether the
> CONFIG_REGULATOR mirco is enabled or not, for the VF610 audio
> patch series, the board cannot be probe successfully.
> And this patch will solve this issue.
I don't understand what this is for at all, you're just saying there is
a problem you're trying to solve but you don't explain anything about
what the problem is or how your changes address it.
> +#ifndef CONFIG_SND_SOC_FSL_SGTL5000_VF610
> static int ldo_regulator_register(struct snd_soc_codec *codec,
This is definitely broken, it won't work with multi-platform kernels,
and I don't understand what this is supposed to do - what is the reason
for making this change?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
From: Mark Brown @ 2013-11-01 18:40 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1383289495-24523-7-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
On Fri, Nov 01, 2013 at 03:04:53PM +0800, Xiubo Li wrote:
> Conflicts:
> sound/soc/fsl/Makefile
Ahem.
> + /* TODO: The SAI driver should figure this out for us */
> + switch (channels) {
> + case 2:
> + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffffffc, 0xfffffffc, 2, 0);
> + break;
> + case 1:
> + snd_soc_dai_set_tdm_slot(cpu_dai, 0xfffffffe, 0xfffffffe, 1, 0);
> + break;
> + default:
> + return -EINVAL;
> + }
Yes, it should - this code should probably just be copied straight into
the SAI driver. If we need to support other configurations we can do
that later.
> +static int fsl_sgtl5000_remove(struct platform_device *pdev)
> +{
> + snd_soc_unregister_card(&fsl_sgt1500_card);
> +
> + return 0;
> +}
You're using snd_soc_unregister_card() so you don't need to do this.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Mark Brown @ 2013-11-01 18:25 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, b42378, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring, oskar,
fabio.estevam, lgirdwood, linux-kernel, rob, r64188, shawn.guo,
linuxppc-dev
In-Reply-To: <1383289495-24523-2-git-send-email-Li.Xiubo@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Fri, Nov 01, 2013 at 03:04:48PM +0800, Xiubo Li wrote:
> +static int fsl_sai_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
> + int div_id, int div)
> +{
> + struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> + u32 tcr2, rcr2;
> +
> + if (div_id == FSL_SAI_TX_DIV) {
> + tcr2 = readl(sai->base + FSL_SAI_TCR2);
> + tcr2 &= ~FSL_SAI_CR2_DIV_MASK;
> + tcr2 |= FSL_SAI_CR2_DIV(div);
> + writel(tcr2, sai->base + FSL_SAI_TCR2);
What is this divider and why does the user have to set it manually?
> + } else
> + return -EINVAL;
> +
Coding style?
> +static int fsl_sai_dai_probe(struct snd_soc_dai *dai)
> +{
> + int ret;
> + struct fsl_sai *sai = dev_get_drvdata(dai->dev);
> +
> + ret = clk_prepare_enable(sai->clk);
> + if (ret)
> + return ret;
It'd be nicer to only enable the clock while the device is in active
use.
> + ret = snd_dmaengine_pcm_register(&pdev->dev, NULL,
> + SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
> + if (ret)
> + return ret;
We should have a devm_ version of this.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-11-01 16:30 UTC (permalink / raw)
To: David Laight
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra,
Frederic Weisbecker, LKML, Oleg Nesterov, Linux PPC dev,
Anton Blanchard, paulmck
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73D4@saturn3.aculab.com>
"David Laight" <David.Laight@aculab.com> wrote on 11/01/2013 06:25:29 PM:
> gcc will do unexpected memory accesses for bit fields that are
> adjacent to volatile data.
> In particular it may generate 64bit sized (and aligned) RMW cycles
> when accessing bit fields.
> And yes, this has caused real problems.
Thanks, I am aware about this bug/feature in gcc.
-- Victor
^ permalink raw reply
* RE: perf events ring buffer memory barrier on powerpc
From: David Laight @ 2013-11-01 16:25 UTC (permalink / raw)
To: Victor Kaplansky, paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra,
Frederic Weisbecker, LKML, Oleg Nesterov, Linux PPC dev,
Anton Blanchard
In-Reply-To: <OF3CB471BA.BACC7843-ON42257C16.0055EF23-42257C16.0058875B@il.ibm.com>
> But "broken" compiler is much wider issue to be deeply discussed in =
this
> thread. I'm pretty sure that kernel have tons of very subtle
> code that actually creates locks and memory ordering. Such code
> usually just use the "barrier()" approach to tell gcc not to combine
> or move memory accesses around it.
gcc will do unexpected memory accesses for bit fields that are
adjacent to volatile data.
In particular it may generate 64bit sized (and aligned) RMW cycles
when accessing bit fields.
And yes, this has caused real problems.
David
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-11-01 16:18 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, Oleg Nesterov, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031064015.GV4126@linux.vnet.ibm.com>
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> The dependency you are talking about is via the "if" statement?
> Even C/C++11 is not required to respect control dependencies.
>
> This one is a bit annoying. The x86 TSO means that you really only
> need barrier(), ARM (recent ARM, anyway) and Power could use a weaker
> barrier, and so on -- but smp_mb() emits a full barrier.
>
> Perhaps a new smp_tmb() for TSO semantics, where reads are ordered
> before reads, writes before writes, and reads before writes, but not
> writes before reads? Another approach would be to define a per-arch
> barrier for this particular case.
Supposing a sane language where we can rely on control flow; would that
change the story?
I'm afraid I'm now terminally confused between actual proper memory
model issues and fucked compilers.
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-11-01 16:11 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, Oleg Nesterov, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031064015.GV4126@linux.vnet.ibm.com>
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > void kbuf_write(int sz, void *buf)
> > {
> > u64 tail = ACCESS_ONCE(ubuf->tail); /* last location userspace read */
> > u64 offset = kbuf->head; /* we already know where we last wrote */
> > u64 head = offset + sz;
> >
> > if (!space(tail, offset, head)) {
> > /* discard @buf */
> > return;
> > }
> >
> > /*
> > * Ensure that if we see the userspace tail (ubuf->tail) such
> > * that there is space to write @buf without overwriting data
> > * userspace hasn't seen yet, we won't in fact store data before
> > * that read completes.
> > */
> >
> > smp_mb(); /* A, matches with D */
> >
> > write(kbuf->data + offset, buf, sz);
> > kbuf->head = head % kbuf->size;
> >
> > /*
> > * Ensure that we write all the @buf data before we update the
> > * userspace visible ubuf->head pointer.
> > */
> > smp_wmb(); /* B, matches with C */
> >
> > ubuf->head = kbuf->head;
> > }
> > Now the whole crux of the question is if we need barrier A at all, since
> > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > read.
>
> The dependency you are talking about is via the "if" statement?
> Even C/C++11 is not required to respect control dependencies.
But surely we must be able to make it so; otherwise you'd never be able
to write:
void *ptr = obj1;
void foo(void)
{
/* create obj2, obj3 */
smp_wmb(); /* ensure the objs are complete */
/* expose either obj2 or obj3 */
if (x)
ptr = obj2;
else
ptr = obj3;
/* free the unused one */
if (x)
free(obj3);
else
free(obj2);
}
Earlier you said that 'volatile' or '__atomic' avoids speculative
writes; so would:
volatile void *ptr = obj1;
Make the compiler respect control dependencies again? If so, could we
somehow mark that !space() condition volatile?
Currently the above would be considered a valid pattern. But you're
saying its not because the compiler is free to expose both obj2 and obj3
(for however short a time) and thus the free of the 'unused' object is
incorrect and can cause use-after-free.
In fact; how can we be sure that:
void *ptr = NULL;
void bar(void)
{
void *obj = malloc(...);
/* fill obj */
if (!err)
rcu_assign_pointer(ptr, obj);
else
free(obj);
}
Does not get 'optimized' into:
void bar(void)
{
void *obj = malloc(...);
void *old_ptr = ptr;
/* fill obj */
rcu_assign_pointer(ptr, obj);
if (err) { /* because runtime profile data says this is unlikely */
ptr = old_ptr;
free(obj);
}
}
We _MUST_ be able to rely on control flow, otherwise me might as well
all go back to writing kernels in asm.
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-11-01 16:06 UTC (permalink / raw)
To: paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <20131031152543.GC4067@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
05:25:43 PM:
> I really don't care about "fair" -- I care instead about the kernel
> working reliably.
Though I don't see how putting a memory barrier without deep understanding
why it is needed helps kernel reliability, I do agree that reliability
is more important than performance.
> And it should also be easy for proponents of removing memory barriers to
> clearly articulate what orderings their code does and does not need.
I intentionally took a simplified example of circle buffer from
Documentation/circular-buffers.txt. I think both sides agree about
memory ordering requirements in the example. At least I didn't see anyone
argued about them.
> You are assuming control dependencies that the C language does not
> provide. Now, for all I know right now, there might well be some other
> reason why a full barrier is not required, but the "if" statement cannot
> be that reason.
>
> Please review section 1.10 of the C++11 standard (or the corresponding
> section of the C11 standard, if you prefer). The point is that the
> C/C++11 covers only data dependencies, not control dependencies.
I feel you made a wrong assumption about my expertise in compilers. I don't
need to reread section 1.10 of the C++11 standard, because I do agree that
potentially compiler can break the code in our case. And I do agree that
a compiler barrier() or some other means (including a change of the
standard)
can be required in future to prevent a compiler from moving memory accesses
around.
But "broken" compiler is much wider issue to be deeply discussed in this
thread. I'm pretty sure that kernel have tons of very subtle
code that actually creates locks and memory ordering. Such code
usually just use the "barrier()" approach to tell gcc not to combine
or move memory accesses around it.
Let's just agree for the sake of this memory barrier discussion that we
*do* need compiler barrier to tell gcc not to combine or move memory
accesses around it.
> Glad we agree on something!
I'm glad too!
> Did you miss the following passage in the paragraph you quoted?
>
> "... likewise, your consumer must issue a memory barrier
> instruction after removing an item from the queue and before
> reading from its memory."
>
> That is why DEC Alpha readers need a read-side memory barrier -- it says
> so right there. And as either you or Peter noted earlier in this thread,
> this barrier can be supplied by smp_read_barrier_depends().
I did not miss that passage. That passage explains why consumer on Alpha
processor after reading @head is required to execute an additional
smp_read_barrier_depends() before it can *read* from memory pointed by
@tail. And I think that I understand why - because the reader have to wait
till local caches are fully updated and only then it can read data from
the data buffer.
But on the producer side, after we read @tail, we don't need to wait for
update of local caches before we start *write* data to the buffer, since
the
producer is the only one who write data there!
>
> I can sympathize if you are having trouble believing this. After all,
> it took the DEC Alpha architects a full hour to convince me, and that was
> in a face-to-face meeting instead of over email. (Just for the record,
> it took me even longer to convince them that their earlier documentation
> did not clearly indicate the need for these read-side barriers.) But
> regardless of whether or not I sympathize, DEC Alpha is what it is.
Again, I do understand quirkiness of the DEC Alpha, and I still think that
there is no need in *full* memory barrier on producer side - the one
before writing data to the buffer and which you've put in kfifo
implementation.
Regard,
-- Victor
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-11-01 14:56 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, Oleg Nesterov, LKML,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031064015.GV4126@linux.vnet.ibm.com>
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
> > Now the whole crux of the question is if we need barrier A at all, since
> > the STORES issued by the @buf writes are dependent on the ubuf->tail
> > read.
>
> The dependency you are talking about is via the "if" statement?
> Even C/C++11 is not required to respect control dependencies.
>
> This one is a bit annoying. The x86 TSO means that you really only
> need barrier(), ARM (recent ARM, anyway) and Power could use a weaker
> barrier, and so on -- but smp_mb() emits a full barrier.
>
> Perhaps a new smp_tmb() for TSO semantics, where reads are ordered
> before reads, writes before writes, and reads before writes, but not
> writes before reads? Another approach would be to define a per-arch
> barrier for this particular case.
I suppose we can only introduce new barrier primitives if there's more
than 1 use-case.
> > If the read shows no available space, we simply will not issue those
> > writes -- therefore we could argue we can avoid the memory barrier.
>
> Proving that means iterating through the permitted combinations of
> compilers and architectures... There is always hand-coded assembly
> language, I suppose.
I'm starting to think that while the C/C++ language spec says they can
wreck the world by doing these silly optimization, real world users will
push back for breaking their existing code.
I'm fairly sure the GCC people _will_ get shouted at _loudly_ when they
break the kernel by doing crazy shit like that.
Given its near impossible to write a correct program in C/C++ and
tagging the entire kernel with __atomic is equally not going to happen,
I think we must find a practical solution.
Either that, or we really need to consider forking the language and
compiler :-(
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-11-01 14:25 UTC (permalink / raw)
To: paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <20131031064015.GV4126@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
08:40:15 AM:
> > void ubuf_read(void)
> > {
> > u64 head, tail;
> >
> > tail = ACCESS_ONCE(ubuf->tail);
> > head = ACCESS_ONCE(ubuf->head);
> >
> > /*
> > * Ensure we read the buffer boundaries before the actual buffer
> > * data...
> > */
> > smp_rmb(); /* C, matches with B */
> >
> > while (tail != head) {
> > obj = ubuf->data + tail;
> > /* process obj */
> > tail += obj->size;
> > tail %= ubuf->size;
> > }
> >
> > /*
> > * Ensure all data reads are complete before we issue the
> > * ubuf->tail update; once that update hits, kbuf_write() can
> > * observe and overwrite data.
> > */
> > smp_mb(); /* D, matches with A */
> >
> > ubuf->tail = tail;
> > }
> > Could we replace A and C with an smp_read_barrier_depends()?
>
> C, yes, given that you have ACCESS_ONCE() on the fetch from ->tail
> and that the value fetch from ->tail feeds into the address used for
> the "obj =" assignment.
No! You must to have a full smp_rmb() at C. The race on the reader side
is not between fetch of @tail and read from address pointed by @tail.
The real race here is between a fetch of @head and read of obj from
memory pointed by @tail.
Regards,
-- Victor
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-11-01 13:12 UTC (permalink / raw)
To: paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <20131031061602.GU4126@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
08:16:02 AM:
> > BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
> > around
> > @head read.
Just to be sure, that we are talking about the same code - I was
considering
ACCESS_ONCE() around @tail in point AAA in the following example from
Documentation/circular-buffers.txt for CONSUMER:
unsigned long head = ACCESS_ONCE(buffer->head);
unsigned long tail = buffer->tail; /* AAA */
if (CIRC_CNT(head, tail, buffer->size) >= 1) {
/* read index before reading contents at that index */
smp_read_barrier_depends();
/* extract one item from the buffer */
struct item *item = buffer[tail];
consume_item(item);
smp_mb(); /* finish reading descriptor before incrementing
tail */
buffer->tail = (tail + 1) & (buffer->size - 1); /* BBB */
}
>
> If you omit the ACCESS_ONCE() calls around @tail, the compiler is within
> its rights to combine adjacent operations and also to invent loads and
> stores, for example, in cases of register pressure.
Right. And I was completely aware about these possible transformations when
said that ACCESS_ONCE() around @tail in point AAA is redundant. Moved, or
even
completely dismissed reads of @tail in consumer code, are not a problem at
all,
since @tail is written exclusively by CONSUMER side.
> It is also within
> its rights to do piece-at-a-time loads and stores, which might sound
> unlikely, but which can actually has happened when the compiler figures
> out exactly what is to be stored at compile time, especially on hardware
> that only allows small immediate values.
As for writes to @tail, the ACCESS_ONCE around @tail at point AAA,
doesn't prevent in any way an imaginary super-optimizing compiler
from moving around the store to @tail (which appears in the code at point
BBB).
It is why ACCESS_ONCE at point AAA is completely redundant.
-- Victor
^ permalink raw reply
* Re: [PATCHv2 6/8] ASoC: fsl: add SGTL5000 based audio machine driver.
From: Shawn Guo @ 2013-11-01 12:07 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur, perex,
r65073, LW, linux, Xiubo Li, linux-arm-kernel, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, oskar, fabio.estevam, lgirdwood, linux-kernel, rob,
r64188, linuxppc-dev
In-Reply-To: <20131101102805.GG28401@MrMyself>
On Fri, Nov 01, 2013 at 06:28:05PM +0800, Nicolin Chen wrote:
> > sound/soc/fsl/fsl-sgtl5000-vf610.c | 208 +++++++++++++++++++++++++++++++++++++
>
> I just doubt if this file naming is appropriate. Even if we might not have
> rigor rule for the file names, according to existing ones, they are all in
> a same pattern: [SoC name]-[codec name].c
>
> "imx-sgtl5000.c" for example
>
> I think it would make user less confused about what this file exactly is if
> this machine driver also follow the pattern: vf610-sgtl5000.c
>
>
> @Shawn
>
> What do you think about the file name?
Yeah, it would be better to name the file following the existing the
pattern.
Shawn
^ permalink raw reply
* Re: Gianfar driver crashes in Kernel v3.10
From: Claudiu Manoil @ 2013-11-01 11:51 UTC (permalink / raw)
To: Thomas Hühn; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <05E1EDFE-EDFB-4E6F-AA83-D353B4032CA5@net.t-labs.tu-berlin.de>
Hi Thomas,
On 10/31/2013 1:51 PM, Thomas H=FChn wrote:
> Hi Claudiu,
>
>
>> Please try the following patch:
>> http://patchwork.ozlabs.org/patch/283235/
>>
>> It should help with your issue.
>>
>
> Several OpenWrt users including myself have tested your patch on
> TPLink-4900 routers.
> We do have positive feedback, as no crash nor system freeze was reporte=
d
> for different
> network loads and router setups.
> All different scenarios / details and two digit uptimes are in this
> forum thread:
> https://forum.openwrt.org/viewtopic.php?id=3D42062&p=3D13
>
> Thanks again for your work and I hope to see this patch merged upstrea=
m.
>
> Greetings Thomas
>
Thanks for the testing and feedback.
The patch has been merged into davem/net-next.git:
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=
=3D3ba405db1c1b05d157474c71e559393f7ea436ad
And I think it will be merged from there into the next
kernel release. I think that in time it will be back-ported
to stable kernel versions too. In some cases, requests are made
to the netdev mailing list to speedup inclusion of fixes (such
as this one) to certain stable kernel versions.
Thanks,
Claudiu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox