linux-kernel - Re: wake_q memory ordering

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]

Message-ID: <0312fc72-74f1-ea3e-8301-f94bba742735@colorfullife.com>
Date:   Fri, 11 Oct 2019 10:57:35 +0200
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Davidlohr Bueso <dave@...olabs.net>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Waiman Long <longman@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        1vier1@....de, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: wake_q memory ordering

Hi Davidlohr,

On 10/10/19 9:25 PM, Davidlohr Bueso wrote:
> On Thu, 10 Oct 2019, Peter Zijlstra wrote:
>
>> On Thu, Oct 10, 2019 at 02:13:47PM +0200, Manfred Spraul wrote:
>>
>>> Therefore smp_mb__{before,after}_atomic() may be combined with
>>> cmpxchg_relaxed, to form a full memory barrier, on all archs.
>>
>> Just so.
>
> We might want something like this?
>
> ----8<---------------------------------------------------------
>
> From: Davidlohr Bueso <dave@...olabs.net>
> Subject: [PATCH] Documentation/memory-barriers.txt: Mention 
> smp_mb__{before,after}_atomic() and CAS
>
> Explicitly mention possible usages to guarantee serialization even upon
> failed cmpxchg (or similar) calls along with 
> smp_mb__{before,after}_atomic().
>
> Signed-off-by: Davidlohr Bueso <dbueso@...e.de>
> ---
> Documentation/memory-barriers.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index 1adbb8a371c7..5d2873d4b442 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1890,6 +1890,18 @@ There are some more advanced barrier functions:
>      This makes sure that the death mark on the object is perceived to 
> be set
>      *before* the reference counter is decremented.
>
> +     Similarly, these barriers can be used to guarantee serialization 
> for atomic
> +     RMW calls on architectures which may not imply memory barriers 
> upon failure.
> +
> +    obj->next = NULL;
> +    smp_mb__before_atomic()
> +    if (cmpxchg(&obj->ptr, NULL, val))
> +        return;
> +
> +     This makes sure that the store to the next pointer always has 
> smp_store_mb()
> +     semantics. As such, smp_mb__{before,after}_atomic() calls allow 
> optimizing
> +     the barrier usage by finer grained serialization.
> +
>      See Documentation/atomic_{t,bitops}.txt for more information.
>
>
I don't know. The new documentation would not have answered my question 
(is it ok to combine smp_mb__before_atomic() with atomic_relaxed()?). 
And it copies content already present in atomic_t.txt.

Thus: I would prefer if the first sentence of the paragraph is replaced: 
The list of operations should end with "...", and it should match what 
is in atomic_t.txt

Ok?

--

     Manfred



View attachment "0004-Documentation-memory-barriers.txt-Clarify-cmpxchg.patch" of type "text/x-patch" (2497 bytes)