linux-kernel - Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

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: <Pine.LNX.4.44L0.1807111010270.1436-100000@iolanthe.rowland.org>
Date:   Wed, 11 Jul 2018 10:19:45 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Andrea Parri <andrea.parri@...rulasolutions.com>
cc:     Daniel Lustig <dlustig@...dia.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Nicholas Piggin <npiggin@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will.deacon@....com>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and
 remove it for ordinary release/acquire

On Wed, 11 Jul 2018, Andrea Parri wrote:

> > > Does something like "po; [UL]; rf; [LKR]; po" fit in with the rest
> > > of the model?  If so, maybe that solves the asymmetry and also
> > > legalizes the approach of putting fence.tso in front?
> > 
> > That would work just as well.  For this version of the patch it 
> > doesn't make any difference, because nothing that comes po-after the 
> > LKR is able to directly read the value stored by the UL.
> 
> Consider:
> 
> C v2-versus-v3
> 
> {}
> 
> P0(spinlock_t *s, int *x)
> {
> 	spin_lock(s);   /* A */
> 	spin_unlock(s);
> 	spin_lock(s);
> 	WRITE_ONCE(*x, 1); /* B */
> 	spin_unlock(s);
> }
> 
> P1(spinlock_t *s, int *x)
> {
> 	int r0;
> 	int r1;
> 
> 	r0 = READ_ONCE(*x); /* C */
> 	smp_rmb();
> 	r1 = spin_is_locked(s); /* D */
> }
> 
> With v3, it's allowed that C reads from B and D reads from (the LKW of) A;
> this is not allowed with v2 (unless I mis-applied/mis-read v2).

Correct.  But it doesn't affect the end result, because both versions
allow C to read from B while D reads from the second spin_lock(), and
there's no way to distinguish that from the case where D reads from A.

If we were talking about arbitrary integers and rmw-acquire updates,
there _would_ be a difference.  But not with spinlocks.

Alan