On Fri, Sep 30, 2016 at 02:51:13PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 30, 2016 at 05:14:03AM -0700, Paul E. McKenney wrote:
> > PowerPC does not "obscure" stores, so both stores really are there and
> > the lwsync really has effect on all CPUs. From what I understand, even
> > CPUs that
On Fri, Sep 30, 2016 at 02:51:13PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 30, 2016 at 05:14:03AM -0700, Paul E. McKenney wrote:
> > PowerPC does not "obscure" stores, so both stores really are there and
> > the lwsync really has effect on all CPUs. From what I understand, even
> > CPUs that
On Fri, Sep 30, 2016 at 02:45:42PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 30, 2016 at 05:17:21AM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
>
> > > So its a pretty dumb thing to do in any case (and yes the kernel does
> > > this). Its
On Fri, Sep 30, 2016 at 02:45:42PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 30, 2016 at 05:17:21AM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
>
> > > So its a pretty dumb thing to do in any case (and yes the kernel does
> > > this). Its
On Fri, Sep 30, 2016 at 05:14:03AM -0700, Paul E. McKenney wrote:
> PowerPC does not "obscure" stores, so both stores really are there and
> the lwsync really has effect on all CPUs. From what I understand, even
> CPUs that do obscure stores only do so in the case of repeated stores
> by the same
On Fri, Sep 30, 2016 at 05:14:03AM -0700, Paul E. McKenney wrote:
> PowerPC does not "obscure" stores, so both stores really are there and
> the lwsync really has effect on all CPUs. From what I understand, even
> CPUs that do obscure stores only do so in the case of repeated stores
> by the same
On Fri, Sep 30, 2016 at 05:17:21AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
> > So its a pretty dumb thing to do in any case (and yes the kernel does
> > this). Its also entirely expected in my book, that if you generate
> > conflicting
On Fri, Sep 30, 2016 at 05:17:21AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
> > So its a pretty dumb thing to do in any case (and yes the kernel does
> > this). Its also entirely expected in my book, that if you generate
> > conflicting
On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation
On Fri, Sep 30, 2016 at 12:25:16PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation
On Fri, Sep 30, 2016 at 11:57:38AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
>
> > > How about something like so on PPC?
> > >
> > > P0(int *x, int *y)
> > > {
> > >
On Fri, Sep 30, 2016 at 11:57:38AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
>
> > > How about something like so on PPC?
> > >
> > > P0(int *x, int *y)
> > > {
> > >
On Fri, Sep 30, 2016 at 10:20:09AM +0100, Will Deacon wrote:
> On Fri, Sep 30, 2016 at 01:53:52PM +0800, Boqun Feng wrote:
> > On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Fri, Sep 30, 2016 at 10:20:09AM +0100, Will Deacon wrote:
> On Fri, Sep 30, 2016 at 01:53:52PM +0800, Boqun Feng wrote:
> > On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> broken if a third process overwrites the value written by the RELEASE
> operation before the ACQUIRE operation has a chance of reading it, for
> example:
>
On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> broken if a third process overwrites the value written by the RELEASE
> operation before the ACQUIRE operation has a chance of reading it, for
> example:
>
On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > How about something like so on PPC?
> >
> > P0(int *x, int *y)
> > {
> > WRITE_ONCE(*x, 1);
> > smp_store_release(y, 1);
> > }
> >
> > P1(int *x, int
On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > How about something like so on PPC?
> >
> > P0(int *x, int *y)
> > {
> > WRITE_ONCE(*x, 1);
> > smp_store_release(y, 1);
> > }
> >
> > P1(int *x, int
On Fri, Sep 30, 2016 at 01:53:52PM +0800, Boqun Feng wrote:
> On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation before
On Fri, Sep 30, 2016 at 01:53:52PM +0800, Boqun Feng wrote:
> On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation before
On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > > > >
> > > > > P0(int *x, int *y)
> > > > > {
> > > > >
On Thu, Sep 29, 2016 at 12:18:58PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > > > >
> > > > > P0(int *x, int *y)
> > > > > {
> > > > >
On Thu, Sep 29, 2016 at 03:36:38PM -0400, Alan Stern wrote:
> > > If you execute P0 and P1 concurrently and one store of each 'wins' the
> > > LWSYNC of either is null and void, and therefore P2 is unordered and can
> > > observe r2==0.
>
> Not so. lwsync instructions cannot be "voided".
I
On Thu, Sep 29, 2016 at 03:36:38PM -0400, Alan Stern wrote:
> > > If you execute P0 and P1 concurrently and one store of each 'wins' the
> > > LWSYNC of either is null and void, and therefore P2 is unordered and can
> > > observe r2==0.
>
> Not so. lwsync instructions cannot be "voided".
I
Hi Paul,
On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > > On Thu, Sep
Hi Paul,
On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > > On Thu, Sep
On Thu, Sep 29, 2016 at 03:36:38PM -0400, Alan Stern wrote:
> On Thu, 29 Sep 2016, Paul E. McKenney wrote:
>
> > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
>
> > > How about something like so on PPC?
> > >
> > > P0(int *x, int *y)
> > > {
> > > WRITE_ONCE(*x, 1);
> > >
On Thu, Sep 29, 2016 at 03:36:38PM -0400, Alan Stern wrote:
> On Thu, 29 Sep 2016, Paul E. McKenney wrote:
>
> > On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
>
> > > How about something like so on PPC?
> > >
> > > P0(int *x, int *y)
> > > {
> > > WRITE_ONCE(*x, 1);
> > >
On Thu, 29 Sep 2016, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > How about something like so on PPC?
> >
> > P0(int *x, int *y)
> > {
> > WRITE_ONCE(*x, 1);
> > smp_store_release(y, 1);
> > }
> >
> > P1(int *x, int *y)
> > {
> >
On Thu, 29 Sep 2016, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> > How about something like so on PPC?
> >
> > P0(int *x, int *y)
> > {
> > WRITE_ONCE(*x, 1);
> > smp_store_release(y, 1);
> > }
> >
> > P1(int *x, int *y)
> > {
> >
On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > > >
> > > > P0(int *x, int *y)
> > > > {
> > > > WRITE_ONCE(*x, 1);
> > > > smp_wmb();
> > > >
On Thu, Sep 29, 2016 at 08:44:39PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > > >
> > > > P0(int *x, int *y)
> > > > {
> > > > WRITE_ONCE(*x, 1);
> > > > smp_wmb();
> > > >
On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > >
> > > P0(int *x, int *y)
> > > {
> > > WRITE_ONCE(*x, 1);
> > > smp_wmb();
> > > smp_store_release(y, 1);
> > > }
> > >
> > > P1(int *y)
> > > {
> > > WRITE_ONCE(*y, 2);
> >
On Thu, Sep 29, 2016 at 11:10:15AM -0700, Paul E. McKenney wrote:
> > >
> > > P0(int *x, int *y)
> > > {
> > > WRITE_ONCE(*x, 1);
> > > smp_wmb();
> > > smp_store_release(y, 1);
> > > }
> > >
> > > P1(int *y)
> > > {
> > > WRITE_ONCE(*y, 2);
> >
On Thu, Sep 29, 2016 at 11:04:44AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > > On Thu, Sep 29,
On Thu, Sep 29, 2016 at 11:04:44AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > > On Thu, Sep 29,
On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > > On Thu, Sep 29, 2016 at
On Thu, Sep 29, 2016 at 10:23:22AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > > On Thu, Sep 29, 2016 at
On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Sep 29, 2016 at
On Thu, Sep 29, 2016 at 06:10:37PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> > On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > > On Thu, Sep 29, 2016 at
On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > > If two processes are
On Thu, Sep 29, 2016 at 09:43:53AM -0700, Paul E. McKenney wrote:
> On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > > If two processes are
On Thu, Sep 29, 2016 at 06:17:38PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > > If two processes are
On Thu, Sep 29, 2016 at 06:17:38PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> > On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > > If two processes are
On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third
On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation
On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > broken if a third process overwrites the value written by the RELEASE
> > operation
On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> broken if a third process overwrites the value written by the RELEASE
> operation before the ACQUIRE operation has a chance of reading it.
> This commit
On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> broken if a third process overwrites the value written by the RELEASE
> operation before the ACQUIRE operation has a chance of reading it.
> This commit
If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
broken if a third process overwrites the value written by the RELEASE
operation before the ACQUIRE operation has a chance of reading it.
This commit therefore updates the documentation to call this vulnerability
out
If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
broken if a third process overwrites the value written by the RELEASE
operation before the ACQUIRE operation has a chance of reading it.
This commit therefore updates the documentation to call this vulnerability
out
54 matches
Mail list logo
