linux-kernel - Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171006201537.GZ6524@worktop.programming.kicks-ass.net>
Date:   Fri, 6 Oct 2017 22:15:37 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...nel.org,
        jiangshanlai@...il.com, dipankar@...ibm.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
        oleg@...hat.com
Subject: Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of
 migrations and delays

On Fri, Oct 06, 2017 at 12:18:22PM -0700, Paul E. McKenney wrote:
> > /me goes and install this herd thing again.. I'm sure I had it running
> > _somewhere_.. A well.
> > 
> > 	C C-PaulEMcKenney-W+RWC4+2017-10-05
> > 
> > 	{
> > 	}
> > 
> > 	P0(int *a, int *x)
> > 	{
> > 		WRITE_ONCE(*a, 1);
> > 		smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > 		WRITE_ONCE(*x, 1);
> > 	}
> > 
> > 	P1(int *x, int *y)
> > 	{
> > 		r3 = READ_ONCE(*x);
> > 		smp_mb(); /* Lock acquisition for rcu_node ->lock. */
> > 		smp_store_release(y, 1);
> > 	}
> > 
> > 	P2(int *y, int *b)
> > 	{
> > 		r4 = smp_load_acquire(y);
> > 		r1 = READ_ONCE(*b);
> > 	}
> > 
> > 	P3(int *b, int *a)
> > 	{
> > 		WRITE_ONCE(*b, 1);
> > 		smp_mb();
> > 		r2 = READ_ONCE(*a);
> > 	}
> > 
> > 	exists (1:r3=1 /\ 2:r4=1 /\ 2:r1=0 /\ 3:r2=0)
> > 
> > 
> > Is what I was thinking of, I think that is the minimal ordering
> > complete()/wait_for_completion() need to provide.
> 
> OK, I will bite...  What do the smp_store_release() and the
> smp_load_acquire() correspond to?  I see just plain locking in
> wait_for_completion() and complete().

They reflect the concept of complete() / wait_for_completion().
Fundamentally all it needs to do is pass the message of 'completion'.

That is, if we were to go optimize our completion implementation, it
would be impossible to be weaker than this and still correct.

> So I dropped that patch yesterday.  The main thing I was missing was
> that there is no ordering-free fastpath in wait_for_completion() and
> complete(): Each unconditionally acquires the lock.  So the smp_mb()
> that I was trying to add doesn't need to be there.

Going by the above, it never needs to be there, even if there was a
lock-free fast-path.