Re: [PATCHv2 06/11] atomics/treewide: rework ordering barriers

[Mark Rutland]

On Mon, Jun 25, 2018 at 11:59:47AM +0100, Mark Rutland wrote:
> Currently architectures can override __atomic_op_*() to define the barriers
> used before/after a relaxed atomic when used to build acquire/release/fence
> variants.
> 
> This has the unfortunate property of requiring the architecture to define the
> full wrapper for the atomics, rather than just the barriers they care about,
> and gets in the way of generating atomics which can be easily read.
> 
> Instead, this patch has architectures define an optional set of barriers,
> __atomic_mb_{before,after}_{acquire,release,fence}(), which <linux/atomic.h>
> uses to build the wrappers.
> 
> At the same time, let's avoid any potential reliance on these elsewhere
> by ensuring each is undef'd at the end of <linux/atomic.h>.

> +#undef __atomic_op_acquire
> +#undef __atomic_op_release
> +#undef __atomic_op_fence
> +
> +#undef __atomic_acquire_fence
> +#undef __atomic_release_fence
> +#undef __atomic_pre_fence
> +#undef __atomic_post_fence

Due to the way preprocessor gets expanded, this happens to break the
cmpxchg() wrappers on some architectures. Without re-implementing those
with some pretty horrendous static inlines and wrappers to guarantee
type invariance, it's not possible to solve that.

As agreed over IRC, I've removed the undefs for now.

Alas.

Mark.