All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Will Deacon <will@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Waiman Long <longman@redhat.com>,
	1vier1@web.de, Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 1/5] smp_mb__{before,after}_atomic(): Update Documentation
Date: Wed, 6 Nov 2019 20:23:03 +0100	[thread overview]
Message-ID: <65a187c2-80de-2c6f-5f80-48c51f973d08@colorfullife.com> (raw)
In-Reply-To: <20191101164948.GD3603@willie-the-truck>

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

Hi Will,

On 11/1/19 5:49 PM, Will Deacon wrote:
> Hi Manfred,
>
> On Sun, Oct 20, 2019 at 02:33:01PM +0200, Manfred Spraul wrote:
>> When adding the _{acquire|release|relaxed}() variants of some atomic
>> operations, it was forgotten to update Documentation/memory_barrier.txt:
>>
>> smp_mb__{before,after}_atomic() is now intended for all RMW operations
>> that do not imply a memory barrier.
> [...]
>
> Although I think this is correct, I really think we should instead refer to
> Documentation/atomic_t.txt and get rid of this out of memory-barriers.txt
> entirely. It's just duplication and is out of date.

So you would prefer the attached patch?

For me this would be fine, too.


--

     Manfred


[-- Attachment #2: 0001-smp_mb__-before-after-_atomic-Update-Documentation.patch --]
[-- Type: text/x-patch, Size: 2346 bytes --]

From 8d2b219794221e3ef1a1ec90e0f4fe344af9a55d Mon Sep 17 00:00:00 2001
From: Manfred Spraul <manfred@colorfullife.com>
Date: Fri, 11 Oct 2019 10:33:26 +0200
Subject: [PATCH 1/5] smp_mb__{before,after}_atomic(): Update Documentation

When adding the _{acquire|release|relaxed}() variants of some atomic
operations, it was forgotten to update Documentation/memory_barrier.txt:

smp_mb__before_atomic and smp_mb__after_atomic can be combined with
all RMW operations that do not imply memory barriers.

In order to avoid that this happens again:
Remove the paragraph from Documentation/memory_barrier.txt, the functions
are sufficiently documented in Documentation/atomic_{t,bitops}.txt

Fixes: 654672d4ba1a ("locking/atomics: Add _{acquire|release|relaxed}() variants of some atomic operations")

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>
---
 Documentation/memory-barriers.txt | 20 +-------------------
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1adbb8a371c7..16dfb4cde1e1 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1873,25 +1873,7 @@ 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 also used for atomic bitop functions that do not return a
-     value (such as set_bit and clear_bit).
-
-     As an example, consider a piece of code that marks an object as being dead
-     and then decrements the object's reference count:
-
-	obj->dead = 1;
-	smp_mb__before_atomic();
-	atomic_dec(&obj->ref_count);
-
-     This makes sure that the death mark on the object is perceived to be set
-     *before* the reference counter is decremented.
-
-     See Documentation/atomic_{t,bitops}.txt for more information.
-
+     See Documentation/atomic_{t,bitops}.txt for information.
 
  (*) dma_wmb();
  (*) dma_rmb();
-- 
2.23.0


  reply	other threads:[~2019-11-06 19:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-20 12:33 [PATCH 0/5] V3: Clarify/standardize memory barriers for ipc Manfred Spraul
2019-10-20 12:33 ` [PATCH 1/5] smp_mb__{before,after}_atomic(): Update Documentation Manfred Spraul
2019-11-01 16:49   ` Will Deacon
2019-11-06 19:23     ` Manfred Spraul [this message]
2019-11-07 11:22       ` Will Deacon
2019-10-20 12:33 ` [PATCH 2/5] ipc/mqueue.c: Remove duplicated code Manfred Spraul
2019-10-22 22:43   ` Andrew Morton
2019-10-20 12:33 ` [PATCH 3/5] ipc/mqueue.c: Update/document memory barriers Manfred Spraul
2019-10-20 12:33 ` [PATCH 4/5] ipc/msg.c: Update and document " Manfred Spraul
2019-10-20 12:33 ` [PATCH 5/5] ipc/sem.c: Document and update " Manfred Spraul

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=65a187c2-80de-2c6f-5f80-48c51f973d08@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=1vier1@web.de \
    --cc=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will.deacon@arm.com \
    --cc=will@kernel.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.