linux-kernel - Sparc64 support added to Userspace RCU

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]

Date:	Thu, 22 Oct 2009 15:57:53 -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>,
	ltt-dev@...ts.casi.polymtl.ca, rp@...s.cs.pdx.edu
Subject: Sparc64 support added to Userspace RCU

By the way, I just added sparc64 support to the Userspace RCU library,
available at: git://lttng.org/userspace-rcu.git

Interesting files concerning sparc64 are:

urcu/arch_sparc64.h
urcu/uatomic_arch_sparc64.h

Direct links:
http://www.lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git;a=blob;f=urcu/arch_sparc64.h;hb=HEAD
http://www.lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git;a=blob;f=urcu/uatomic_arch_sparc64.h;hb=HEAD

Please note that this code targets user-space, not kernel-space.

Feedback is welcome,

Thanks,

Mathieu

* Mathieu Desnoyers (mathieu.desnoyers@...ymtl.ca) wrote:
> 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

-- 
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/