From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 6F6C127B32C for ; Mon, 26 Jan 2026 19:19:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769455143; cv=none; b=G1f5kCxdE6ikhwyqK36YnfHlyuS/Y6cAYdk+I0Q2oMYpLa9uyIYa0YqTZjL9pEolptIpfxCjwdrhWU8aVCidgYFWcgh8Dn8kUurpnsQh6Cki19r03T4Te8i1okhLDjXWqisH9EU3zo8h85I7Oqzwom+h7iw181rsn6XmD/MiMFU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769455143; c=relaxed/simple; bh=X7WKfIe2F3sKHAkHtT8gREVlj3Y0lWqGCtTKhqJkDFs=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=PGqKtYGlBVG4HNz1ZMxpPHoGf5Uvquz9a6rsjM+nYiqbNcUf6RwdPz1hv3wtsdo96yddumCkNEeArwZPPp3CPg+mrWmwCDWS2Qm15lfgdWxIuJOSgoe27mFj2bRTbKt67oju0LVFIeEWslr329EHtJBQY+lWvTBo7xXV+TcKm38= 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=JCMhsNji; arc=none smtp.client-ip=209.85.128.52 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="JCMhsNji" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4801d1daf53so53123125e9.2 for ; Mon, 26 Jan 2026 11:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769455141; x=1770059941; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=UMORb+r1omq1DqBVvxD9Q2gvnIjSytvIGqt6iuJXuFo=; b=JCMhsNjiaIbp9WUn0wKRa7p9oZeoVwCthQb+Yyh/DlJe6HNX9Zw/LU4jlrohrdaVEP PVtFx/IgXgGiuv2y74MlHKc2/iTJsCNFRWrA33nqCbE7LCaJC58kSQG2aCR4hSk4/0/z 9P/lSgREzGR2iQLGbZGRnmQAKfvAJfQp8uIa8rWfiFe8sLEKR7xnd13xWwK9b7JKG9qI EA0nlCL9ujjPwhcnu/MO+TDY7frTesfjbtNwT4ywLyIkk5WRAv/gcc1mGlqh4Kogb75l SON+DLpYL/CrEFfwa9nEsEE2huhuajcSPiz6t7rBNE9TDZUy1F8hcUbxbxA18kavVyHz +jKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769455141; x=1770059941; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=UMORb+r1omq1DqBVvxD9Q2gvnIjSytvIGqt6iuJXuFo=; b=FwYrLMXrcUToLnqkAOw567LJeuTkLaVLX0X/pJfaFO7NUyh4pkXnlmQjOn0SckPypF LAcinzUVQaLkq5et8UjG3shaqHU9Tx9IhxPtN3KpAqhjqb7+d2cccU3hW7thVdzKz/Mh AdIo3MaaoKPugGChr4TfXrxNf4DDOy1vZzZ7gPUIHUZhVQuTxscmgpbSe+vXUCvOg8E7 lAi0QCCOfgHEljzj3o4bkSL6a5TklbMH8xYym3Qa7BNxviSZcA1gSb0HFRLayiBi/dIq 16sHukZd82yLOYjU+eUrqRgEGlXMQoyLPvjoj2OZ3l8dJFN14xwHoi7eh48DYaAHhPvV djkg== X-Forwarded-Encrypted: i=1; AJvYcCWFWQOdKabgF3J4cTQ7mcIrYlTjT3HtjHWCnldOddTwjMAutF4drFdhGpwtVoSqZaeRDyJRb2g3q/nAd2I=@vger.kernel.org X-Gm-Message-State: AOJu0Yz8FTX9H6ASHYNZsMP6NVqayhAwGyfIbZi152jOrt4+/B7DWwyr 7sdtOeAwIl+fNZB92Wfzhw4TWv/CZdHuf77zQkxNx7zKa5AHfECOMP/7 X-Gm-Gg: AZuq6aIqzxMX68kLaMFQO18WAeGnw0+CxYApOxrC5zmsefVPlKfXbDjpIfNg+Qq2j3y zao4aFy+vT/zp1QJej+3GgIsKzuqCCBZfYu3g7Co/ym7PH/WhnQ0VSQDuaj+VrwTYEV3ykVlfwh iQVffFNsXO+Y4QPUSxVHPRJZrSe06WmXEHRn1YJzM9LVLBFvady9HiCkMg4I6VXFMyI2nbYnjSq Sqtv0T+ODTN38fqo+TWllB4NCUaOcLX4JKQtsYGbgELIAA11gU7UpvoKYRlxcrF+qLg0RTvxnzE nVh29iPe0wtneFXwVLkGXMAqrNmgjyUxW495BgZoetgscFm65YzqYggvkyE3+18PffIGFL/wvlZ iQcoJhIsLiJXcgv3FRsLBd4Q+Md8FNuIOWDhqyz/84pR9I3+D8rGTFe2OuVseWefLl+XKnWxPiU F4fB8kOdrQ7WRNQGMorXqXADTjOI2nKtzdkbm56fWepVnFPavoNvx4 X-Received: by 2002:a05:600c:8b16:b0:47e:c562:a41f with SMTP id 5b1f17b1804b1-4805cf5f1a5mr80909895e9.18.1769455140603; Mon, 26 Jan 2026 11:19:00 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435b1c24a8asm32075802f8f.12.2026.01.26.11.19.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 11:19:00 -0800 (PST) Date: Mon, 26 Jan 2026 19:18:55 +0000 From: David Laight To: Eric Dumazet Cc: David Yang , netdev@vger.kernel.org, Aaron Conole , Eelco Chaudron , Ilya Maximets , "David S. Miller" , Jakub Kicinski , Paolo Abeni , Simon Horman , dev@openvswitch.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 4/7] net: openvswitch: fix load tearing with u64_stats Message-ID: <20260126191855.04018872@pumpkin> In-Reply-To: References: <20260123162159.2877941-1-mmyangfl@gmail.com> <20260123162159.2877941-5-mmyangfl@gmail.com> <20260126182928.39ab1d58@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 26 Jan 2026 19:35:38 +0100 Eric Dumazet wrote: > On Mon, Jan 26, 2026 at 7:29=E2=80=AFPM David Laight > wrote: > > > > On Sat, 24 Jan 2026 00:21:36 +0800 > > David Yang wrote: > > =20 > > > On 64bit arches, struct u64_stats_sync is empty and provides no help > > > against load/store tearing. struct copying should not be considered > > > tear-free. Use u64_stats_reads() instead. =20 > > > > Except that the compiler doesn't ever generate 'tearing accesses' for > > aligned 64bit accesses on any 64bit architecture. > > Similarly memcpy() won't generate problematic accesses. > > > > The problem is purely theoretical - the C language lets the compiler > > split accesses, but it doesn't. =20 >=20 > Yeah, although we still have races that KCSAN can detect. >=20 > data_race() or READ_ONCE() would be necessary to avoid noisy KCSAN report= s. >=20 > While many KCSAN reports are boring, some of them point to real bugs. >=20 Could something be put in u64_stats_fetch_begin() to stop KCSAN bleating? With the way READ_ONCE and WRITE_ONCE now get enforced I do wonder if some data shouldn't just be marked 'volatile'? That would give 'non-tearing' accesses, but without the inter-cpu ordering that (I think) READ/WRITE_ONCE also give. For stats counters that is enough. David