All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Manfred Spraul <manfred@colorfullife.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	1vier1@web.de, Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH 6/6] Documentation/memory-barriers.txt: Clarify cmpxchg()
Date: Tue, 15 Oct 2019 16:31:04 -0400	[thread overview]
Message-ID: <c46f8cfa-056a-059c-a193-376a0d710699@redhat.com> (raw)
In-Reply-To: <ef45c2ca-942a-df83-22cf-690eaf761fb7@colorfullife.com>

On 10/14/19 1:49 PM, Manfred Spraul wrote:
> Hello Peter,
>
> On 10/14/19 3:03 PM, Peter Zijlstra wrote:
>> On Sat, Oct 12, 2019 at 07:49:58AM +0200, Manfred Spraul wrote:
>>> The documentation in memory-barriers.txt claims that
>>> smp_mb__{before,after}_atomic() are for atomic ops that do not return a
>>> value.
>>>
>>> This is misleading and doesn't match the example in atomic_t.txt,
>>> and e.g. smp_mb__before_atomic() may and is used together with
>>> cmpxchg_relaxed() in the wake_q code.
>>>
>>> The purpose of e.g. smp_mb__before_atomic() is to "upgrade" a following
>>> RMW atomic operation to a full memory barrier.
>>> The return code of the atomic operation has no impact, so all of the
>>> following examples are valid:
>> The value return of atomic ops is relevant in so far that
>> (traditionally) all value returning atomic ops already implied full
>> barriers. That of course changed when we added
>> _release/_acquire/_relaxed variants.
> I've updated the Change description accordingly
>>> 1)
>>>     smp_mb__before_atomic();
>>>     atomic_add();
>>>
>>> 2)
>>>     smp_mb__before_atomic();
>>>     atomic_xchg_relaxed();
>>>
>>> 3)
>>>     smp_mb__before_atomic();
>>>     atomic_fetch_add_relaxed();
>>>
>>> Invalid would be:
>>>     smp_mb__before_atomic();
>>>     atomic_set();
>>>
>>> Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
>>> Cc: Waiman Long <longman@redhat.com>
>>> Cc: Davidlohr Bueso <dave@stgolabs.net>
>>> Cc: Peter Zijlstra <peterz@infradead.org>
>>> ---
>>>   Documentation/memory-barriers.txt | 11 ++++++-----
>>>   1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/memory-barriers.txt
>>> b/Documentation/memory-barriers.txt
>>> index 1adbb8a371c7..52076b057400 100644
>>> --- a/Documentation/memory-barriers.txt
>>> +++ b/Documentation/memory-barriers.txt
>>> @@ -1873,12 +1873,13 @@ There are some more advanced barrier functions:
>>>    (*) smp_mb__before_atomic();
>>>    (*) smp_mb__after_atomic();
>>>   -     These are for use with atomic (such as add, subtract,
>>> increment and
>>> -     decrement) functions that don't return a value, especially
>>> when used for
>>> -     reference counting.  These functions do not imply memory
>>> barriers.
>>> +     These are for use with atomic RMW functions (such as add,
>>> subtract,
>>> +     increment, decrement, failed conditional operations, ...) that do
>>> +     not imply memory barriers, but where the code needs a memory
>>> barrier,
>>> +     for example when used for reference counting.
>>>   -     These are also used for atomic bitop functions that do not
>>> return a
>>> -     value (such as set_bit and clear_bit).
>>> +     These are also used for atomic RMW bitop functions that do
>>> imply a full
>> s/do/do not/ ?
> Sorry, yes, of course

I was wondering the same thing. With the revised patch,

Acked-by: Waiman Long <longman@redhat.com>

>>> +     memory barrier (such as set_bit and clear_bit).
>
>


  parent reply	other threads:[~2019-10-15 20:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-12  5:49 [PATCH 0/6] V2: Clarify/standardize memory barriers for ipc Manfred Spraul
2019-10-12  5:49 ` [PATCH 1/6] wake_q: Cleanup + Documentation update Manfred Spraul
2019-10-14  6:34   ` Davidlohr Bueso
2019-10-14 12:04   ` Peter Zijlstra
2019-10-12  5:49 ` [PATCH 2/6] ipc/mqueue.c: Remove duplicated code Manfred Spraul
2019-10-14  6:35   ` Davidlohr Bueso
2019-10-14 12:37   ` Peter Zijlstra
2019-10-12  5:49 ` [PATCH 3/6] ipc/mqueue.c: Update/document memory barriers Manfred Spraul
2019-10-14  6:38   ` Davidlohr Bueso
2019-10-14 12:59   ` Peter Zijlstra
2019-10-14 13:58     ` Peter Zijlstra
2019-10-14 18:06       ` Manfred Spraul
2019-10-12  5:49 ` [PATCH 4/6] ipc/msg.c: Update and document " Manfred Spraul
2019-10-12  5:49 ` [PATCH 5/6] ipc/sem.c: Document and update " Manfred Spraul
2019-10-12  5:49 ` [PATCH 6/6] Documentation/memory-barriers.txt: Clarify cmpxchg() Manfred Spraul
2019-10-14 13:03   ` Peter Zijlstra
2019-10-14 17:49     ` Manfred Spraul
2019-10-14 19:03       ` Davidlohr Bueso
2019-10-15  7:45       ` Peter Zijlstra
2019-10-15 20:31       ` Waiman Long [this message]
2019-10-15  1:26   ` Davidlohr Bueso
2019-10-15  7:19     ` Peter Zijlstra
2019-10-15 16:26       ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c46f8cfa-056a-059c-a193-376a0d710699@redhat.com \
    --to=longman@redhat.com \
    --cc=1vier1@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.