From nobody Fri Oct 2 13:03:26 2026 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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 9EB8D3191D3 for ; Fri, 31 Jul 2026 09:02:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488551; cv=none; b=mFkHw9PL9KHwrSbYs9DifYyZqNn5WPeTYHldUUTZ/6S103avdMd0NTT5hSnCwu2lSUd2oWOHdvZqHjApW21xtdfLE3SoZnKXHUDhl0ICmhli/YeuVwTHZUwJa/DExaKc/zlUr/jDnac7BW5R+yPi+9P9StpWAfp2npQpPIRAA0A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488551; c=relaxed/simple; bh=0rflTe54TijjzunwMIYxkwBCoYwbcmj+eJ/5a8rrMtk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UE4CA/gfe8Wn60WXrlqtdhyoQnLX9QZtpyzHvOxeVNoXBa5+/oVqVoPJPXqKQcLtATLp0vgTPAZC3n/pk/AzipqrtEdSjVpVD3NYNkDziB9kaai0T9+FfNFUSWzTe0WWTtedSjEdMfjSAjvMHDYxs28QviuF0R0RCcEJ1HRXUOQ= 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=EaJCrdRf; arc=none smtp.client-ip=209.85.208.46 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="EaJCrdRf" Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-69f4acf7047so98490a12.3 for ; Fri, 31 Jul 2026 02:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785488548; x=1786093348; 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:content-type; bh=l1mYauMG9GINwFO5wrxlpL/vPzaA4PT/FlWkWnobmqU=; b=EaJCrdRfaotcSsuVX/jCAW+VvhsKtLvkQ8y4Gyyaus19YJGVbfPuw47KiTaQNoe55k YAHVgFRSazuMRJd6NPsX8j+llqye4Fj6I+Bv7GJEqzxs4uDmhQ2de5VVjIptgksYK6r4 Z1p5ap+dNTOj6i3rzyBtHPSgzmWRlLSn85H6QG3wX638lhOD534LtyPitN+CMtBP6T6z XXgSKVG3XfPopMMUq7xqAyMOMSsq5WgA5IyhNLyzH7cIFI5kf3R9OGRzHG8F+W6m92In BY4VVFS2tbiibLfCL8xhblfy7nbsus09K7n1Mlgd4vLTS3lTlbp0cV3C6BZFJBuPkkjL 9arg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785488548; x=1786093348; 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:content-type; bh=l1mYauMG9GINwFO5wrxlpL/vPzaA4PT/FlWkWnobmqU=; b=Lo3VFYFKa6qUcok9NOKAhKDZMIvViJvg9TOIszSpSTQ4SN37SfPMD9ceOZN+stLEdF sYiIlSMJtLE5SD08MKeGJgDQDJA7Nxx/ogr0kyFBDSyaeXyyqsSmjuCqpTQFSWOfrNwO an4sV4eOWOHNqb4MpmD6cYpM2qLuaUtVHa8NQR9HEU8XcnbCtCE9FNvUJ9pgWesnvVMI ED61EzW8w7KYu+sDFKgZ0uUbBAr/g9yhyXWYwIXUwCORcIdlauxLUnV8634z5GpTgGfG trAndUJ45MlKv/M/liFzVBprk1ay+7EK1Ofpu0Xfm/bmW4nBXqwuDg+mgeNueOiY0uvL N7Bw== X-Forwarded-Encrypted: i=1; AHgh+Rr2wRscl5nvw/dTqIuJ+HY/D6nBI5GNYjI+MG0kZcfDaDNNA6Jb/KrpSTUn7lK8Ftxzy+zSPr4FfsRFyHY=@vger.kernel.org X-Gm-Message-State: AOJu0Ywe37VO2mydbacCV7kg5Ptv5RP6J+OOTg8wyMGR9WJ5IPodW/nG HYGme36e8bbN7y5fwE59NbxjVUkW1l3Wa+cMupZvFeJde6QC+S1+jJu8 X-Gm-Gg: AR+sD13qInc32z6oqOcq+V6VHEPampvTSP0SRWhZjgP0ptUMdaK6rcKpJTjmoeqpSC/ Zlv2iHplolMTA+1fozVtE1PAbXhdy8UQlvbwECdEZ0yxPTTo+mIeSEoob1/YZBA4My9E3AoZjj5 44rAEfsIYW8n8L6dOMscA97e+udbO9cxfEtS7aa/Ld5r/3dKFReTeGQaMSN+93iD6DqK2/lrqNp WZRbmXoVM8Djg1+ztNuHJuzrUw6It523YymgiSDjq2wjlP/LyoRKWjVQ/PM2Ex1RToa9a4ZTX7m vty9AF2wLbikQPeNYwcz2wCoLkhQCoPanu6PLaxyjGxg3Ynb/Di8PhXMoG/4hnYlMUKmyHZP5Ul 5a8+RULgde938Rza4ynNQ99LGOZGyOCGmhNJr8riUxlwnwz/zDpyvrL+8QN9SBpeph01YT1JO9K Jv8xJRYb6JDfOpQfArSgJSewus7kVZdTKmO9tUIcLkzzzI5X6vGgs+HEI3hITyEarze+pzkZRV/ 8+QCFhwQk1kVqmf3b1+8RFKMTlHdgk5dnOJUyBRIpoIHDs+qBcq1hbAzmkjikVoGS87xUWHouUM Ca0CWNFY5qbG9gbSUM8N7Q== X-Received: by 2002:a05:6402:2424:b0:67d:4eea:a29d with SMTP id 4fb4d7f45d1cf-6a098f25f0emr740566a12.4.1785488547476; Fri, 31 Jul 2026 02:02:27 -0700 (PDT) Received: from L-022584.energy.envision.com (dynamic-077-184-219-058.77.184.pool.telefonica.de. [77.184.219.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41d1a58sm2965051f8f.7.2026.07.31.02.02.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 02:02:27 -0700 (PDT) From: Xin Xie To: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, shuah@kernel.org, kees@kernel.org, petr.wozniak@gmail.com, qingfang.deng@linux.dev, fmaurer@redhat.com, luka.gejak@linux.dev, bigeasy@linutronix.de, xiaoliang.yang_1@nxp.com, skhawaja@google.com, stable@vger.kernel.org, Xin Xie Subject: [PATCH net v3 1/4] net: hsr: fix packet drops caused by GRO superpackets Date: Fri, 31 Jul 2026 11:02:20 +0200 Message-ID: <20260731090224.18-2-xiexinet@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260731090224.18-1-xiexinet@gmail.com> References: <20260731090224.18-1-xiexinet@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" HSR/PRP append a 6-byte tag/RCT to every forwarded frame and process each frame individually (sequence numbering, duplicate discard). When a lower device aggregates received frames into a GRO super-packet -- in software, or in hardware on GRO_HW-capable NICs -- the HSR receive/forward path sees a single skb instead of the individual frames. Depending on the lower device, that super-skb is then either rejected outright (for example when it exceeds the lower MTU at egress), or forwarded without valid per-wire-frame HSR/PRP processing: its single trailing tag/RCT cannot represent the per-frame trailers and sequence numbers of the aggregated frames. On memory-constrained devices, processing super-skbs in softirq context can also pressure atomic memory allocation. The HSR/PRP stack already disables LRO on enslaved devices for the same reason. Extend that treatment to GRO: add netif_disable_gro() and dev_disable_gro() mirroring netif_disable_lro()/dev_disable_lro(), and call dev_disable_gro() from hsr_portdev_setup() so enslavement to an HSR/PRP master automatically strips NETIF_F_GRO and NETIF_F_GRO_HW on the lower device (recursively on its own lowers, as with LRO). This is a setup-time default, not an immutable feature policy: a later privileged feature override, or a lower newly attached below a stacked slave, can re-enable GRO without re-walking the HSR enslavement path. Patch 3 is the fail-safe for that case: a GSO skb that nevertheless reaches the forward entry is segmented on the plain master/interlink paths or rejected on the LAN/tagged paths, so invalid aggregates are never forwarded as-is -- though a later override can still cost traffic on a LAN ingress. Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamle= ss Redundancy protocol (HSRv0)") Cc: stable@vger.kernel.org Signed-off-by: Xin Xie Reviewed-by: Ali Ahmet Memis Tested-by: Ali Ahmet Memis --- include/linux/netdevice.h | 2 ++ net/core/dev.c | 18 ++++++++++++++++++ net/core/dev_api.c | 16 ++++++++++++++++ net/hsr/hsr_slave.c | 1 + 4 files changed, 37 insertions(+) diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 9981d637f8b5..eba2c26a49ba 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -3434,6 +3434,8 @@ void dev_close(struct net_device *dev); void netif_close_many(struct list_head *head, bool unlink); void netif_disable_lro(struct net_device *dev); void dev_disable_lro(struct net_device *dev); +void netif_disable_gro(struct net_device *dev); +void dev_disable_gro(struct net_device *dev); int dev_loopback_xmit(struct net *net, struct sock *sk, struct sk_buff *ne= wskb); u16 dev_pick_tx_zero(struct net_device *dev, struct sk_buff *skb, struct net_device *sb_dev); diff --git a/net/core/dev.c b/net/core/dev.c index 5933c5dab09e..a6cf2adc8625 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1840,6 +1840,24 @@ void netif_disable_lro(struct net_device *dev) } } =20 +void netif_disable_gro(struct net_device *dev) +{ + struct net_device *lower_dev; + struct list_head *iter; + + dev->wanted_features &=3D ~(NETIF_F_GRO | NETIF_F_GRO_HW); + netdev_update_features(dev); + + if (unlikely(dev->features & (NETIF_F_GRO | NETIF_F_GRO_HW))) + netdev_WARN(dev, "failed to disable GRO!\n"); + + netdev_for_each_lower_dev(dev, lower_dev, iter) { + netdev_lock_ops(lower_dev); + netif_disable_gro(lower_dev); + netdev_unlock_ops(lower_dev); + } +} + /** * dev_disable_gro_hw - disable HW Generic Receive Offload on a device * @dev: device diff --git a/net/core/dev_api.c b/net/core/dev_api.c index 437947dd08ed..02fb21629512 100644 --- a/net/core/dev_api.c +++ b/net/core/dev_api.c @@ -269,6 +269,22 @@ void dev_disable_lro(struct net_device *dev) } EXPORT_SYMBOL(dev_disable_lro); =20 +/** + * dev_disable_gro() - disable Generic Receive Offload on a device + * @dev: device + * + * Disable Generic Receive Offload (GRO) on a net device. Must be + * called under RTNL. This is needed if received packets may be + * forwarded to another interface. + */ +void dev_disable_gro(struct net_device *dev) +{ + netdev_lock_ops(dev); + netif_disable_gro(dev); + netdev_unlock_ops(dev); +} +EXPORT_SYMBOL(dev_disable_gro); + /** * dev_set_promiscuity() - update promiscuity count on a device * @dev: device diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c index 01c73b4b50dd..da06b21cdf51 100644 --- a/net/hsr/hsr_slave.c +++ b/net/hsr/hsr_slave.c @@ -170,6 +170,7 @@ static int hsr_portdev_setup(struct hsr_priv *hsr, stru= ct net_device *dev, if (res) goto fail_rx_handler; dev_disable_lro(dev); + dev_disable_gro(dev); =20 return 0; =20 --=20 2.43.0 From nobody Fri Oct 2 13:03:26 2026 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 F1C3D30E82E for ; Fri, 31 Jul 2026 09:02:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488552; cv=none; b=kxA2PxGgebUJlr9VpsgxfuNcUAWrmDPtUKAeZiIfrvqzLTG7wd3R6psbBabO/m65pulzr4sq9a3nP3fpN5q9Q5HriR7yXIYG1bPhUs6bCYrY0hh2fy7A6V/m9NH7E982/SVwbXuWthFcPQsFFezKb4qOkck0XxfYNb0Qb4DytRA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488552; c=relaxed/simple; bh=imTV0lVDCJfkhzd13WmGrGkOzMCAQaUcglG1OsyAMdY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kWMiqhImNt/knDGR4k0uHl9MFI28zyYsrw3O8vInnQ06Tga5vepk/jc1wHp/iwUk9gijEGR6WyyQJe7kft+vupI7uuzkh4mK1ai0RAN/x46jwKSKSwS4PNvcys90mjtIU/b4Uhs3Dh1x5vR3DTL2Bt7AzvZYwNqIcVCBXWqlULY= 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=spPR/zoE; arc=none smtp.client-ip=209.85.221.51 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="spPR/zoE" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-472d9d69e16so56567f8f.0 for ; Fri, 31 Jul 2026 02:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785488549; x=1786093349; 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:content-type; bh=dcpIWu2gPXbEkinbrLRL7Y5Q8sZSbgxuISV/4k1U49M=; b=spPR/zoERGOuuUJTx57ShqNTpsxUS6lrwaP5ugtyi0wJOr4CUAiOqN6I23ruVybMkY WiJRSiy1V+mo/H75tUseFU6mpsweNRsmGAtWvkQaHfYAtq6wSZPgewvdrplEJKSCjS7T 5Cl9XevwIxFmR8AOp9/pnQfziGOcpwtg3Aa6xAnAEVNcXgJ6SNzako/WUY5iWqdirCFi K1x27qyX5vRee5Rcu7qb5/JC6FJNWNezhkiRU/GfgnnkTFcIIPJ3O2SqaQT1N6IrsHgv CZUndoXNCRXb+21jas9F7Q0T7zg++GPAjukNvhqG4gRNJnV74vk96o/psgZ7DJJAqGGr pjJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785488549; x=1786093349; 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:content-type; bh=dcpIWu2gPXbEkinbrLRL7Y5Q8sZSbgxuISV/4k1U49M=; b=hZtCZNp7YKRSu5Yw3Ddp77hcsT6EasLtu5otORIXnge/YKh6AJON4nXLLWMxG6FVNq 0zzOZpcka4Ukke2JZlIL/TQaq8u1I/bMkNTEFf6qlMGbf4Toy/URvxzroIDfTK7/bMW+ NfWvToXw5yilwUPSSE0lB0pPZvWYOLFyuq0nC2PNI+9xlpSl1akzqUmmqSBajTwxjHR2 m6BfKRtzkiVxJLeTIz0w49iw//Ab45RbHd1ZGZ3QmPCuEerktpI9HS7ntn7CK+RnatFK RN04F5USdmhXAuIS3lH4PnI1M+gM1OAvq7YWzaQXXVsosLxFGOJTfchbcQs6jidSAfa4 5Itw== X-Forwarded-Encrypted: i=1; AHgh+Rp4xew5hwDy87mueGBKM5/eKMDJ+Lc6sXyRjjxsGi7soBOi187DQ+mWMHTaXHGbc3p6sQ89FhG4lyK8AD0=@vger.kernel.org X-Gm-Message-State: AOJu0YwKGXc4iMhFvrqF7xrw9VM1BYBSHd4q4hOSln6rJZxAknIlRge2 S2lYAYCcZcnjztJeQQ7T1ngafNRCluWl+mpneq5GTh4lOGCKlOGT2oEf X-Gm-Gg: AR+sD13n267t7/m7picLbZFi0ieJmya5CQM3GWe3exKVHYxYrx/iJa42yO6BHefXwKY sRjqiBryS4bmYuXZD9PlywbVto6Hdo8tAn6blqXlyDsJR7BQXcGffPGA7gSgPAWIM4pfFbt3WE8 3zMbkYGf/eWisL5pY6SbCXhmatC8aAYYPwJKt5JvDhqpsWN7P5Wlgov5RsZMn6tGqyv+bqRlCYo //0SI/M9KyeRvSninIfzTILecd4RG6aVTSgMb7EKqdm1ZSShBjV5IZNKTcw6bFL4K8aqoaLiUvI KgRIcDNOV54x0Q5kmzW2AEuGhIV9YR3uiMDnLhp+7FWw5hYxvosc1F8+HQwd4YH1ie0HJQZ15Wr B+nKDcKXbBsOg/PGEMWznxbF/Pfj1fGy7qcNR16UncRI0HeJ5SPG2Inn1mPUuT+S+o2tp55M2IP 7+IW/qZerL73KfH1iLB1KVPSim8Mp7ZSYkueiGNAR2u4NSNxNy8w4+CfvQijZEYj+nfr7BLSdRV RCL3NIfs4PimjSTDdLk6TTxBOrWi/JsBkHvZdjGOlgAObHO5WQBjGRsivPBt121Qpe198qnYvW7 012y18eSokMu3XRsFy7CHQ== X-Received: by 2002:a05:6000:240a:b0:470:f631:8316 with SMTP id ffacd0b85a97d-47fd2b4e441mr3218259f8f.3.1785488548831; Fri, 31 Jul 2026 02:02:28 -0700 (PDT) Received: from L-022584.energy.envision.com (dynamic-077-184-219-058.77.184.pool.telefonica.de. [77.184.219.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41d1a58sm2965051f8f.7.2026.07.31.02.02.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 02:02:28 -0700 (PDT) From: Xin Xie To: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, shuah@kernel.org, kees@kernel.org, petr.wozniak@gmail.com, qingfang.deng@linux.dev, fmaurer@redhat.com, luka.gejak@linux.dev, bigeasy@linutronix.de, xiaoliang.yang_1@nxp.com, skhawaja@google.com, stable@vger.kernel.org, Xin Xie Subject: [PATCH net v3 2/4] net: hsr: shrink seqnr_lock to sequence counter updates Date: Fri, 31 Jul 2026 11:02:21 +0200 Message-ID: <20260731090224.18-3-xiexinet@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260731090224.18-1-xiexinet@gmail.com> References: <20260731090224.18-1-xiexinet@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" hsr->seqnr_lock is currently held across entire hsr_forward_skb() calls: master TX (hsr_dev_xmit()), interlink RX (hsr_handle_frame()), and both supervision frame builders hold it while frames are built, classified, duplicated and forwarded on every port. The only state that actually needs the lock is the sequence counters themselves (hsr->sequence_nr / hsr->sup_sequence_nr). Shrink the locking to the individual counter updates: handle_std_frame() now takes the lock around its sequence number allocation (replacing the lockdep assertion), the master TX and interlink RX paths drop their outer lock, and the supervision builders release the lock right after updating their counter instead of holding it across frame construction and forwarding. Ordering: with IFF_NO_QUEUE and dev->lltx, hsr_dev_xmit() is concurrently callable, and this change removes the old allocation-through-forward ordering guarantee there: master-TX frames may now be emitted out of sequence-allocation order. On the current tree this is safe because duplicate discard tracks individual sequence numbers in sparse bitmaps (commit aae9d6b616b5 ("hsr: Implement more robust duplicate discard for HSR") and commit 415e6367512b ("hsr: Implement more robust duplicate discard for PRP")) rather than requiring monotonic arrival. Sequence numbers remain unique and monotonically allocated per counter. This is a latency/critical-section prerequisite for unfolding GSO super-packets at the forward entry (not a functional prerequisite): the segmentation work should not extend the global sequence lock's critical section. Patch 3 depends on this change; their automatic stable selection is limited to 7.0 and newer, where sparse-bitmap duplicate discard accepts out-of-order arrival. Older stable branches require an adapted backport. History of the lock being narrowed: it was introduced by commit 06afd2c31d33 ("hsr: Synchronize sending frames to have always incremented outgoing seq nr.") and briefly removed by commit b3c9e65eb227 ("net: hsr: remove seqnr_lock") in net. Merge commit 46ae4d0a4897 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/n= etdev/net") reverted that removal because commit 430d67bdcb04 ("net: hsr: Use the seqnr lock for frames received via interlink port.") in net-next had already superseded it by adding locking for the interlink RX path. All sequence counter updates remain protected; only the forwarding work moves out of the critical section. Cc: # 7.0.x Signed-off-by: Xin Xie Reviewed-by: Ali Ahmet Memis Tested-by: Ali Ahmet Memis --- net/hsr/hsr_device.c | 15 ++++----------- net/hsr/hsr_forward.c | 3 ++- net/hsr/hsr_slave.c | 11 +---------- 3 files changed, 7 insertions(+), 22 deletions(-) diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c index 5555b71ab19b..3fd1762d8916 100644 --- a/net/hsr/hsr_device.c +++ b/net/hsr/hsr_device.c @@ -232,9 +232,7 @@ static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, st= ruct net_device *dev) skb->dev =3D master->dev; skb_reset_mac_header(skb); skb_reset_mac_len(skb); - spin_lock_bh(&hsr->seqnr_lock); hsr_forward_skb(skb, master); - spin_unlock_bh(&hsr->seqnr_lock); } else { dev_core_stats_tx_dropped_inc(dev); dev_kfree_skb_any(skb); @@ -335,6 +333,7 @@ static void send_hsr_supervision_frame(struct hsr_port = *port, hsr_stag->sequence_nr =3D htons(hsr->sequence_nr); hsr->sequence_nr++; } + spin_unlock_bh(&hsr->seqnr_lock); =20 hsr_stag->tlv.HSR_TLV_type =3D type; /* HSRv0 has 6 unused bytes after the MAC */ @@ -356,14 +355,10 @@ static void send_hsr_supervision_frame(struct hsr_por= t *port, ether_addr_copy(hsr_sp->macaddress_A, hsr->macaddress_redbox); } =20 - if (skb_put_padto(skb, ETH_ZLEN)) { - spin_unlock_bh(&hsr->seqnr_lock); + if (skb_put_padto(skb, ETH_ZLEN)) return; - } =20 hsr_forward_skb(skb, port); - spin_unlock_bh(&hsr->seqnr_lock); - return; } =20 static void send_prp_supervision_frame(struct hsr_port *master, @@ -390,6 +385,7 @@ static void send_prp_supervision_frame(struct hsr_port = *master, spin_lock_bh(&hsr->seqnr_lock); hsr_stag->sequence_nr =3D htons(hsr->sup_sequence_nr); hsr->sup_sequence_nr++; + spin_unlock_bh(&hsr->seqnr_lock); hsr_stag->tlv.HSR_TLV_type =3D PRP_TLV_LIFE_CHECK_DD; hsr_stag->tlv.HSR_TLV_length =3D sizeof(struct hsr_sup_payload); =20 @@ -397,13 +393,10 @@ static void send_prp_supervision_frame(struct hsr_por= t *master, hsr_sp =3D skb_put(skb, sizeof(struct hsr_sup_payload)); ether_addr_copy(hsr_sp->macaddress_A, master->dev->dev_addr); =20 - if (skb_put_padto(skb, ETH_ZLEN)) { - spin_unlock_bh(&hsr->seqnr_lock); + if (skb_put_padto(skb, ETH_ZLEN)) return; - } =20 hsr_forward_skb(skb, master); - spin_unlock_bh(&hsr->seqnr_lock); } =20 /* Announce (supervision frame) timer function diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c index 0774981a65c1..8e4158a9b57c 100644 --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -621,9 +621,10 @@ static void handle_std_frame(struct sk_buff *skb, if (port->type =3D=3D HSR_PT_MASTER || port->type =3D=3D HSR_PT_INTERLINK) { /* Sequence nr for the master/interlink node */ - lockdep_assert_held(&hsr->seqnr_lock); + spin_lock_bh(&hsr->seqnr_lock); frame->sequence_nr =3D hsr->sequence_nr; hsr->sequence_nr++; + spin_unlock_bh(&hsr->seqnr_lock); } } =20 diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c index da06b21cdf51..0ca55d9323c5 100644 --- a/net/hsr/hsr_slave.c +++ b/net/hsr/hsr_slave.c @@ -73,16 +73,7 @@ static rx_handler_result_t hsr_handle_frame(struct sk_bu= ff **pskb) } skb_reset_mac_len(skb); =20 - /* Only the frames received over the interlink port will assign a - * sequence number and require synchronisation vs other sender. - */ - if (port->type =3D=3D HSR_PT_INTERLINK) { - spin_lock_bh(&hsr->seqnr_lock); - hsr_forward_skb(skb, port); - spin_unlock_bh(&hsr->seqnr_lock); - } else { - hsr_forward_skb(skb, port); - } + hsr_forward_skb(skb, port); =20 finish_consume: return RX_HANDLER_CONSUMED; --=20 2.43.0 From nobody Fri Oct 2 13:03:26 2026 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (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 00C353502A5 for ; Fri, 31 Jul 2026 09:02:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488555; cv=none; b=WefmqDQYPVOsnHW7sS+a2aze8Cg5OoZYM98i+3k2SCFwLjQQV93zEz1jemXMlg9T5MH2E64FL6mSzoOdmrBtWJCf5fvPtYU0WS+3+9twuMNwBneSdcc3F6UCmkLq7YGZ/lM0sDmJ9duOxXkHPJnnGS65Q7uQMFDARbISsdSPSnk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488555; c=relaxed/simple; bh=Gvo7dvsXJnKYRwaxoElTc0qa0PZfiQSj25oZnrC2+wc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sRky1d1LxnwPb33HKhAnyQBi536yKuzjEY/Wg1lQIPSQJlGKHIn8BSZ0rF8vDM7OjonyK7c9tq7owyvNHbe2FTMvr8qq29fclzgg8R9VfnMTOLtTx+QjFyJRQKtPiAWHvDzyWx9Up72FDbRqTDlenZRWvzOL7n84OsBt8yicvNI= 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=HzqJhvjN; arc=none smtp.client-ip=209.85.221.43 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="HzqJhvjN" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-47f502ff678so84870f8f.0 for ; Fri, 31 Jul 2026 02:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785488550; x=1786093350; 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:content-type; bh=xuWU9LZrmF4Dt9/ovolj0itekaMNh8PVn0wC7NLE19M=; b=HzqJhvjNJk3ll97EBG8FOXtKAYUKNB7KEqD5Dq4ckYwAmFZzp7nqSBzHbtiW5v+Qpu zfvh7Da65+9JYQ3GGvfkabiHpVaQJvEc20PBi4Z7+z8tzQ8RxQ/7oD6odBL0tKyjnh23 5Wwn1OVI33Y4rPk75xQFlFJcbCCIbcr1DtzWcjiMqFxJw6gHEyW+6uhZKlkLHmjHP7ft /xBwNd3eEx09mv4ZfMqIFO1a+66FqCfdmoc3zHmA0pJT5yrhqz0HyRBvouNTRYPgqrz6 xsiGxInEam8ggpdTxNaZml4ukd4zh2Gubk/HIKnnzIBG5JvGUMDqX9BplWfrKjGWUyYt pTlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785488550; x=1786093350; 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:content-type; bh=xuWU9LZrmF4Dt9/ovolj0itekaMNh8PVn0wC7NLE19M=; b=VxsA63lA+SQlgupuGQJ5i8GNTXYscmPhUHTXh3SsNsDnhKulgmrk/BjwSP9ckA3zMK G+CIBJ+Ay0to61Ytpaq7Puum6BuOoRfV+KndzwzppcSXB6sYOFZyEVCkRmBqg/VM3a1w qoIP34DVGwqmbJ+mxk5OAV2eB7tcoAyOzHKpa3kPkIN9ap25BEjz530RvIVtDtPQL8o9 UFsq05JVle31tRyZ83UFsj4qHmULgMyP0yIjrVrAa33RVWwRdZekCzRJweaaUb3gML2K MTMlNpTosbDZ0TikFFqGEUoL6HLDekdHO6KJ+b4bk8WuTLFRNWJrkd6Ye6jVRsDirr43 WZGQ== X-Forwarded-Encrypted: i=1; AHgh+Ro6h152gsjvUodEN0U7a5uG3B/HnYAplKa8LPfH+Y7l4G0guSj/LQP4rtRHKEXfmMm64iE6mDCQyMrzsJo=@vger.kernel.org X-Gm-Message-State: AOJu0YyXu98B5iuka3W/KLtLsx5L5aI36k+BJBkWFH9jjP3EeoRqPSHk IyQWlNASLQmiZTbPs3vSEs6txIovAeVRmOuLnNZ11Wo7GKAFtSUulOGH X-Gm-Gg: AR+sD11eDk/SMaNadJ8nsc/I20Cvgqluu7Dc+lIlw6ficsiQfUNXPq/7m+XlHoi1C9s EyePmbgLMuq8/hq4FQOpwmc26KVZ+6RGOI4RAUCJd6XDCQ9veRCrHrDCyg6BFtUn458wxRPdoDv oo9zZaP3O/ycN0pfLpGDaIwUY5PFY4lfSLGhw7GwkduSP78eNBU43YU5EwbSZHeA+4R0hgTz4U/ Di8ZRSHMM7IM/Rj6VI9+xbE++x2JbYKJy+GeCx9zOzaWx0XuYrMGQzQD0EL/mqB+WRw3b0HVgO+ CNI74KmISKjGn8F0ZQ/ROFEfszjEP46F3Sfc0XIEx30ZK7xlz1rvpfpezpNk2EGFgKK0z6jkIGM cD2GHFUGq4NSYDBUpbLhYN5NG0cZ/EYgkxPeKtacVN/6TZ+oY/kn0HOTwGeO/78slTB8/GhLmQL zo4Fm1Vts8pfWvJXsA4fBJ1vRnaB4F03f/Ov76Q/H4i78YOdZJxDcqnjvKS1A3PGitnho+5R75n P14DOaqXDKsN4eOFdUDmQ2dwBnL/7JSqqdSOwNtlIeOhvgxrz7rCXQP9XgSFUoDYvo8kUtJGsfD jL/ilTbQsyCtM86KsVh7c0hgRsTEcwn7 X-Received: by 2002:a05:6000:430b:b0:47f:9256:52c0 with SMTP id ffacd0b85a97d-47fd2b5498amr3276372f8f.3.1785488550061; Fri, 31 Jul 2026 02:02:30 -0700 (PDT) Received: from L-022584.energy.envision.com (dynamic-077-184-219-058.77.184.pool.telefonica.de. [77.184.219.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41d1a58sm2965051f8f.7.2026.07.31.02.02.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 02:02:29 -0700 (PDT) From: Xin Xie To: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, shuah@kernel.org, kees@kernel.org, petr.wozniak@gmail.com, qingfang.deng@linux.dev, fmaurer@redhat.com, luka.gejak@linux.dev, bigeasy@linutronix.de, xiaoliang.yang_1@nxp.com, skhawaja@google.com, stable@vger.kernel.org, Xin Xie Subject: [PATCH net v3 3/4] net: hsr: unfold GSO super-packets at the forward entry Date: Fri, 31 Jul 2026 11:02:22 +0200 Message-ID: <20260731090224.18-4-xiexinet@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260731090224.18-1-xiexinet@gmail.com> References: <20260731090224.18-1-xiexinet@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" HSR/PRP forward frames one by one: each wire frame gets its own tag and sequence number, and duplicate discard is per frame. A GSO super-packet reaching hsr_forward_skb() breaks that per-frame semantics: it would be tagged and forwarded as a single frame. Unfold such super-packets at the forward entry with the top-level GSO dispatch: __skb_gso_segment() initializes SKB_GSO_CB() and performs the L2->L3->L4 protocol dispatch (calling the low-level skb_segment() helper directly is not allowed here -- it reads SKB_GSO_CB(skb) state that only __skb_gso_segment() sets up). features =3D 0 requests full software segmentation; tx_path is selected by ingress port (master =3D locally generated TX, interlink =3D RX) to get the right checksum semantics. Each segment then runs through the existing per-frame path, which is split out as hsr_forward_skb_one() so that no GSO skb can reach it. Segmentation is only offered for the ingress roles whose frames are known to be plain Ethernet: the master (locally generated) and the interlink (SAN side, untagged). A super-packet received from a LAN slave may carry per-frame HSR tags or PRP RCT trailers that software segmentation cannot recover, and an already-tagged HSR/PRP super-packet violates per-frame wire semantics; both are rejected by ingress-port policy. (ETH_P_PRP identifies supervision traffic only; a PRP data frame keeps its payload EtherType, so RCT carriage cannot be tested by protocol.) Also drop NETIF_F_GSO_MASK from the HSR master's hw_features so locally generated traffic is segmented before reaching the forward path whenever possible. Patch 2 (seqnr_lock shrink) is a latency/critical-section prerequisite for this change; their automatic stable selection is limited to 7.0 and newer. Older stable branches require an adapted backport. Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamle= ss Redundancy protocol (HSRv0)") Cc: # 7.0.x Signed-off-by: Xin Xie Reviewed-by: Ali Ahmet Memis Tested-by: Ali Ahmet Memis --- net/hsr/hsr_device.c | 2 +- net/hsr/hsr_forward.c | 50 ++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 50 insertions(+), 2 deletions(-) diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c index 3fd1762d8916..248cbb142e21 100644 --- a/net/hsr/hsr_device.c +++ b/net/hsr/hsr_device.c @@ -652,7 +652,7 @@ void hsr_dev_setup(struct net_device *dev) dev->needs_free_netdev =3D true; =20 dev->hw_features =3D NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_HIGHDMA | - NETIF_F_GSO_MASK | NETIF_F_HW_CSUM | + NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_FILTER; =20 diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c index 8e4158a9b57c..3fcdbac49c59 100644 --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -12,6 +12,7 @@ #include #include #include +#include #include "hsr_main.h" #include "hsr_framereg.h" =20 @@ -732,7 +733,7 @@ static int fill_frame_info(struct hsr_frame_info *frame, } =20 /* Must be called holding rcu read lock (because of the port parameter) */ -void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port) +static void hsr_forward_skb_one(struct sk_buff *skb, struct hsr_port *port) { struct hsr_frame_info frame; =20 @@ -761,3 +762,50 @@ void hsr_forward_skb(struct sk_buff *skb, struct hsr_p= ort *port) port->dev->stats.tx_dropped++; kfree_skb(skb); } + +/* GSO fan-out funnel: unfold super-packets before per-frame processing so + * each wire frame gets its own HSR/PRP tag and sequence number. + */ +void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port) +{ + struct sk_buff *segs, *next; + + if (likely(!skb_is_gso(skb))) { + hsr_forward_skb_one(skb, port); + return; + } + + /* Unfold only plain-Ethernet GSO super-packets: locally generated + * on the master, or arriving untagged from the SAN side on the + * interlink. A super-packet from a LAN slave may carry per-frame + * HSR tags / PRP RCT trailers that software segmentation cannot + * recover; an already-tagged HSR/PRP super-packet violates + * per-frame wire semantics. Drop both. + */ + if (port->type !=3D HSR_PT_MASTER && port->type !=3D HSR_PT_INTERLINK) + goto drop_gso; + if (skb->protocol =3D=3D htons(ETH_P_HSR) || + skb->protocol =3D=3D htons(ETH_P_PRP)) + goto drop_gso; + + /* features =3D 0: request full software segmentation. tx_path is true + * only for locally generated traffic on the master; ingress from + * the interlink follows RX checksum semantics. + */ + segs =3D __skb_gso_segment(skb, 0, port->type =3D=3D HSR_PT_MASTER); + if (IS_ERR(segs) || unlikely(!segs)) + goto drop_gso; + + consume_skb(skb); + while (segs) { + next =3D segs->next; + segs->next =3D NULL; + hsr_forward_skb_one(segs, port); + segs =3D next; + } + return; + +drop_gso: + port->dev->stats.tx_dropped++; + kfree_skb(skb); +} --=20 2.43.0 From nobody Fri Oct 2 13:03:26 2026 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (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 B259837E2FE for ; Fri, 31 Jul 2026 09:02:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488556; cv=none; b=iDwld3W3NEmlIMcGFSz1SKF9ooNaOQM2/MiIztlFYHOqCw+nN/6lxtwWAenHfrj2fczI3fCoqU+RRn4I/yvq/WTHGSJgA4K252zAXfbaCnaNfl2BUy4sG6oqlaOf29mUOyPSs9E224dK2JpRzcYO1Q7/klojwzvdfzGVU4AC7G0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785488556; c=relaxed/simple; bh=2WmkWOQUFedXlAeRWs1rCF6F6EEDQs0fH4tiKIsLUIg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=P4Q93s1ruc2Q7Cdz3uLK9eN5a+BwrSJsNzmOZzckImAfYVHz9WOpUFySe0Z8sdCAd/NrP61R0Diyar/P0htldy/dv+UGVF327kaktJGutrYqIp2i4cy222+raacpfeiEChRM1hU2hESBnLwBroQWbz31lcn7bqBJa0Ek4gOtl8w= 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=WJIOG83L; arc=none smtp.client-ip=209.85.218.45 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="WJIOG83L" Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-c15b51ba80dso6946966b.2 for ; Fri, 31 Jul 2026 02:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785488552; x=1786093352; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=0UMcq6cX22VzKYCYw8MtlB1VO1OK1eK2jVGQy/sBkLM=; b=WJIOG83LzDVDx/FobzqTDDTkzBk65Mky9KryDU39TuCT6hM6ENg/dIor5uvxDNkwgt MudusRxXIaxAnqkB9HuPjf19B1Y7NfmEC5XIWGyuTG5w9BGe0722ZfTdFHXsPr3queLY WwybDusesw0DQJyILd25+t2RqYMD9foRJ5Xzo4fhU2rFNtwzWgDAuHevasc8jO69CfpG Ec+SuVZMK51NXVyQQxPCSKG4AgU4MY3kwK0Fm4WHeSxh6EHuF0YgpcPkd3PVDv7duop6 CgZFQ/5DAo0fQRIyja9T8G7udDb1xhuyUMldie6zlZVVClmJGCWq96bq2H0xR/DBANCx O//g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785488552; x=1786093352; h=content-transfer-encoding:content-type: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 :content-type; bh=0UMcq6cX22VzKYCYw8MtlB1VO1OK1eK2jVGQy/sBkLM=; b=RVVYdfp7SB14qJ0fVyUqDzWggskqGmTEmK3hqS+ggH8fxHg22xgQWd7r43fR2B9/lu n9wjZ8wn7kFrF8no/yZOc24Ue7VPbsfZTnkl+aHAXqs+qRCeh6O3soVVWplhX4446pZd Q8WnnDvmSxryA35p0YtqSv2I3QHWRbG1ZZ5yyuiY8T1ESMQ28KNa2BZqvT4GmrKyDTGP +wEAvnMcdpB5xjk/fxJBJv1aDvRVwHj0vffhFjGFU4Iamoaq45PzNSYDGBoSinyo+CKM XcxRM66Txhmh4G+7b4GNV+P8EPlUj2hpPlTcpAHRtkJEYtwKHAMKCiQseRJPTD3rJ53t 3fGg== X-Forwarded-Encrypted: i=1; AHgh+Rp/libuBtDaztOzc0wTd9Nqff8FVqTtcqVYBZvfx+2A6eGGVAiccNHv1MLnJMQzpMDK6nzVOgmj7fke2M8=@vger.kernel.org X-Gm-Message-State: AOJu0Yxllz+XHBVBZn9FwqkzDeAc11a9bVRiGlZmEcaM1ZnNCjY++U13 goDNh8DccvgE/2lSREBBNNOoI6tWUr3jLBx/KaVl+R+xVbdd6tyNifG2 X-Gm-Gg: AR+sD12m1dp2rt5LGYjqGgH5ickdYnGokBtr2UdsT5qbAAoUaWPfQVg/fvgioDXtzDF LwG+9NztzjfHeomQq/98xAVgUfI332CmvuU6/yR3SdaDgGb8u4fNs9TDJL+PKdOnANQc9pNZe1+ QqWvSlRk6m5r3CglAkXir1xqn5SWqSj7gzY2g3XzVuYOBldP4oi08L/a+oM7ZGSXGLhoninADCr hH+jsfXFIMVXn24JHjpi6NDKl5AXRdvvJFQvC8iUgkE00J6dwK+LbygeJmV8vebUlVcDzCNNqzy 0PbMiEmHz8Y19MRRUegZ6o5BNFKD6RlQM5U3cHSW+wbtTeDohNWGawgRpo8ZOj8fAg3PCTrbMvY 8HRdDcncOTxrX3f/x3lVwQ6zW2vJsM3xJhS6f9T/qo9PHrJZt82Zgk09fntP8tFDddB5q4tnS/B 51onO+uybFbrHvV83TkOKWoTMRTpsSseDh3S9bZ0JvYon6D+9orGweX/Z8P2c0HBdSwQTZ/kYoB 4ReJb+rMpFY8QKvUcfvKtOrBMgf2MDW0ovkjx6gd9lpp7+VB7g/dZ6Sf9xyIlWU4Jxp7s6iD1rM gRlC3g1BwEA/xBdXnnRasA== X-Received: by 2002:a17:907:ea8c:b0:c12:6db4:4bf4 with SMTP id a640c23a62f3a-c1fd1cecb3fmr87595766b.0.1785488551469; Fri, 31 Jul 2026 02:02:31 -0700 (PDT) Received: from L-022584.energy.envision.com (dynamic-077-184-219-058.77.184.pool.telefonica.de. [77.184.219.58]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd41d1a58sm2965051f8f.7.2026.07.31.02.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Jul 2026 02:02:30 -0700 (PDT) From: Xin Xie To: netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, andrew+netdev@lunn.ch, shuah@kernel.org, kees@kernel.org, petr.wozniak@gmail.com, qingfang.deng@linux.dev, fmaurer@redhat.com, luka.gejak@linux.dev, bigeasy@linutronix.de, xiaoliang.yang_1@nxp.com, skhawaja@google.com, stable@vger.kernel.org, Xin Xie Subject: [PATCH net v3 4/4] selftests: net: hsr: add GRO super-packet forwarding test Date: Fri, 31 Jul 2026 11:02:23 +0200 Message-ID: <20260731090224.18-5-xiexinet@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260731090224.18-1-xiexinet@gmail.com> References: <20260731090224.18-1-xiexinet@gmail.com> 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 Add a test exercising the HSR forward path with GSO super-packets: a TSO-enabled SAN behind the interlink streams TCP through an HSR DUT to a peer node. The test verifies that: * enslaved devices have GRO and HW-GRO disabled automatically, * the HSR master does not advertise GSO/TSO features (including tx-tcp6/udp/gso-list, to catch future hw_features leaks), * super-packets really leave the SAN (TX average frame size above a fixed threshold) while bulk output on the DUT's LAN legs stays at per-frame size =E2=80=94 aggregate counter evidence that GSO enters the forward path and is unfolded at the forward entry. Zero TCP retransmits is reported as a secondary health signal. The one-shot iperf3 server lives in a private mktemp -d workdir (mode 0700): its exact PID is retained only after numeric, alive, comm=3D=3Diperf3 and netns-membership checks, its real exit status is propagated through an rc file, and cleanup kills by exact PID with a bounded wrapper reap plus a namespace-scoped iperf3 sweep. Server startup failure, client failure and a never-published PID are all bounded exits with no process or directory leaks. Environments whose iproute2 lacks the HSR interlink syntax are skipped with ksft_skip. Without this series the feature checks fail, and on drivers that hand GRO super-packets to the HSR receive path the stream degrades or stalls. Signed-off-by: Xin Xie Reviewed-by: Ali Ahmet Memis Tested-by: Ali Ahmet Memis --- tools/testing/selftests/net/hsr/Makefile | 1 + .../selftests/net/hsr/hsr_gro_superpacket.sh | 462 ++++++++++++++++++ 2 files changed, 463 insertions(+) create mode 100755 tools/testing/selftests/net/hsr/hsr_gro_superpacket.sh diff --git a/tools/testing/selftests/net/hsr/Makefile b/tools/testing/selft= ests/net/hsr/Makefile index 31fb9326cf53..0d105476e7c5 100644 --- a/tools/testing/selftests/net/hsr/Makefile +++ b/tools/testing/selftests/net/hsr/Makefile @@ -3,6 +3,7 @@ top_srcdir =3D ../../../../.. =20 TEST_PROGS :=3D \ + hsr_gro_superpacket.sh \ hsr_ping.sh \ hsr_redbox.sh \ link_faults.sh \ diff --git a/tools/testing/selftests/net/hsr/hsr_gro_superpacket.sh b/tools= /testing/selftests/net/hsr/hsr_gro_superpacket.sh new file mode 100755 index 000000000000..288de3a60b89 --- /dev/null +++ b/tools/testing/selftests/net/hsr/hsr_gro_superpacket.sh @@ -0,0 +1,462 @@ +#!/bin/bash +# SPDX-License-Identifier: GPL-2.0 +# +# Test HSR handling of GRO/GSO super-packets: +# +# 1. Enslaving a device to an HSR master disables GRO on it +# (dev_disable_gro()). +# 2. The HSR master does not advertise GSO/TSO features. +# 3. A TCP stream from a TSO-enabled SAN (which therefore emits GSO +# super-packets) is unfolded at the HSR forward entry. Evidence: +# interface-counter deltas show super-packet-sized frames leaving +# the SAN and per-frame-sized traffic leaving the DUT's LAN ports. +# +# Topology (100.64.0.0/24): +# +# ns_san ns_dut ns_peer +# +-----------+ interlink +---------------+ LAN A/B +-----------+ +# | s0 [0.1] |-------------| d_il hsr0 |-----------| hsr1 [0.3]| +# +-----------+ | d_a / d_b | | p_a / p_b | +# +---------------+ +-----------+ +# +# SAN traffic reaches ns_peer only through hsr0's forward path +# (interlink RX -> LAN A/B TX), so every SAN frame is tagged and +# forwarded by the DUT. + +source ./hsr_common.sh + +san_ip=3D"100.64.0.1" +peer_ip=3D"100.64.0.3" + +# Aggregate counter thresholds for the stream test (bytes/packets): +# SAN_AVG_MIN proves GSO super-packets left the SAN; LAN_AVG_MAX is a +# guard with margin, not the protocol maximum (see do_tso_stream_test). +SAN_AVG_MIN=3D2048 +LAN_AVG_MAX=3D1514 + +iperf_pid=3D"" +server_wrapper=3D"" +workdir=3D"" +pidfile=3D"" +rcfile=3D"" + +cleanup() +{ + # exact-PID kill only after RE-validating identity (guards against + # PID reuse between publication and cleanup) + if [ -n "${iperf_pid}" ] && valid_server_pid "${iperf_pid}"; then + kill "${iperf_pid}" 2>/dev/null + fi + iperf_pid=3D"" + if [ -n "${server_wrapper}" ]; then + # the wrapper waits on the server; reap it with a 5s bound so a + # live-but-unpublished server can never hang cleanup + for _ in $(seq 1 50); do + kill -0 "${server_wrapper}" 2>/dev/null || break + sleep 0.1 + done + kill "${server_wrapper}" 2>/dev/null + wait "${server_wrapper}" 2>/dev/null + server_wrapper=3D"" + fi + # last resort, namespace-scoped only: TERM the iperf3 processes that + # actually live in the peer netns, poll for bounded exit, then + # SIGKILL any survivor before touching the namespace name. A blind + # pkill would scan the host PID space and hit unrelated tests. + local _p _still + for _p in $(ip netns pids "$ns_peer" 2>/dev/null); do + if is_iperf3_pid "$_p"; then + kill "$_p" 2>/dev/null + fi + done + for _ in $(seq 1 50); do + _still=3D0 + for _p in $(ip netns pids "$ns_peer" 2>/dev/null); do + if is_iperf3_pid "$_p"; then + _still=3D1 + break + fi + done + [ "$_still" -eq 0 ] && break + sleep 0.1 + done + for _p in $(ip netns pids "$ns_peer" 2>/dev/null); do + if is_iperf3_pid "$_p"; then + kill -9 "$_p" 2>/dev/null + fi + done + # remove only the known non-empty private directory + if [ -n "${workdir}" ] && [ -d "${workdir}" ]; then + rm -rf "${workdir}" + fi + workdir=3D"" + pidfile=3D"" + rcfile=3D"" + cleanup_all_ns +} + +trap cleanup EXIT + +check_tool() +{ + if ! command -v "$1" > /dev/null 2>&1; then + echo "SKIP: Could not run test without $1" + exit $ksft_skip + fi +} + +nsx() +{ + ip netns exec "$1" bash -c "$2" +} + +is_iperf3_pid() +{ + [ "$(cat /proc/"$1"/comm 2>/dev/null)" =3D "iperf3" ] +} + +# Decimal-counter validation for the snapshot blocks: every value must +# be a plain decimal number. A parse failure in read_tx_counters yields +# empty/garbled fields, which this check turns into an immediate FAIL. +valid_decimals() +{ + local v + + for v in "$@"; do + [[ "$v" =3D~ ^[0-9]+$ ]] || return 1 + done + return 0 +} + +setup_topo() +{ + setup_ns ns_dut ns_san ns_peer || exit $? + + ip link add d_a netns "$ns_dut" type veth peer name p_a netns "$ns_peer" + ip link add d_b netns "$ns_dut" type veth peer name p_b netns "$ns_peer" + ip link add d_il netns "$ns_dut" type veth peer name s0 netns "$ns_san" + + # HSR tags add 6 bytes per frame; give the LAN legs headroom. + for iface in d_a d_b; do + nsx "$ns_dut" "ip link set $iface mtu 1600; \ + ip link set $iface up" + done + for iface in p_a p_b; do + nsx "$ns_peer" "ip link set $iface mtu 1600; \ + ip link set $iface up" + done + + nsx "$ns_dut" "ip link set d_il up" + nsx "$ns_san" "ip link set s0 up; ip addr add $san_ip/24 dev s0" + + nsx "$ns_dut" "ip link add hsr0 type hsr \ + slave1 d_a slave2 d_b interlink d_il proto 0; \ + ip link set hsr0 up" + nsx "$ns_peer" "ip link add hsr1 type hsr \ + slave1 p_a slave2 p_b proto 0; \ + ip link set hsr1 up; ip addr add $peer_ip/24 dev hsr1" + + # Let the nodes see each other's supervision frames. + sleep 2 +} + +check_feature() +{ + local ns=3D"$1" + local iface=3D"$2" + local feature=3D"$3" + local want=3D"$4" + + if nsx "$ns" "ethtool -k $iface" | grep -q "^$feature: $want"; then + echo "INFO: $ns/$iface $feature is $want [ OK ]" + else + echo "FAIL: $ns/$iface $feature is not $want" 1>&2 + ret=3D1 + fi +} + +# Off-or-absent variant: fails only when the feature is present AND on, +# so devices that simply do not list the feature do not fail it. +check_feature_not_on() +{ + local ns=3D"$1" + local iface=3D"$2" + local feature=3D"$3" + + if nsx "$ns" "ethtool -k $iface" | grep -q "^$feature: on"; then + echo "FAIL: $ns/$iface $feature is on" 1>&2 + ret=3D1 + else + echo "INFO: $ns/$iface $feature not on [ OK ]" + fi +} + +do_gro_feature_checks() +{ + echo "INFO: Checking that enslavement disabled GRO." + check_feature "$ns_dut" d_a generic-receive-offload off + check_feature "$ns_dut" d_b generic-receive-offload off + check_feature "$ns_dut" d_il generic-receive-offload off + stop_if_error "GRO not disabled on enslaved devices." + + echo "INFO: Checking that enslavement disabled HW-GRO." + check_feature "$ns_dut" d_a rx-gro-hw off + check_feature "$ns_dut" d_b rx-gro-hw off + check_feature "$ns_dut" d_il rx-gro-hw off + stop_if_error "HW-GRO not disabled on enslaved devices." + + echo "INFO: Checking that the HSR master does not advertise GSO/TSO." + check_feature "$ns_dut" hsr0 generic-segmentation-offload off + check_feature "$ns_dut" hsr0 tcp-segmentation-offload off + check_feature_not_on "$ns_dut" hsr0 tx-tcp6-segmentation + check_feature_not_on "$ns_dut" hsr0 tx-udp-segmentation + check_feature_not_on "$ns_dut" hsr0 tx-gso-list + stop_if_error "HSR master still advertises GSO-family features." +} + +alloc_workdir() +{ + # Allocated only here, long after the initial topology cleanup, so + # cleanup() at setup_topo() time can never remove it. mktemp failure + # is a hard test failure. + workdir=3D$(mktemp -d /tmp/hsr_gro_test.XXXXXX) || { + echo "FAIL: mktemp -d failed" 1>&2 + exit 1 + } + chmod 700 "${workdir}" + pidfile=3D"${workdir}/iperf.pid" + rcfile=3D"${workdir}/iperf.rc" +} + +# Numeric, alive, comm =3D=3D iperf3, and really owned by the peer netns. +valid_server_pid() +{ + local p=3D"$1" + + [[ "$p" =3D~ ^[0-9]+$ ]] || return 1 + kill -0 "$p" 2>/dev/null || return 1 + [ "$(cat /proc/"$p"/comm 2>/dev/null)" =3D "iperf3" ] || return 1 + ip netns pids "$ns_peer" 2>/dev/null | grep -qx "$p" +} + +start_iperf_server() +{ + local candidate_pid + + # One-shot server, no -D: the wrapper records its exact PID and its + # real exit status (netns shares the PID namespace and the host fs). + alloc_workdir + ( nsx "$ns_peer" "iperf3 -s -1 > /dev/null 2>&1 & \ + echo \$! > ${pidfile}; \ + wait \$!; \ + echo \$? > ${rcfile}" ) & + server_wrapper=3D$! + # the wrapper writes the pidfile asynchronously; wait for it to + # appear instead of racing the read + for _ in $(seq 1 50); do + [ -s "${pidfile}" ] && break + sleep 0.1 + done + if [ ! -s "${pidfile}" ]; then + echo "FAIL: iperf3 server did not publish a pid" \ + "(no pidfile)" 1>&2 + ret=3D1 + return 1 + fi + candidate_pid=3D$(<"${pidfile}") + if ! valid_server_pid "${candidate_pid}"; then + echo "FAIL: iperf3 server pid '${candidate_pid}'" \ + "failed validation" 1>&2 + ret=3D1 + return 1 + fi + # publish only after full validation + iperf_pid=3D"${candidate_pid}" + sleep 1 + return 0 +} + +# Print " " for exactly one TX record of ns/dev; anything +# else (missing, duplicated, non-numeric) is a hard FAIL. +read_tx_counters() +{ + local ns=3D"$1" dev=3D"$2" + local out cnt + + out=3D$(nsx "$ns" "ip -s link show $dev" | \ + awk '/^ +TX:/{getline; print $1, $2}') + cnt=3D$(echo "$out" | grep -c '^[0-9]* [0-9]*$') + if [ "$cnt" -ne 1 ]; then + echo "FAIL: cannot parse TX counters of $ns/$dev" \ + "(records=3D$cnt)" 1>&2 + return 1 + fi + echo "$out" + return 0 +} + +eval_counter_delta() +{ + local name=3D"$1" b0=3D"$2" p0=3D"$3" b1=3D"$4" p1=3D"$5" op=3D"$6" limit= =3D"$7" + local bd pd + + if ! [[ "$b0" =3D~ ^[0-9]+$ && "$b1" =3D~ ^[0-9]+$ && \ + "$p0" =3D~ ^[0-9]+$ && "$p1" =3D~ ^[0-9]+$ ]]; then + echo "FAIL: non-numeric counter input for $name" 1>&2 + ret=3D1 + return 1 + fi + bd=3D$((b1 - b0)) + pd=3D$((p1 - p0)) + if [ "$bd" -lt 0 ] || [ "$pd" -le 0 ]; then + echo "FAIL: counter delta invalid for $name" \ + "(bytes=3D$bd pkts=3D$pd)" 1>&2 + ret=3D1 + return 1 + fi + if [ "$op" =3D "gt" ]; then + if [ "$bd" -le $((pd * limit)) ]; then + echo "FAIL: $name bytes/packets $bd/$pd <=3D $limit" 1>&2 + ret=3D1 + return 1 + fi + else + if [ "$bd" -gt $((pd * limit)) ]; then + echo "FAIL: $name bytes/packets $bd/$pd > $limit" 1>&2 + ret=3D1 + return 1 + fi + fi + echo "INFO: $name counter delta bytes=3D$bd packets=3D$pd" \ + "(op $op limit $limit) [ OK ]" + return 0 +} + +do_tso_stream_test() +{ + local out sender_retr server_rc + local san_b0 san_p0 san_b1 san_p1 + local a_b0 a_p0 a_b1 a_p1 b_b0 b_p0 b_b1 b_p1 + + echo "INFO: Enabling TSO/GSO on the SAN interface." + nsx "$ns_san" "ethtool -K s0 tso on gso on" + check_feature "$ns_san" s0 tcp-segmentation-offload on + stop_if_error "Could not enable TSO on the SAN interface." + + echo "INFO: Running 10s TCP stream SAN -> peer through the HSR DUT." + start_iperf_server || return + + # Counter snapshots around the stream window. The SAN-side average + # must exceed SAN_AVG_MIN (aggregate proof that GSO super-packets + # really left the SAN); each DUT LAN leg must stay under LAN_AVG_MAX + # (aggregate proof that bulk output was segmented per-frame). These + # are aggregate discriminators, not a per-frame maximum proof. + san_b0=3D0; san_p0=3D0; a_b0=3D0; a_p0=3D0; b_b0=3D0; b_p0=3D0 + read -r san_b0 san_p0 <&2 + ret=3D1 + return 1 + fi + + # rate-capped: the PRIMARY discriminator is the counter inequality + # above, not max throughput; retransmits are informational only. + # Uncapped runs flap at VM/CI edge rates without indicating a + # functional problem. + if ! out=3D$(nsx "$ns_san" "timeout 60 iperf3 -c $peer_ip -M 1446 \ + -b 2G -t 10" 2>&1); then + echo "FAIL: iperf3 client failed:" 1>&2 + echo "$out" 1>&2 + ret=3D1 + return + fi + + read -r san_b1 san_p1 <&2 + ret=3D1 + return 1 + fi + + eval_counter_delta "SAN s0 TX" "$san_b0" "$san_p0" "$san_b1" "$san_p1" \ + gt "$SAN_AVG_MIN" + eval_counter_delta "DUT d_a TX" "$a_b0" "$a_p0" "$a_b1" "$a_p1" \ + le "$LAN_AVG_MAX" + eval_counter_delta "DUT d_b TX" "$b_b0" "$b_p0" "$b_b1" "$b_p1" \ + le "$LAN_AVG_MAX" + [ "${ret:-0}" -eq 0 ] || return + + # success path: the one-shot server exits by itself; reap the + # wrapper, then REQUIRE the rcfile with the server's real status + wait "${server_wrapper}" + server_wrapper=3D"" + if [ ! -s "${rcfile}" ]; then + echo "FAIL: iperf3 server status file missing (${rcfile})" 1>&2 + ret=3D1 + return + fi + server_rc=3D$(cat "${rcfile}") + if ! [[ "$server_rc" =3D~ ^[0-9]+$ ]] || [ "$server_rc" -ne 0 ]; then + echo "FAIL: iperf3 server exited with rc=3D'${server_rc}'" 1>&2 + ret=3D1 + return + fi + iperf_pid=3D"" + + # secondary health signal only: anchored, single-match, numeric =E2=80=94 + # any parse anomaly is a loud FAIL, but the value itself no longer + # gates (the counter inequalities above are the primary evidence). + sender_retr=3D$(echo "$out" | awk '/sec .* sender$/ {print $(NF-1)}') + if [ "$(echo "$sender_retr" | grep -Ec '^[0-9]+$')" -ne 1 ]; then + echo "FAIL: cannot parse sender retransmits reliably" 1>&2 + echo "$out" 1>&2 + ret=3D1 + return + fi + echo "INFO: TCP stream done;" \ + "sender retransmits=3D$sender_retr (secondary signal)" + echo "$out" | grep -E "sender|receiver" +} + +check_prerequisites +check_tool ethtool +check_tool iperf3 +check_tool timeout + +# iproute2 must know the HSR interlink syntax. +if ! ip link help hsr 2>&1 | grep -qi interlink; then + echo "SKIP: iproute2 has no HSR interlink support" + exit $ksft_skip +fi + +setup_topo + +echo "INFO: Initial validation ping (SAN -> peer through the DUT)." +do_ping "$ns_san" "$peer_ip" +stop_if_error "Initial validation failed." + +do_gro_feature_checks +do_tso_stream_test +stop_if_error "GSO super-packet stream test failed." + +echo "INFO: All good." +cleanup +exit $ret --=20 2.43.0