linux-kernel - Re: [PATCH 2/2] tools/memory-model: Add write ordering by release-acquire and by locks

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: <b41849a8-76cd-2375-dd80-c1bdeb9ea7d2@nvidia.com>
Date:   Thu, 5 Jul 2018 08:44:39 -0700
From:   Daniel Lustig <dlustig@...dia.com>
To:     <paulmck@...ux.vnet.ibm.com>,
        Alan Stern <stern@...land.harvard.edu>
CC:     Will Deacon <will.deacon@....com>,
        Andrea Parri <andrea.parri@...rulasolutions.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>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] tools/memory-model: Add write ordering by
 release-acquire and by locks

On 7/5/2018 8:31 AM, Paul E. McKenney wrote:
> On Thu, Jul 05, 2018 at 10:21:36AM -0400, Alan Stern wrote:
>> At any rate, it looks like instead of strengthening the relation, I
>> should write a patch that removes it entirely.  I also will add new,
>> stronger relations for use with locking, essentially making spin_lock
>> and spin_unlock be RCsc.
> 
> Only in the presence of smp_mb__after_unlock_lock() or
> smp_mb__after_spinlock(), correct?  Or am I confused about RCsc?
> 
> 							Thanx, Paul
> 

In terms of naming...is what you're asking for really RCsc?  To me,
that would imply that even stores in the first critical section would
need to be ordered before loads in the second critical section.
Meaning that even x86 would need an mfence in either lock() or unlock()?

If you're only looking for R->R, R->W, and W->W ordering between
critical sections, is it better to find a new unique name for this?
"RCtso" possibly, or something to that effect?

Dan