From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB5CB1553AA; Wed, 4 Jun 2025 00:52:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748998348; cv=none; b=KROYNMSZtGE3DaJ80dNo5AxepnzhjiQgPhijn6B2SS/QxZwJdJCrcycETp5t5V9Ht2W0FAZil9Pm7ZZY9TtPGEc1zNzVl8IKp0XDCw2dv3e8m0ULlrrCEP85QMSvRHa2fGo4v0C9K1zdma125bWkyQSWZysvFib8qztHDB4dHLQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748998348; c=relaxed/simple; bh=pI5EtjIR+Gd1ZUGKs+hQPSxBJfgW9d78S5kjWynaYTw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=KmYmG3rO0MPpk14N5UNKwY+e+UZEM2lH2Iudfqkdo99VucPSrDPbJfD/lAtVdevTovroNSF8qv36b77L0rX6upTtJcun6i9KLwyOhO71Z3GuzedeBRy5ar3TwxE42eA98WX23UbRYqrg8Pt89Czw7u5ORt01ohPsf60UliCUsWU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rZd69Eq0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rZd69Eq0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD6B9C4CEED; Wed, 4 Jun 2025 00:52:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748998348; bh=pI5EtjIR+Gd1ZUGKs+hQPSxBJfgW9d78S5kjWynaYTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rZd69Eq0HIUAcamFW9nOFHGQ4SW7mY54ZW1kFKtNR6/hNGCsz4ARbTCIGeUrCkGci kxe+TaT87yKP5B+40iJGefsBElvuU4jLxfAk97WxJM4CPsjanvmXnLOS1wRml37bgc VodOSRtf3EBC9JDfhllOEsZLYnvRUdN8g+XJMU+MRbeuyXPYLVFpQFYG4d3vEYyizB S/QW6e6vxnOFbgLKSblbbqrlyygss/1+uwvk1bOiA7XzKQzb7+djK9Daap7FbGF+4U K8V9L1YZel0np7SzIg3wqlVxqApIQ+l+0DiqF5Cl0vfVafc7/SlcGbblGyMIzrOv+o T8WUWlECg6UDg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Jason Xing , Jakub Kicinski , Sasha Levin , mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, 0x1207@gmail.com, andrew@lunn.ch, pabeni@redhat.com, hayashi.kunihiko@socionext.com, vladimir.oltean@nxp.com, netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: [PATCH AUTOSEL 6.15 049/118] net: stmmac: generate software timestamp just before the doorbell Date: Tue, 3 Jun 2025 20:49:40 -0400 Message-Id: <20250604005049.4147522-49-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250604005049.4147522-1-sashal@kernel.org> References: <20250604005049.4147522-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.15 Content-Transfer-Encoding: 8bit From: Jason Xing [ Upstream commit 33d4cc81fcd930fdbcca7ac9e8959225cbec0a5e ] Make sure the call of skb_tx_timestamp is as close as possbile to the doorbell. The patch also adjusts the order of setting SKBTX_IN_PROGRESS and generate software timestamp so that without SOF_TIMESTAMPING_OPT_TX_SWHW being set the software and hardware timestamps will not appear in the error queue of socket nearly at the same time (Please see __skb_tstamp_tx()). Signed-off-by: Jason Xing Link: https://patch.msgid.link/20250510134812.48199-4-kerneljasonxing@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- Based on my comprehensive analysis, here is my assessment: **YES** This commit should be backported to stable kernel trees. Here's my detailed analysis: ## Code Analysis The commit moves `skb_tx_timestamp(skb)` calls to execute immediately before the hardware "doorbell" operations: 1. **In `stmmac_tso_xmit()`**: Moves `skb_tx_timestamp(skb)` from line 4483 to line 4532, placing it right before `stmmac_flush_tx_descriptors()` 2. **In `stmmac_xmit()`**: Moves `skb_tx_timestamp(skb)` from line 4759 to line 4823, placing it between `stmmac_enable_dma_transmission()` and `stmmac_flush_tx_descriptors()` ## Why This Should Be Backported ### 1. **Follows Established Kernel Patterns** This change aligns with the kernel documentation requirement that drivers "call skb_tx_timestamp() as close to passing sk_buff to hardware as possible." It matches the exact pattern used in the NFP driver fix (Similar Commit #5) that was marked "Backport Status: YES" - both move `skb_tx_timestamp()` immediately before the hardware doorbell operation. ### 2. **Addresses Real Timing Accuracy Issues** The original code creates a problematic gap between when the software timestamp is recorded and when the packet is actually handed to hardware. This affects: - PTP (Precision Time Protocol) synchronization accuracy - Network performance debugging tools that rely on precise timestamps - Applications using SOF_TIMESTAMPING_OPT_TX_SWHW that need correlated SW/HW timestamps ### 3. **Fixes Race Condition** The commit message specifically mentions reordering to prevent software and hardware timestamps from appearing in the socket error queue "nearly at the same time" without SOF_TIMESTAMPING_OPT_TX_SWHW. This indicates it addresses a race condition in the timestamp handling logic in `__skb_tstamp_tx()`. ### 4. **Minimal Risk of Regression** This is a simple reordering of existing function calls with no new functionality or complex logic changes. The transformation is identical to multiple other network drivers that have been successfully backported. ### 5. **Important for Embedded Systems** The STMMAC driver is widely used in embedded systems and SoCs where precise timing is often critical for industrial applications, making accurate timestamping particularly important. ### 6. **Matches Reference Patterns** The Similar Commit #5 (NFP driver) with "Backport Status: YES" shows this exact same type of fix - moving `skb_tx_timestamp()` to just before the hardware doorbell - was deemed appropriate for backporting. The STMMAC commit follows this same proven pattern. This commit fixes a legitimate timing/correctness issue with minimal risk and follows established patterns that have been approved for stable backporting in other drivers. drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 59d07d0d3369d..6c90a88f7b0ea 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -4488,8 +4488,6 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev) if (priv->sarc_type) stmmac_set_desc_sarc(priv, first, priv->sarc_type); - skb_tx_timestamp(skb); - if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) && priv->hwts_tx_en)) { /* declare that device is doing timestamping */ @@ -4522,6 +4520,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev) } netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len); + skb_tx_timestamp(skb); stmmac_flush_tx_descriptors(priv, queue); stmmac_tx_timer_arm(priv, queue); @@ -4765,8 +4764,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev) if (priv->sarc_type) stmmac_set_desc_sarc(priv, first, priv->sarc_type); - skb_tx_timestamp(skb); - /* Ready to fill the first descriptor and set the OWN bit w/o any * problems because all the descriptors are actually ready to be * passed to the DMA engine. @@ -4813,7 +4810,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev) netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len); stmmac_enable_dma_transmission(priv, priv->ioaddr, queue); - + skb_tx_timestamp(skb); stmmac_flush_tx_descriptors(priv, queue); stmmac_tx_timer_arm(priv, queue); -- 2.39.5