Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp933583iob; Fri, 13 May 2022 17:00:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVXpM2G+bOsZrUDGtKBe5K3jNeFOf34mJjR4chlgHrEo/eVHsNhdQqgK66rTvcb8j298wP X-Received: by 2002:a05:600c:35cc:b0:394:7e9e:bd1f with SMTP id r12-20020a05600c35cc00b003947e9ebd1fmr17457839wmq.95.1652486407252; Fri, 13 May 2022 17:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652486407; cv=none; d=google.com; s=arc-20160816; b=WD+cDCZ8eF3WACrzHklSe3e4V/9fHLGBI1yprbZ3PUJmiN8gcHOHNGF9nF06574i+f xHL8EwFzXokhVM9PWABLXKkUhqa54wFymTaEqGV9OJLez/jtHjqSynL+JnZLbn6DZnht vNjrJPHwfq19SwUwvzTr8ule+DN/i/GbuvrJC5WhOWHUhbScHJDRkKWly631fSnMcYMX +BpJCOFxmKmthfGUKaCsEg9SCoO3XllV7YhLXEPQ0+goyjKrpoyiV4VAqqch3C2JTYAz idVBysjjmwo5NwNCnFxoM/QfoM6d33NRbFDiDMqNNpE5UyIaSrXEJtv72DGFGSG1sCqD E7zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=qP8x7MUO3Uu37I6lovdAXd3voCCKfRiLq82HFRhMPMs=; b=Vyyv2jC6ZqxF9jUqCCdBxX9GVCN78B0mpy0xgOcbCX5ebT8IHCgCvdMeGxjescN9Z0 c31LPVqQzshiyDiDXe6eXbQhXg3NzIwszZN8NuIbVVvqTzo5u/PdghE+eo68NY+nDZgT ArKScT70TxZAzVgNHRM2qebCfB47fi1LnOKvjmrJ6fVR/8Ap24vObFp4Dypw3U3q5Gtn OQbDH4p/YEeTyS1rKDsge5OrEyivjA1O1tEcWMzGQ6p8s6+0+oWdArUPr21v6U9Ql1hu GtPseA6dgqx3s6XaNXFgzRUXeKVBMirlwaOqrQc+/qZKlOAwaURTxoIwmekb1TuHiUQS RgHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Kplc09E4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id c5-20020a056000184500b0020adebae0b2si4736170wri.696.2022.05.13.17.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 17:00:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Kplc09E4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8290A666AA; Fri, 13 May 2022 16:01:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358750AbiELVcH (ORCPT + 99 others); Thu, 12 May 2022 17:32:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358742AbiELVcC (ORCPT ); Thu, 12 May 2022 17:32:02 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 05D6F20F742 for ; Thu, 12 May 2022 14:32:01 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id g28so12095598ybj.10 for ; Thu, 12 May 2022 14:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qP8x7MUO3Uu37I6lovdAXd3voCCKfRiLq82HFRhMPMs=; b=Kplc09E4S/2dbuxcXjM62BKCcgoUDUa3W6vtuOLIK+pmB60FnSLrqgZFHHcXsrROHz 0ftSTKDMuLcwioiSk/jyrRtd3aYiH0CFysLg06dQS1x6v7XwC1QVBUmuYS4m/cCt2QGm Z99AeZbhMuOeU3i4+v3+ETnSyv8MdvnZWxck8Ig1RAl7SSfsFoOScsMPeaZm9pTUoW0M A0Qigywdfgl0/AlJEEPTKEUYjCWn8rjocrJo45QUFBdV0Vc6zxIbJiK4DMtVNxvEU0Xx m1TP3ZzWFpl9tlk5z3USjv8ThN7ozhK8XhpqTHZJqgPPtBHS6F7geiDW6SoUkNj+ooB4 KL1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qP8x7MUO3Uu37I6lovdAXd3voCCKfRiLq82HFRhMPMs=; b=oVNgfpGXRE3NDeLGMHPC8OFGV7KHzr92c8tHxYqDwLCJf5k1X7264uDjUQ9r3lC4ge QpqhM8zV5FKyHBZUZKGeMH2krkBBvMDbbPcgLLrQ5uEtfc5C+4qc0FN+5U/PNFeWSctP klSTIZhD2x4Gr5nWx7gfwtnY3YpaabOzlMS6RJfPz8XZ/1mECIuzL9JcDTJBUKMSMntV HbNdKZmxcyIWdjpCvvlS1EfZNFRVQGDiKo98zoL71zMTTclf9aSl70+Ap1eFuFAskyj7 3J+gLhccCu+AIbOZ68mkW1Pu2DsP5XcNM02NvIbtUQQ/VH87mi/WrTMo3yOlgR37HK33 tPxQ== X-Gm-Message-State: AOAM533ttfO7uM1cd7gTd+Ff1+jDfVYs2Z2oodq0osTB5E+HJT+AnvYq ASVhz/pe73cczGh7jQPctWQ2+QtDg+G1LdckQmjhJw== X-Received: by 2002:a05:6902:1007:b0:649:7745:d393 with SMTP id w7-20020a056902100700b006497745d393mr1846772ybt.407.1652391119968; Thu, 12 May 2022 14:31:59 -0700 (PDT) MIME-Version: 1.0 References: <20220512103322.380405-1-liujian56@huawei.com> In-Reply-To: From: Eric Dumazet Date: Thu, 12 May 2022 14:31:48 -0700 Message-ID: Subject: Re: [PATCH net] tcp: Add READ_ONCE() to read tcp_orphan_count To: Marco Elver Cc: "Paul E. McKenney" , Liu Jian , Dmitry Vyukov , LKML , David Miller , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , Neal Cardwell , netdev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no 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 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. We could make an exception for per_cpu_once(), because the comment would be centralized at per_cpu_once() definition. We will be stuck with READ_ONCE() in places we are using per_cpu_ptr(), for example in dev_fetch_sw_netstats() diff --git a/net/core/dev.c b/net/core/dev.c index 1461c2d9dec8099a9a2d43a704b4c6cb0375f480..b66470291d7b7e6c33161093d71e40587f9ed838 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -10381,10 +10381,13 @@ void dev_fetch_sw_netstats(struct rtnl_link_stats64 *s, stats = per_cpu_ptr(netstats, cpu); do { start = u64_stats_fetch_begin_irq(&stats->syncp); - tmp.rx_packets = stats->rx_packets; - tmp.rx_bytes = stats->rx_bytes; - tmp.tx_packets = stats->tx_packets; - tmp.tx_bytes = stats->tx_bytes; + /* These values can change under us. + * READ_ONCE() pair with too many write sides... + */ + tmp.rx_packets = READ_ONCE(stats->rx_packets); + tmp.rx_bytes = READ_ONCE(stats->rx_bytes); + tmp.tx_packets = READ_ONCE(stats->tx_packets); + tmp.tx_bytes = READ_ONCE(stats->tx_bytes); } while (u64_stats_fetch_retry_irq(&stats->syncp, start)); s->rx_packets += tmp.rx_packets;