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: <20170609111305.bn4ca4uscbp6pgxn@hirez.programming.kicks-ass.net>
Date:   Fri, 9 Jun 2017 13:13:05 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Will Deacon <will.deacon@....com>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@...il.com>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>, vgupta@...opsys.com,
        rkuo@...eaurora.org, james.hogan@...tec.com, jejb@...isc-linux.org,
        davem@...emloft.net, cmetcalf@...lanox.com
Subject: Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'
 architectures

On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:

> The spinlock based atomics should be SC, that is, none of them appear to
> place extra barriers in atomic_cmpxchg() or any of the other SC atomic
> primitives and therefore seem to rely on their spinlock implementation
> being SC (I did not fully validate all that).

So I did see that ARC and PARISC have 'superfluous' smp_mb() calls
around their spinlock implementation.

That is, for spinlock semantics you only need one _after_ lock and one
_before_ unlock. But the atomic stuff relies on being SC and thus would
need one before and after both lock and unlock.

Now, afaict PARISC doesn't even have memory barriers (it uses
asm-generic/barrier.h) so that's a bit of a puzzle.

But ARC could probably optimize (if they still care about that hardware)
by pulling out those barriers and putting it in the atomic
implementation.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ