linux-kernel - Re: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin

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: <CA+55aFwu5jat5vV-d6RVaUFo=Bjeyv-7eXWUJySg6xFUTnfbWQ@mail.gmail.com>
Date:   Mon, 26 Feb 2018 08:06:59 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Luc Maranget <luc.maranget@...ia.fr>
Cc:     Daniel Lustig <dlustig@...dia.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...ive.com>,
        Albert Ou <albert@...ive.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Will Deacon <will.deacon@....com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Akira Yokosawa <akiyks@...il.com>,
        Ingo Molnar <mingo@...nel.org>, linux-riscv@...ts.infradead.org
Subject: Re: [RFC PATCH] riscv/locking: Strengthen spin_lock() and spin_unlock()

On Mon, Feb 26, 2018 at 6:21 AM, Luc Maranget <luc.maranget@...ia.fr> wrote:
>
> That is, locks are not implemented from more basic primitive but are specified.
> The specification can be described as behaving that way:
>   - A lock behaves as a read-modify-write. the read behaving as a read-acquire

This is wrong, or perhaps just misleading.

The *whole* r-m-w acts as an acquire. Not just the read part. The
write is very much part of it.

Maybe that's what you meant, but it read to me as "just the read part
of the rmw behaves as a read-acquire".

Because it is very important that the _write_ part of the rmw is also
ordered wrt everything that is inside the spinlock.

So doing a spinlock as

 (a) read-locked-acquire
   modify
 (c) write-conditional

would be wrong, because the accesses inside the spinlock are ordered
not just wrt the read-acquire, they have to be ordered wrt the write
too.

So it is closer to say that it's the _write_ of the r-m-w sequence
that has the acquire semantics, not the read.

>   - A unlock behaves as a store release.

Yes.

                  Linus