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

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:   Mon, 25 Jun 2018 16:44:00 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     linux-kernel@...r.kernel.org, will.deacon@....com,
        peterz@...radead.org, boqun.feng@...il.com
Cc:     Andrea Parri <parri.andrea@...il.com>
Subject: Re: [PATCHv2 06/11] atomics/treewide: rework ordering barriers

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.