From nobody Sat Feb 7 10:07:57 2026 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E5E82DA750 for ; Fri, 23 Jan 2026 16:22:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769185352; cv=none; b=g97Vkd9LZ3mPph8k5MFMhDT3oe7usUIPBPI+3+6r9B10i0efORvXSQOeiwvXmxjLuE59XVMeO5rSPe4ddc0K+YSx07WCU88pt2RNn6kde2VvikuNsWYFe2JjS3L93DiffyMZmdPBpoc7kk+L3/TJOtlRrPtWQEdluOHaMaI58Zk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769185352; c=relaxed/simple; bh=CWAmd2gDO+bz+iiUcK+EZ5ZuNzlcyN9HRHG8OTxXoro=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hAMfAZLcVDZyuYvrRTPLsY45YNCg+AhD8nzsZ9geXBj+vmOuJDR48rWgJg5H9m2TBWtfw+mKdWrqYg3/tprsGazxKeoaCCKYqqo/irp2GLaboBtiYt0LEuOHLMWWxj8xog1WT2uQzRJM/jz1U4JcXrFCS8YJG+Zvkt9Dg1ZyYTY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Z5lxFDcV; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Z5lxFDcV" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-b4755f37c3eso1685910a12.3 for ; Fri, 23 Jan 2026 08:22:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769185351; x=1769790151; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/v74RSchMzcO/nfO8KMHLNyi6DHe8JbEgv9uztbjT94=; b=Z5lxFDcVKbEg3CXyyUVQO1roqDKC76Pbn1gu3txOpP8wnDbuEQCE8Hqds2uS3gNic0 U+ZBe0SOrRvQLRt9nRuffQew107wk42pDDuoMzSES6a0iA0SLxLcCExVN2WeTcZ++W7s 6VlPOGaJy5GxJ2szjseJY1xqr+63t02Y5ibox3HSnTWG1C9YV6OdzhNuRhrCe+BcLbWw e/lSkCnyJZ96jYd80B42dZpMpssAixKlwR/PAA3dZY6FsWh6VMBNafNmEGoQ6wyfkpbP akVaSFxH6vhE3Q52htexu2GQdGolMzxjzOTnyMcEyw7djSwloXnWibIBtf1pFyqhepCN CvwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769185351; x=1769790151; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/v74RSchMzcO/nfO8KMHLNyi6DHe8JbEgv9uztbjT94=; b=gF0V51MgJSjv4LFuHEFAYm0pF3MAA58pfCiLS4voAm1CkY0fvVGky5uwQsrmLcjoq7 AQOSrW9teR1Jodl7PHRqcZYVPeq67GLD8fbxMTjOqU3MWDh4IZJRLQb/OKLRodfEgW+n IkO6ZWzY/NW0rhM0wBqY/956NFsaZEoyY9wsbkbsUORHlORy5rpxcY3cNkq2dCpvEkMI x/Pu4xB4qKRFR46ZSVt+ABsvEXWVkR4esYO69V95cDlwSoAzEubDucG/eq7GmoGZBueA o8haKz5BiqUO8xIy6L6/VcJVYUo0aVMH8Q0cRheCjrq4Qin8FLEm5rYvR+pfBN1m8SCF A3cA== X-Forwarded-Encrypted: i=1; AJvYcCUsMFALobKW6AFXztYdqH2OJzzGvMQ/L0XC28Lvmv95DnmB06Yum+n5bQ/CQpub4Niq5In6tDgsppkjRcs=@vger.kernel.org X-Gm-Message-State: AOJu0YwSy7FdvI9ZpMpZmn1qlbiLwqx/8ooJUpMTHuBSyly1ejSLiLTH jSDgmPhm/9JuiFajOCh/1jClqwY2WUqENj+dhrR1UjDnGSJGqh1VxH9F49XnoQ== X-Gm-Gg: AZuq6aLppWVANOXrmfzFbAcfyDf4j95ezVfzbSHbnm+QrMd0OMBxXY1bcXOUGAUeWH/ aR+NtvZnCkHhqmFcMwtQCUVlRcciLKBWLmMq0FFos0sdxoX7jBDX5PIRSWRimSJ+yI9XCDj7YVS ImyCX/t7mbD9UCSLZgj+aHWaR6Be2wTQcN6YMpyPqL23DZw6Mel40HpXXSK/MbcZnup+ly7Eh3c 0Z4/u83deX/wRRUeEwXgX9j8eKgo2cegyPTolK8qhU3PUy9g1sTDmRZzNRt+VeN5PwSUNk8vhZt ogKrbLDO8hZZpZZ2NfwujQSp+UN3SmRVtMwQQuv2TOooCtkYbGJBBR/VBOMVUY+BZcOqz+bn4oP FuwTCCQZwpSyn0IOohWqad1/L5Rg5K7nLfQgWyzMS34G42baRvpe84KF1nFPyhkLfqHMhpQbwMl 6F83nK+Oro44rzjtOhJUgXIwAjrP6aYKSOR9ovvDZFZQzLdg2SqVGiwLdNLPiojGBe X-Received: by 2002:a17:90b:548d:b0:353:38b3:dccf with SMTP id 98e67ed59e1d1-353688574f4mr3025512a91.23.1769185350618; Fri, 23 Jan 2026 08:22:30 -0800 (PST) Received: from d.home.mmyangfl.tk ([2001:19f0:8001:1644:5400:5ff:fe3e:12b1]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3536dc50882sm2496967a91.16.2026.01.23.08.22.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jan 2026 08:22:29 -0800 (PST) From: David Yang To: netdev@vger.kernel.org Cc: David Yang , Sabrina Dubroca , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Nikolay Aleksandrov , Ido Schimmel , Simon Horman , Aaron Conole , Eelco Chaudron , Ilya Maximets , Shigeru Yoshida , Stanislav Fomichev , Breno Leitao , Carolina Jubran , Kuniyuki Iwashima , Guillaume Nault , linux-kernel@vger.kernel.org, bridge@lists.linux.dev, dev@openvswitch.org Subject: [PATCH net-next v2 2/7] u64_stats: Doc incorrect usage with plain variables Date: Sat, 24 Jan 2026 00:21:34 +0800 Message-ID: <20260123162159.2877941-3-mmyangfl@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260123162159.2877941-1-mmyangfl@gmail.com> References: <20260123162159.2877941-1-mmyangfl@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On 64-bit architectures, u64_stats does rely on the load/store atomicity of 64-bit data. However, users often mistakenly believe that the helpers could also protect/"lock" plain (64-bit) variables, which can lead to load/store tearing. Remove the misleading "non atomic operation" comments and add explicit examples of incorrect usage. Users may also be tempted to use memcpy() or struct copying. Doc the usage of u64_stats_reads() for this case. Signed-off-by: David Yang --- include/linux/u64_stats_sync.h | 41 ++++++++++++++++++++++++++-------- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h index 15ea4db2a77b..10f988170e51 100644 --- a/include/linux/u64_stats_sync.h +++ b/include/linux/u64_stats_sync.h @@ -39,21 +39,44 @@ * spin_lock_bh(...) or other synchronization to get exclusive access * ... * u64_stats_update_begin(&stats->syncp); - * u64_stats_add(&stats->bytes64, len); // non atomic operation - * u64_stats_inc(&stats->packets64); // non atomic operation + * u64_stats_add(&stats->bytes64, len); + * u64_stats_inc(&stats->packets64); * u64_stats_update_end(&stats->syncp); * * While a consumer (reader) should use following template to get consiste= nt * snapshot for each variable (but no guarantee on several ones) * - * u64 tbytes, tpackets; - * unsigned int start; + * u64 tbytes, tpackets; + * unsigned int start; * - * do { - * start =3D u64_stats_fetch_begin(&stats->syncp); - * tbytes =3D u64_stats_read(&stats->bytes64); // non atomic opera= tion - * tpackets =3D u64_stats_read(&stats->packets64); // non atomic o= peration - * } while (u64_stats_fetch_retry(&stats->syncp, start)); + * do { + * start =3D u64_stats_fetch_begin(&stats->syncp); + * tbytes =3D u64_stats_read(&stats->bytes64); + * tpackets =3D u64_stats_read(&stats->packets64); + * } while (u64_stats_fetch_retry(&stats->syncp, start)); + * + * Remember point #2: update_begin()/update_end() and + * fetch_begin()/fetch_retry() are no-ops on 64-bit architectures. u64_sta= ts + * _cannot_ be used to protect plain variables against tearing. + * + * u64 stats64, cnt; + * struct { u64_stats_t stats[10]; } st, buf; + * + * u64_stats_update_begin(&stats->syncp); + * stats64 =3D cnt; // no + * stats64 +=3D cnt; // no + * stats64++; // no + * st =3D buf; // no + * memcpy(&st, &buf, sizeof(st)); // no + * u64_stats_update_end(&stats->syncp); + * + * do { + * start =3D u64_stats_fetch_begin(&stats->syncp); + * cnt =3D stats64; // no + * buf =3D st; // no + * memcpy(&buf, &st, sizeof(st)); // no + * u64_stats_reads(&buf, &st, sizeof(st)); // use this instead + * } while (u64_stats_fetch_retry(&stats->syncp, start)); * * * Example of use in drivers/net/loopback.c, using per_cpu containers, --=20 2.51.0