From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B5C8C433DB for ; Thu, 28 Jan 2021 15:06:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 21FEB64DFA for ; Thu, 28 Jan 2021 15:06:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232277AbhA1PGO (ORCPT ); Thu, 28 Jan 2021 10:06:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232425AbhA1PFE (ORCPT ); Thu, 28 Jan 2021 10:05:04 -0500 Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:8b0:10b:1231::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60816C061573; Thu, 28 Jan 2021 07:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=7yfcW39MtfJaiXZmnoAPjncfhf53DYwxvJyT9fBnDYM=; b=2Em3igleeT54NYBZl4CeE7uOzz Nh1wAmPWL+Hu81DHl2mLRb+Qx2NIocJ0DFIITJmvJAUQrXrPlOGKxaNfWgh0JlVEf1G00FNVZDwam f+98RKYRU/gPDw69vlS34mCV9BPzpPfKwfSL5wXq2vUMkxwKP+u1NxbEP3HQ004Kx3iUelv4ze7BK iRk67oz91z5U4FMInA/69CSQqcI5BTo4a8fnt1IGkOXDEpsJu/qLLno+4ZwTr5DFcNDs/cgTTtjBY 5NGQS1mwnIszzBMBEH8Ob0cNQcUk8BQ6VvtEqCb6+JUhhgXoUK1CFJzv4cI9ws4zXzvJFsFw8UQiR U1Xww8Og==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1l58qf-0002ax-4P; Thu, 28 Jan 2021 15:04:41 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C65323059C6; Thu, 28 Jan 2021 16:04:39 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id B7400213FC4B8; Thu, 28 Jan 2021 16:04:39 +0100 (CET) Date: Thu, 28 Jan 2021 16:04:39 +0100 From: Peter Zijlstra To: Alexander Sverdlin Cc: Paul Burton , linux-mips@vger.kernel.org, Thomas Bogendoerfer , Will Deacon , Boqun Feng , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] MIPS: Octeon: Implement __smp_store_release() Message-ID: References: <20210127203627.47510-1-alexander.sverdlin@nokia.com> <20210127203627.47510-2-alexander.sverdlin@nokia.com> <3c0165d9-1814-df1d-7ec9-bf515a3996b3@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c0165d9-1814-df1d-7ec9-bf515a3996b3@nokia.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 28, 2021 at 01:09:39PM +0100, Alexander Sverdlin wrote: > On 28/01/2021 12:33, Peter Zijlstra wrote: > > On Thu, Jan 28, 2021 at 08:27:29AM +0100, Alexander Sverdlin wrote: > > > >>>> +#define __smp_store_release(p, v) \ > >>>> +do { \ > >>>> + compiletime_assert_atomic_type(*p); \ > >>>> + __smp_wmb(); \ > >>>> + __smp_rmb(); \ > >>>> + WRITE_ONCE(*p, v); \ > >>>> +} while (0) > I actually hoped you will remember the discussion you've participated 5 years > ago and (in my understanding) actually already agreed that the solution itself > is not broken: > > https://lore.kernel.org/lkml/20151112180003.GE17308@twins.programming.kicks-ass.net/ My memory really isn't that good. I can barely remember what I did 5 weeks ago, 5 years ago might as well have never happened. > Could you please just suggest the proper comment you expect to be added here, > because there is no doubts, you have much more experience here than me? So for store_release I'm not too worried, and provided no read speculation, wmb is indeed sufficient. This is because our store_release is RCpc. Something like: /* * Because Octeon does not do read speculation, an smp_wmb() * is sufficient to ensure {load,store}->{store} order. */ #define __smp_store_release(p, v) \ do { \ compiletime_assert_atomic_type(*p); \ __smp_wmb(); \ WRITE_ONCE(*p, v); \ } while (0)