linux-kernel - Re: Litmus test names

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: <20230408164956.GA680332@google.com>
Date:   Sat, 8 Apr 2023 16:49:56 +0000
From:   Joel Fernandes <joel@...lfernandes.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Jonas Oberhauser <jonas.oberhauser@...weicloud.com>,
        Alan Stern <stern@...land.harvard.edu>,
        linux-kernel@...r.kernel.org, Boqun Feng <boqun.feng@...il.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>,
        Akira Yokosawa <akiyks@...il.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Daniel Lustig <dlustig@...dia.com>,
        David Howells <dhowells@...hat.com>,
        Jonas Oberhauser <jonas.oberhauser@...wei.com>,
        linux-arch@...r.kernel.org, Nicholas Piggin <npiggin@...il.com>,
        Paul Heidekrüger <paul.heidekrueger@...tum.de>,
        Will Deacon <will@...nel.org>
Subject: Re: Litmus test names

On Fri, Apr 07, 2023 at 05:49:02PM -0700, Paul E. McKenney wrote:
> On Fri, Apr 07, 2023 at 03:05:01PM +0200, Jonas Oberhauser wrote:
> > 
> > 
> > On 4/7/2023 2:12 AM, Joel Fernandes wrote:
> > > 
> > > 
> > > > On Apr 6, 2023, at 6:34 PM, Paul E. McKenney <paulmck@...nel.org> wrote:
> > > > 
> > > > On Thu, Apr 06, 2023 at 05:36:13PM -0400, Alan Stern wrote:
> > > > > Paul:
> > > > > 
> > > > > I just saw that two of the files in
> > > > > tools/memory-model/litmus-tests have
> > > > > almost identical names:
> > > > > 
> > > > >  Z6.0+pooncelock+pooncelock+pombonce.litmus
> > > > >  Z6.0+pooncelock+poonceLock+pombonce.litmus
> > > > > 
> > > > > They differ only by a lower-case 'l' vs. a capital 'L'.  It's
> > > > > not at all
> > > > > easy to see, and won't play well in case-insensitive filesystems.
> > > > > 
> > > > > Should one of them be renamed?
> > > > 
> > > > Quite possibly!
> > > > 
> > > > The "L" denotes smp_mb__after_spinlock().  The only code difference
> > > > between these is that Z6.0+pooncelock+poonceLock+pombonce.litmus has
> > > > smp_mb__after_spinlock() and Z6.0+pooncelock+pooncelock+pombonce.litmus
> > > > does not.
> > > > 
> > > > Suggestions for a better name?  We could capitalize all the letters
> > > > in LOCK, I suppose...
> > 
> > I don't think capitalizing LOCK is helpful.
> 
> Greek font, then?  (Sorry, couldn't resist...)
> 
> > To be honest, almost all the names are extremely cryptic to newcomers like
> > me (like, what does Z6.0 mean? Is it some magic incantation?).
> > And that's not something that's easy to fix.
> 
> All too true on all counts.  Some of the names abbreviate the litmus
> test itself, and there are multiple encodings depending one who/what
> generated the test in question.  Others of the names relate to who came
> up with them or the code from which they are derived.
> 
> New allegedly universal naming schemes have a rather short half-life.
> 
> What would be cool would be a way to structurally compare litmus tests.
> I bet that there are quite a few duplicates, for example.
> 
> > The only use case I can think of for spending time improving the names is
> > that sometimes you wanna say something like "oh, this is like
> > Z6.0+pooncelock+pooncelockmb+pombonce". And then people can look up what
> > that is.
> > For that, it's important that the names are easy to disambiguate by humans,
> > and I think Joel's suggestion is an improvement.
> > (and it also fixes the issue brought up by Alan about case-insensitive file
> > systems)
> > 
> > > 
> > > Z6.0+pooncelock+pooncelockmb+pombonce.litmus ?
> 
> I am OK with this one, but then again, I was also OK with the original
> Z6.0+pooncelock+poonceLock+pombonce.litmus.  ;-)

FWIW, if I move that smp_mb_after..() a step lower, that also makes the test
work (see below).

If you may look over quickly my analysis of why this smp_mb_after..() is
needed, it is because what I marked as a and d below don't have an hb
relation right?

(*
  b ->rf c

  d ->co e

  e ->hb f

  basically the issue is a ->po b ->rf c ->po d    does not imply a ->hb d
*)

P0(int *x, int *y, spinlock_t *mylock)
{
	spin_lock(mylock);
	WRITE_ONCE(*x, 1); // a
	WRITE_ONCE(*y, 1); // b
	spin_unlock(mylock);
}

P1(int *y, int *z, spinlock_t *mylock)
{
	int r0;

	spin_lock(mylock);
	r0 = READ_ONCE(*y); // c
	smp_mb__after_spinlock(); // moving this a bit lower also works fwiw.
	WRITE_ONCE(*z, 1);  // d
	spin_unlock(mylock);
}

P2(int *x, int *z)
{
	int r1;

	WRITE_ONCE(*z, 2);  // e
	smp_mb();
	r1 = READ_ONCE(*x); // f
}

exists (1:r0=1 /\ z=2 /\ 2:r1=0)


> Would someone like to to a "git mv" send the resulting patch?

Yes I can do that in return as I am thankful in advance for the above
discussion. ;)

thanks,

 - Joel