svn commit: r251782 - head/sys/sparc64/sparc64

[Marius Strobl]

On Sat, Jun 15, 2013 at 08:21:54AM +0000, Ed Schouten wrote:
> Author: ed
> Date: Sat Jun 15 08:21:54 2013
> New Revision: 251782
> URL: http://svnweb.freebsd.org/changeset/base/251782
> 
> Log:
>   Stick to using the documented atomic(9) API.
>   
>   The atomic_store_ptr() function is not part of the atomic(9) API. We
>   only provide a version with a release barrier.
> 
> Modified:
>   head/sys/sparc64/sparc64/pmap.c
> 
> Modified: head/sys/sparc64/sparc64/pmap.c
> ==============================================================================
> --- head/sys/sparc64/sparc64/pmap.c	Sat Jun 15 08:15:22 2013	(r251781)
> +++ head/sys/sparc64/sparc64/pmap.c	Sat Jun 15 08:21:54 2013	(r251782)
> @@ -2246,7 +2246,7 @@ pmap_activate(struct thread *td)
>  	pm->pm_context[curcpu] = context;
>  #ifdef SMP
>  	CPU_SET_ATOMIC(PCPU_GET(cpuid), &pm->pm_active);
> -	atomic_store_ptr((uintptr_t *)PCPU_PTR(pmap), (uintptr_t)pm);
> +	atomic_store_rel_ptr((uintptr_t *)PCPU_PTR(pmap), (uintptr_t)pm);
>  #else
>  	CPU_SET(PCPU_GET(cpuid), &pm->pm_active);
>  	PCPU_SET(pmap, pm);

Semantically, this change is wrong; what we really need here is an
acquire variant. Using the release variant instead happens to also
work - albeit additionally wastes CPU cycles for the write memory
barrier - because in total store order, atomic operations implicitly
include the read memory barrier necessary for acquire semantics. In
other words, atomic(9) is in dare need of atomic_store_acq_<type>().

Marius