Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4094681iob; Tue, 17 May 2022 13:55:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1Ru2elsrvsfygjxqOyGWhiCEzauyrAQX9HnL+k5VNYIckGF4oyA9GKNy5eBhz0NHgc5fO X-Received: by 2002:a17:907:a412:b0:6f4:31e5:5ce with SMTP id sg18-20020a170907a41200b006f431e505cemr21979491ejc.237.1652820934737; Tue, 17 May 2022 13:55:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652820934; cv=none; d=google.com; s=arc-20160816; b=ckGRBeijhjPscUzmk2ll5TBMfinfZxIJ3HoJexlteapA4YaN6N7ETos+2cC3Ac5mwf OtnHnY4ukZJT5mqFqC1/SaHCKMz1HTiQhMWPy4DuxGOB5Fe/ikAlhGL2PKH8sUkBukYF 7omHqu9upWHS9sjsNsQjoM+a/HYYTrQzuOWl67Pec3vTDT+m4u/AgVNYluDzJ6LZSV5O fukcMWSau+Ewhb6mADPvxGsktnixMn0KJ+qwAVj9Qg823qCqQcNhkIyMHWJqk9ptJzmH C3yAPKl9ydzBgTQt3VPq6TwFRUEZasETejVt5ysjxxDAmtO3QqES1IWSXsBSvKrjwkkN MMCw== 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-disposition:mime-version :references:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=F4l5jKZ8om+UJ2bnnny8US3atCJkXvdO1ZweF9XShQ4=; b=lEFjH0xgTexQDsolBKvRgk/9Pl0n2wAdsjvYIec0x4ZU2FKwWVeJCGCNvraf8RhEWb bOtvTIXoQiPzHFHs4DlXpq1RFyhFxvygboRRNxjf+LYP+WB3lR7BNqrkBVzjq9o/kmov iQdg0dez/OWP1/jWy+PWtNzKeAHOC9EK8l6YMItRMLCPomyQoz4LNU1UZl+QiJOS5JkL +ACvLfb7hxx5/mxwJTykAllxnMdA4Nm8baS9qqp6FCA76zHvH07Gfqoj0LWC0xwGd7sE mxIP8krZsLJRKnFZK9Pnk+hdHd8mhBCO+l/9WSCFFREzbTCbsvNn+bKfaYXBohdyRrTu h9xQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ts4NTFOo; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gt32-20020a1709072da000b006f3a3b15ad6si289012ejc.354.2022.05.17.13.55.09; Tue, 17 May 2022 13:55:34 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Ts4NTFOo; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352927AbiEQU2f (ORCPT + 99 others); Tue, 17 May 2022 16:28:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234683AbiEQU2a (ORCPT ); Tue, 17 May 2022 16:28:30 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D122252B08; Tue, 17 May 2022 13:28:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5DCAF616E6; Tue, 17 May 2022 20:28:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AC815C385B8; Tue, 17 May 2022 20:28:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652819308; bh=ZWAkpabVz1HDAQwuEJZ+QuSTkMhXnE1CAPhGyAj51Ss=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=Ts4NTFOo/kHz9JMr2Fjsr2lkkw8k/l0758yDk0sN7oPbZqvEZqkjdvpmL8ZM9xmDp RG4O205n7i9ptfMGSg3yqzh8fUtf+5XuW6ciYND3iRM4lH009UCCw+kElJiQ9T1fW3 f0hUc5r7UrrHT3VIyMa1tWwR9CObW304HPy9cUzWkVqTpez7T4mln14Vg5XiBWIGGB c1FuhSDJH3itVCB6MoVbjv3/aSkAP0CEzRR24jeWxqvV5w6cZvzKz2YxyUTHQogIDW aXXRussQ3bhTTpS6zQGSd1zwLj/tIxap7U7nFX3ai5huB0dRlKmy+cNiam6Ijzd4d7 5X8Q688Oy+v+A== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 4C9335C086D; Tue, 17 May 2022 13:28:28 -0700 (PDT) Date: Tue, 17 May 2022 13:28:28 -0700 From: "Paul E. McKenney" To: Eric Dumazet Cc: Marco Elver , Liu Jian , Dmitry Vyukov , LKML , David Miller , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , Neal Cardwell , netdev Subject: Re: [PATCH net] tcp: Add READ_ONCE() to read tcp_orphan_count Message-ID: <20220517202828.GF1790663@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20220512103322.380405-1-liujian56@huawei.com> <20220512231031.GT1790663@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 Thu, May 12, 2022 at 04:43:20PM -0700, Eric Dumazet wrote: > On Thu, May 12, 2022 at 4:10 PM Paul E. McKenney wrote: > > > > On Thu, May 12, 2022 at 02:31:48PM -0700, Eric Dumazet wrote: > > > On Thu, May 12, 2022 at 2:18 PM Marco Elver wrote: > > > > > > > > > > > I guess the question is, is it the norm that per_cpu() retrieves data > > > > that can legally be modified concurrently, or not. If not, and in most > > > > cases it's a bug, the annotations should be here. > > > > > > > > Paul, was there any guidance/documentation on this, but I fail to find > > > > it right now? (access-marking.txt doesn't say much about per-CPU > > > > data.) > > > > > > Normally, whenever we add a READ_ONCE(), we are supposed to add a comment. > > > > I am starting to think that comments are even more necessary for unmarked > > accesses to shared variables, with the comments setting out why the > > compiler cannot mess things up. ;-) > > > > > We could make an exception for per_cpu_once(), because the comment > > > would be centralized > > > at per_cpu_once() definition. > > > > This makes a lot of sense to me. > > > > > We will be stuck with READ_ONCE() in places we are using > > > per_cpu_ptr(), for example > > > in dev_fetch_sw_netstats() > > > > If this is strictly statistics, data_race() is another possibility. > > But it does not constrain the compiler at all. > > Statistics are supposed to be monotonically increasing ;) > > Some SNMP agents would be very confused if they could observe 'garbage' there. > > I sense that we are going to add thousands of READ_ONCE() soon :/ Indeed, adding READ_ONCE() instances can be annoying. Then again, it can also be annoying to have to debug the problems that sometimes arise from omitting them where they are needed. Thanx, Paul