linux-kernel - sparc64 cmpxchg is not a full memory barrier anymore ?

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-next>] [day] [month] [year] [list]

Message-ID: <20091022183242.GA19307@Krystal>
Date:	Thu, 22 Oct 2009 14:32:42 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"David S. Miller" <davem@...emloft.net>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: sparc64 cmpxchg is not a full memory barrier anymore ?

Hi David,

I took a look at the current sparc64 cmpxchg implementation in the Linux
kernel and stumbled on this commit:

commit 293666b7a17cb7a389fc274980439212386a19c4
Author: David S. Miller <davem@...emloft.net>
Date:   Sat Nov 15 13:33:25 2008 -0800

    sparc64: Stop using memory barriers for atomics and locks.

    The kernel always executes in the TSO memory model now,
    so none of this stuff is necessary any more.

    With helpful feedback from Nick Piggin.

    Signed-off-by: David S. Miller <davem@...emloft.net>

Reading p. 152 A.9 Compare and Swap, I see that the cas instruction does
not imply a memory barrier.

Reading http://docs.sun.com/app/docs/doc/801-6678/6i11oelck?a=view

I see that:

"TSO guarantees that the store, FLUSH, and atomic load-store
instructions of all processors appear to be executed by memory serially
in a single order called the memory order. Furthermore, the sequence of
store, FLUSH, and atomic load-store instructions in the memory order for
a given processor is identical to the sequence in which they were issued
by the processor."

So it provides no guarantee whatsoever wrt loads. However, reading
Documentation/memory-barriers.txt:

"Whilst they are technically interprocessor interaction considerations,
atomic operations are noted specially as some of them imply full memory
barriers and some don't, but they're very heavily relied on as a group
throughout the kernel." -> cmpxchg is part of them.

The same applies to the other atomic instructions we find in this list.
How is the correct ordering of loads wrt to cmxchg (and other atomic
ops) still ensured by this modification?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/