From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 EC25126A0A7 for ; Sun, 25 Jan 2026 22:35:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769380503; cv=none; b=SHdeStmX2wmqCskRuTHuUGkJj8Uk2XbsWu151sOs1QR+H+TgLNsCYn+ZEOkOzGvUrvPJkA9SvE0KNMPKqgipJx+Guwjlm+s+Pz3/sNjWa3B8ITIFslLBKNmV4RhviEb+gWRbsW0QkwvWH5GmpgyhxyXLOzzNx8NyoI9Yd5dwkx0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769380503; c=relaxed/simple; bh=zSJsrelPe72OF5BSJWMzvjNyxJBtK7WlsleC8j161ns=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nqHd92jUaaA/tYjAg/D9XEGv+2lynzGpL1dxcaKF6itiNhrJM0SmC3Kp4maFEQrzpC9iFIx38DhA1ZIGBagtm8IXff5Mt04bEnhGzrLfvkcpKG7nxQUevTlDXCygG6qPopJCfEWpIU+dwv/QOPjbUsDAPRm4DJikcDPaX64EQx0= 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=iSCJJ2Be; arc=none smtp.client-ip=209.85.128.53 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="iSCJJ2Be" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-47ee07570deso29953425e9.1 for ; Sun, 25 Jan 2026 14:35:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769380500; x=1769985300; 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=T5wfJAo9SBLVU6wNmnYh+V5LIeGoq+TArwEbDi1cTkk=; b=iSCJJ2BekV2B0frxiVPUrp/ALSP9/vSjpviTumqWU1U8CSyf7nV/llbs8CR4yl+o6X /ABlPiyJ5dM+f2kAEERTpCNotgyNlhnJ0tHGxc9xL4e2nMSoA9BNuLKZfnrCFpg4wJzf UTnf65RDOnoVwWWfRCc8KUwPh/FvaBU4NK5feRvXv3O6+pxV8augkh/uWnKBWvQaO1KX 8ZqhVg5HEU+FsLPJ/7nrG5mnAQ3PTTUDAXELvObv1U38J9HqxIu4iSPZ2WQS4R5sFM7D LHhGsNnpLMgAP3ahn+BUi3IbAYvaF8+Efe2ipMEeyPXdM5Qg95qZRPDTpLrdcvxX1DWt 3XJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769380500; x=1769985300; 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=T5wfJAo9SBLVU6wNmnYh+V5LIeGoq+TArwEbDi1cTkk=; b=tBGnyCS3xzC1+vgsdcF3dYHiK2gRX0HKBQFcQ80LGtjuJ/PQpdY+2Gea+vkNaHPWFL gy7A64LXnWHTNevH5Tnaxug+OXiF8mj4CJXkXlzIZk8UVtZ1zSfn+76q9i+8aqcnKXyK 0ZZQ5HgeV1FIeSg2OmSo8oPE589ByeSJZdwGmhyrrJw2g7NXk5aQciafMCgyS/WKK3Bh TSlULB8XIqve2skh7qkIjlk/QleFTcNDaOmRq8V2IORROvJXJvYqeIX0JHmdaJVsV215 3m8sTXjiOj/ndT+ySr/WX1ccZssu+xo9+yLlFbJLNM1QDwQE95sXI965KSvQ3VRaMrvU wJgQ== X-Forwarded-Encrypted: i=1; AJvYcCWlmlbuVRlqplZMS4W3833UkY6QV9QaGuJBYp25amMC3TQPn/8nZX3ah2UTUcqp73YItIKHIDlT/2qPKCY=@vger.kernel.org X-Gm-Message-State: AOJu0YwcbQ82o2xIr946LvZ7FxrhY0AuVR7CwSLbFa79zve/r6FUBHd4 FJTI17wm7H4vpe8LylccFkMVIJo5EztjamrIXMAt/O41+Ac+CoNZlbxJ X-Gm-Gg: AZuq6aJnqrr5Fwtn1aTb0J0hIb7MJO8Zcp3fJtqhyeHmO/I9Pjtw1xRlRvP5efFCkJK MRG5UQD1rw8WkVOwr81CTEgHCEcLcyFlbdGxiUqhlSWbUT8+u+7xg/TkRvY3psA6Yp9GoxM8HsZ TiuIfsxeg0gntNg7VI0BvwVQItCzVkNl+/+6QfqMk+xoyPKPupO7hZizx1GbgEFWp6kXkf1pEab ag2n2uuySF3siHfZMs/c+wx2srMzsu9sutFy6f+oAMCsxiY2XTPZKUJnnWlrLkXfVZGLV84oeO6 sAeNrQGMom8SOrexl1d2L2wDXlatfbn4ohEUe1JEEzw/9Vud8L2xrZD690bwywMs1V2lxCgP6oE I/KYLrJ0izZQ0SpOknzz9ntQ7J6oC3MatEBev6vveA/z/0c3i6ycnSnZ5PmO/mK287/HWnulkeN 6VPMLQ8N1Ml0vp1kKi/afSo7lM/LCZB7oUby3qi58WcyhbcNEP3B38 X-Received: by 2002:a05:600c:4e4a:b0:47e:e20e:bbb0 with SMTP id 5b1f17b1804b1-4805cd40fcfmr49219325e9.6.1769380500182; Sun, 25 Jan 2026 14:35: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 5b1f17b1804b1-4804d8a5c32sm277706295e9.11.2026.01.25.14.34.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Jan 2026 14:34:59 -0800 (PST) Date: Sun, 25 Jan 2026 22:34:55 +0000 From: David Laight To: David Yang Cc: netdev@vger.kernel.org, Lorenzo Bianconi , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next] net: airoha: Use u64_stats_t with u64_stats_sync properly Message-ID: <20260125223455.31fd7a93@pumpkin> In-Reply-To: <20260122185255.2761568-1-mmyangfl@gmail.com> References: <20260122185255.2761568-1-mmyangfl@gmail.com> 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=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 23 Jan 2026 02:52:51 +0800 David Yang wrote: > On 64bit arches, struct u64_stats_sync is empty and provides no help > against load/store tearing. Convert to u64_stats_t to ensure atomic > operations. > > Signed-off-by: David Yang > --- > drivers/net/ethernet/airoha/airoha_eth.c | 136 +++++++++++------------ > drivers/net/ethernet/airoha/airoha_eth.h | 34 +++--- > 2 files changed, 85 insertions(+), 85 deletions(-) > > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c > index 62bcbbbe2a95..6ed220e5a094 100644 > --- a/drivers/net/ethernet/airoha/airoha_eth.c > +++ b/drivers/net/ethernet/airoha/airoha_eth.c > @@ -1472,131 +1472,131 @@ static void airoha_update_hw_stats(struct airoha_gdm_port *port) > > /* TX */ > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id)); > - port->stats.tx_ok_pkts += ((u64)val << 32); > + u64_stats_add(&port->stats.tx_ok_pkts, (u64)val << 32); > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id)); > - port->stats.tx_ok_pkts += val; > + u64_stats_add(&port->stats.tx_ok_pkts, val); Wouldn't that be better written as: u64 val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id)); val = val << 32 + airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id)); port->stats.tx_ok_pkts += val; (Assuming there something has stopped the hardware increment the register between the two accesses, and there is an associated atomic zero.) Otherwise you are generating 'tearing' on 64bit systems by adding the high and low halves separately - regardless of how the stats are read. I think that works for 32bit as well. Making the code completely unreadable with 'special' types and 'special' copy routines really doesn't seem worth while. The compiler won't generate code that does 'data tearing' for aligned word accesses, and even if it did nothing would really break. The most you want is a memcpy_in_words() function that guarantees to use 'word' size tranfsers for aligned buffers - and is probably an alias for normal memcpy() on all current systems. OTOH data tearing can be seen for 64 bit adds on 32bit systems. It is worth nothing that on 32bits the 'packet count' and 'byte count' increments get seen as a pair, this doesn't happen on 64bit - one happens before the other. David