Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1605380rwb; Mon, 7 Nov 2022 03:46:13 -0800 (PST) X-Google-Smtp-Source: AMsMyM6I/8FahfSFEsESCxyM3ClPv0tpMGGHbWazg1ZOGWzEQohueq3Il+QnOa+s5sDn6mGRXAF1 X-Received: by 2002:a05:6402:371b:b0:460:ff7d:f511 with SMTP id ek27-20020a056402371b00b00460ff7df511mr50530070edb.148.1667821573606; Mon, 07 Nov 2022 03:46:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667821573; cv=none; d=google.com; s=arc-20160816; b=JQQCAKqjI6oPO53yP/C/wwVojK0hQ/i3ME7XVJ1o97R0XZ+dGJjYaRjBf86eWrhjPx CNXG8HWzJJbXxBnc3bHolVv/WIWWJrBNCA5lmqsmNdHRm3+HuTmNJLjJPUHSEt/ndKi/ l6P9EgupqD2dLZPogTMFWN9s/Yi1kNbz9k2unnXTY9heSvTazefz7YAL3efTZHnC85n/ X1uByRpxcNqu9yEUvyo6opiuNTx0MVYlF9neOemAetgAp+DEz6mzMus/4uY3lQjQVsVX 7EOhVW1cdyV4s7UsaGBaAfRpfmVL02j/uJU3m6i12gd8+5CIG/WFWMWWgn3BQpSA6ya5 lsGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xCU29vHImLcpE7TGT0sMFLsvoLj4JsHgzfi5nO1VWmo=; b=Xh176g3+cIq78OYEr8ABpPoJcwCd/YM+0cExxmod3rfmmhh5kf6qiMzsCFzdv1nURP zyJOPncHoRzbzIPPP8ViysaLw9j6SSRnCfG4Wb1BSF9emC4Mh/CcmA2s4l1FvOxrQ1Oo BbU184H+UlgbN+gFVdBv5FmFY1mhHBg8oTC5GtPk15CYsJqS7XVR0hc9Yt5vT+1Z/jM1 OZWEAj+uUwzN/nMOERQ/VOY8gYrlhxLMC+St0lgol4LnpTdkxxc2PElTokMRZbc7t3rT yJgV2suODq5LEHlxgr+OnUAjoPHzGJD07GyGuQ4ZJwE4jLDT5X6iEy9WNUMhb1mgkeOK 34zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xc2-20020a170907074200b0073ce34d1a13si9060841ejb.499.2022.11.07.03.45.51; Mon, 07 Nov 2022 03:46:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231528AbiKGKhY (ORCPT + 93 others); Mon, 7 Nov 2022 05:37:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231590AbiKGKhV (ORCPT ); Mon, 7 Nov 2022 05:37:21 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4036A13F8C for ; Mon, 7 Nov 2022 02:37:15 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 005E523A; Mon, 7 Nov 2022 02:37:21 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.69.132]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 970723F534; Mon, 7 Nov 2022 02:37:13 -0800 (PST) Date: Mon, 7 Nov 2022 10:37:10 +0000 From: Mark Rutland To: Thorsten Glaser Cc: linux-kernel@vger.kernel.org, ardb@kernel.org, arnd@arndb.de, boqun.feng@gmail.com, peterz@infradead.org, will@kernel.org Subject: Re: [PATCH v2] atomics: fix atomic64_{read_acquire,set_release} fallbacks Message-ID: References: <20220203161243.3955547-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 05, 2022 at 12:05:30AM +0100, Thorsten Glaser wrote: > On Thu, 3 Feb 2022, Mark Rutland wrote: > > > - smp_store_release(&(v)->counter, i); > > + if (__native_word(atomic_t)) { > > + smp_store_release(&(v)->counter, i); > > + } else { > > + __atomic_release_fence(); > > + arch_atomic_set(v, i); > > + } > > Shouldn’t this also update Documentation/atomic_t.txt which > currently states: > > | The non-RMW ops are (typically) regular LOADs and STOREs and are canonically > | implemented using READ_ONCE(), WRITE_ONCE(), smp_load_acquire() and > | smp_store_release() respectively. Therefore, if you find yourself only using > | the Non-RMW operations of atomic_t, you do not in fact need atomic_t at all > | and are doing it wrong. > > With this, direct use of atomic64_set_release() and atomic64_read_acquire() > is (IIUC) not “doing it wrong” any more? Direct use was never "wrong" if you were doing anything other than atomic64_set_release() and atomic64_read_acquire(), and I suspect we don't want to see those abused as a way to get a 64-bit smp_store_release() or smp_load_acquire() since those won't necessarily do the right thing w.r.t. a plain READ_ONCE() and so on. So I think this is still correct as-is. Do you have a particular case in mind that you care about? Thanks, Mark.