linux-kernel - Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

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: <20170803165816.GY3730@linux.vnet.ibm.com>
Date:   Thu, 3 Aug 2017 09:58:16 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Will Deacon <will.deacon@....com>
Cc:     Boqun Feng <boqun.feng@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

On Thu, Aug 03, 2017 at 05:12:24PM +0100, Will Deacon wrote:
> On Thu, Aug 03, 2017 at 07:55:14AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 03, 2017 at 10:05:16PM +0800, Boqun Feng wrote:
> > > Hi Will,
> > > 
> > > On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote:
> > > [...]
> > > > 
> > > > It's worth noting that we don't have the problem with any value-returning
> > > > atomics, so all flavours of xchg in this test would be forbidden on arm64
> > > > too.
> > > > 
> > > > > 	C C-WillDeacon-MP+o-r+ai-rmb-o.litmus
> > > > > 
> > > > > 	(*
> > > > > 	 * Expected result: Never.
> > > > > 	 *
> > > > > 	 * Desired litmus test, with atomic_inc() emulated by xchg_relaxed():
> > > > > 	 *
> > > > > 	 *     WRITE_ONCE(x, 1);               atomic_inc(&y);
> > > > > 	 *     r0 = xchg_release(&y, 5);       smp_rmb();
> > > > > 	 *                                     r1 = READ_ONCE(x);
> > > > > 	 *
> > > > > 	 *
> > > > > 	 *     WARN_ON(r0 == 0 && r1 == 0);
> > > > > 	 *)
> > > > > 
> > > > > 	{
> > > > > 	}
> > > > > 
> > > > > 	P0(int *x, int *y)
> > > > > 	{
> > > > > 		WRITE_ONCE(*x, 1);
> > > > > 		r0 = xchg_release(y, 5);
> > > > > 	}
> > > > > 
> > > > > 	P1(int *x, int *y)
> > > > > 	{
> > > > > 		r2 = xchg_relaxed(y, 1);
> > > > > 		smp_rmb();
> > > > > 		r1 = READ_ONCE(*x);
> > > > > 	}
> > > > > 
> > > > > 	exists
> > > > > 	(0:r0=0 /\ 1:r1=0)
> > > > > 
> > > 
> > > How about a litmus test like this?
> > > 
> > >  	C C-AMO-global-transitivity.litmus
> > >  
> > >  	{
> > >  	}
> > >  
> > >  	P0(int *x, int *y)
> > >  	{
> > >  		WRITE_ONCE(*x, 1);
> > >  		r0 = xchg_release(y, 5);
> > >  	}
> > >  
> > >  	P1(int *y, int *z)
> > >  	{
> > >  		atomic_inc(y);
> > >  		smp_mb();
> > 
> > I am going to guess that the smp_mb() enforces the needed ordering,
> > but Will will let me know.  ;-)
> 
> Yup, that would be forbidden on arm64, and would also be forbidden if
> you used WRITE_ONCE instead of atomic_inc (remember that we recently
> became multi-copy atomic).

Thank you for the confirmation!

							Thanx, Paul