Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp989096ybx; Wed, 6 Nov 2019 11:24:42 -0800 (PST) X-Google-Smtp-Source: APXvYqxkrNNDLgUta2ObuhMzpDfddFu3RYtZAQGOt4Wnm7y6hC0Kb6/URWTlq9GUmHk+TH6QGNCt X-Received: by 2002:aa7:d54e:: with SMTP id u14mr4565491edr.49.1573068282306; Wed, 06 Nov 2019 11:24:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573068282; cv=none; d=google.com; s=arc-20160816; b=zgeglqtkCH+xJxDNcyYmZDxzJPoaQVx+uOBZhsYKMQJEyowHyXcu/ybTn6KRMR/qrL 1yDJgYMXTNmgRmTA250rgpR8iv3b4TQi3RTTgwbOYA2v7Y6vEC+A0s6x2b9ESmPVxRii zYwrLN7wr88goy9pj6N0lAF95UOGxe2sFuUw00LuryFiJYbCJPJcbNbklmcBeDLLNijs FH2dPzxfkLCaZ9FhyMAD07IQ1tmNTxMIoSvi4Ed+hNOP4/YoF5CN/bsAvhhBq9AtPezE b/GoQlbJ0zdaleOwvIGQ5qhXKciLyD/nM0dU5+IyeIrCdQl3jYOmnRxgo02V2asVKrcp KgGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :dkim-signature; bh=DY50EUrE+zr/6pmyQoV/OlDlyIr6dh7fVbpsOXhbzB8=; b=0dx/h3uw73ELkj6jCrwgoroM0H7y1njWzCaJekst8o0Aco8YXEc45OhvIbfmL7Qdc9 yywXvN+y9hfHOr6e93Gd/Y/ycv22TOewhydeSstr2xP6HsHICPBKGU164aM38zP7sMy7 6w5XAYZ/Ex4LwD7jLOjsm4ZBZIq+PZ9I/p+r/MtvdiWNBGLVVRIrixaiN6QjFcAo/eUq 8XIwMh+lGuN1nEWGHnZm5Z66sCTr7nt31bN0lFGVY59gtuC+5bKWHRFLUKLLmuqMCYnN nTsaDalwVJkkI0950hE6XsbmXOG43iWQ4wTo8F/5604LDDEvsOMMhW7HAj8JC6XcB6xa 5WMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@colorfullife-com.20150623.gappssmtp.com header.s=20150623 header.b=G7jIupr+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si14535813edf.93.2019.11.06.11.24.18; Wed, 06 Nov 2019 11:24:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@colorfullife-com.20150623.gappssmtp.com header.s=20150623 header.b=G7jIupr+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732637AbfKFTXN (ORCPT + 99 others); Wed, 6 Nov 2019 14:23:13 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:32806 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732612AbfKFTXL (ORCPT ); Wed, 6 Nov 2019 14:23:11 -0500 Received: by mail-wr1-f68.google.com with SMTP id w30so4706095wra.0 for ; Wed, 06 Nov 2019 11:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorfullife-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=DY50EUrE+zr/6pmyQoV/OlDlyIr6dh7fVbpsOXhbzB8=; b=G7jIupr+dTUdzgGZqcLx2YK09iqFHgOFUg3zuVjtfd8JLezsR+XcMT4lYxlB+a1NEr 45vMz6QChH9yep8dDz3U8tPQV4o3K05PkoNyUuEn+TeYC2+TyocG4IxmMEzCAeQ/2/z0 WAX3hSpuRQW78Uy4D73FI+GTb7/y9YThCpvUCc++oaGXDwBdACz9pIwHVmYWQi+lvlKr L1yOY2f1k3uEtObTLpkWq4u6WsaHKUrcmCk97RfUDw+ifl21l8SFdE58RsiAxCrocRfT E/UcctTDvQb7V97/ipBLPsrFaOaTnKUBSxSpKYdR1X2EuitEoDct/NGqEHCMd0v96lDW 3bMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DY50EUrE+zr/6pmyQoV/OlDlyIr6dh7fVbpsOXhbzB8=; b=mOQ3qyIbg/pWF9TinaRtiQANpl1kehsrQ9mvpz8U1BoB7jEI16FvDlr1VprZPPrSWC Ne5ZUcyYAAx6QA61FG6u0ce4dRaGRnbPpFrYZYsjSUXfCw2LloIDF1dY+Cvj7ryL420n C2/fA1ie7uT6vaYy2fKOzsmI8gTOTxjk+s2nmOlGd5JePIMtRsWf7eM/0q69p+r5Bte9 7Trw6GGNjeRM+wwaXrz94w3Ml+9B3psgTjKR//282u9OXlC6soe9eur2o6hO/1oAkUvv i5wrqFG/dBdgpgaAwvRyNe0p2bhEj/YofGExlvQYeziogeZc4HIQKrO15qep8BuZDvUA gWZA== X-Gm-Message-State: APjAAAVfUojn1HkAxmgYOHaFK4QElSb59MP6ka8NMn0gKcPARo1nYQYX PxQIRW9CAtymawK9vuDIdcayGg== X-Received: by 2002:adf:f447:: with SMTP id f7mr4085308wrp.210.1573068188018; Wed, 06 Nov 2019 11:23:08 -0800 (PST) Received: from linux.fritz.box (p200300D99704F800FD1B6A1FC9C62083.dip0.t-ipconnect.de. [2003:d9:9704:f800:fd1b:6a1f:c9c6:2083]) by smtp.googlemail.com with ESMTPSA id r3sm48303904wre.29.2019.11.06.11.23.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 11:23:06 -0800 (PST) Subject: Re: [PATCH 1/5] smp_mb__{before,after}_atomic(): Update Documentation To: Will Deacon Cc: LKML , Davidlohr Bueso , Waiman Long , 1vier1@web.de, Andrew Morton , Peter Zijlstra , Will Deacon References: <20191020123305.14715-1-manfred@colorfullife.com> <20191020123305.14715-2-manfred@colorfullife.com> <20191101164948.GD3603@willie-the-truck> From: Manfred Spraul Message-ID: <65a187c2-80de-2c6f-5f80-48c51f973d08@colorfullife.com> Date: Wed, 6 Nov 2019 20:23:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191101164948.GD3603@willie-the-truck> Content-Type: multipart/mixed; boundary="------------C0D35D7ED75CE9EAD8BE1EE7" Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------C0D35D7ED75CE9EAD8BE1EE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------C0D35D7ED75CE9EAD8BE1EE7 Content-Type: text/x-patch; charset=UTF-8; name="0001-smp_mb__-before-after-_atomic-Update-Documentation.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-smp_mb__-before-after-_atomic-Update-Documentation.patc"; filename*1="h" From 8d2b219794221e3ef1a1ec90e0f4fe344af9a55d Mon Sep 17 00:00:00 2001 From: Manfred Spraul 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 Acked-by: Waiman Long Cc: Davidlohr Bueso Cc: Peter Zijlstra Cc: Will Deacon --- 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 --------------C0D35D7ED75CE9EAD8BE1EE7--