From: Xin Xie <xiexinet@gmail.com>
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, sdf.kernel@gmail.com,
Xin Xie <xiexinet@gmail.com>
Subject: [PATCH net v5 0/4] net: hsr: fix GRO/GSO super-packet handling
Date: Fri, 7 Aug 2026 16:07:46 +0200 [thread overview]
Message-ID: <20260807140751.1351-1-xiexinet@gmail.com> (raw)
HSR/PRP requires per-wire-frame tags/RCTs and sequence numbers, and
duplicate discard is per frame. RX GRO and TX GSO can present
multiple frames as one skb and violate that assumption: a super-skb
is either rejected by a constrained lower device, or forwarded
without valid per-frame trailers and sequence numbers.
Patch 1 adds netif_disable_gro()/dev_disable_gro() and disables
GRO and GRO_HW on lower devices at HSR/PRP enslavement time,
mirroring the existing LRO treatment. Disabling is explicitly
best-effort: a later privileged override can re-enable GRO, and
devices with fixed-on GRO_HW (for example a virtio-net device
negotiating guest TSO without VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)
cannot be forced off, so enslavement succeeds whether or not the
feature could be cleared.
Patch 2 shrinks hsr->seqnr_lock from whole hsr_forward_skb() calls
to the sequence counter updates, so the segmentation work of
patch 3 never runs under the global sequence lock. The outer lock
also incidentally serialized the tx statistics updates in
hsr_forward_skb(); those now use the atomic DEV_STATS_* helpers.
Patch 3 unfolds GSO super-packets at the forward entry with the
top-level GSO dispatch (__skb_gso_segment()), so each wire frame
gets its own tag/RCT and sequence number. Admission is decided by a
content-based classifier, not by the ingress port: plain-Ethernet
aggregates are segmented on every ingress role (master, interlink,
and LAN slaves), while aggregates whose effective protocol is
ETH_P_HSR or ETH_P_PRP carry per-frame trailers that software
segmentation cannot reconstruct and are dropped. The classifier
unwraps accelerated VLAN and one in-band VLAN level, and treats
NETIF_F_HW_HSR_TAG_RM lowers as plain by construction. The
trailer-free premise of the plain-aggregate path is proven for
in-tree software GRO: its IPv4 and IPv6 length checks reject frames
with trailing bytes beyond the L3 length, so an RCT-bearing PRP
frame is not merged. Device-specific fixed-on GRO_HW output is not
claimed to be completely covered. Locally destined segments are
delivered to the host; the rest are forwarded per frame.
Patch 4 adds a kselftest covering the series, including a LAN-slave
plain-GSO regression: a plain SAN aggregate entering a PRP LAN slave
must be segmented, with local delivery and per-frame arrival proven
by independent counter oracles.
Patch 1 is a safe, partial, best-effort mitigation and is
independently stable-selectable; patch 3, named by subject in its
message, is the fallback for plain, trailer-free GSO aggregates.
Patch 3 depends on patch 2, and patches 2 and 3 are selected for
stable only on 7.0 and newer, where sparse-bitmap duplicate discard
accepts out-of-order arrival. Older branches need adapted backports.
Validation:
* the v5 kernel builds cleanly;
* LAN-slave plain-GSO regression: the same frozen script fails on
the v4 kernel (the early slave-port drop collapses the stream into
retransmit-only single segments) and passes on the v5 kernel:
aggregates arrive at the PRP master and are delivered per-frame;
* fixed-on GRO_HW: with a virtio guest negotiating TSO without
VIRTIO_NET_F_CTRL_GUEST_OFFLOADS (rx-gro-hw on [fixed]), HSR setup
succeeds on both kernels; the v4 kernel emits
"failed to disable GRO!" and the v5 kernel does not;
* the interlink super-packet test and hsr_ping, hsr_redbox,
link_faults and prp_ping all pass;
* the series applies cleanly with plain git am on current net.
Note on the contest report: this series conflicts with our own PRP
RedBox support now merged in net-next
(https://lore.kernel.org/netdev/20260717201457.54-1-xiexinet@gmail.com/).
On current net it applies cleanly (re-verified by a full-series
git am). For net-next the conflict is confined to two sites:
1. net/hsr/hsr_device.c, send_prp_supervision_frame(): net-next
added the PRP RedBox Type-30 TLV and EOT construction where
patch 2/4 shrinks the seqnr_lock critical section. Resolution:
keep the lock release immediately after the sup_sequence_nr
update (as in this patch), build the whole TLV chain (LifeCheck
payload, Type-30 RedBox-MAC TLV, EOT) unlocked, and drop the
two stale unlocks from the padding-error and normal-exit paths.
2. tools/testing/selftests/net/hsr/Makefile: insert
hsr_gro_superpacket.sh at its sorted position.
This resolution was applied and validated on the previous net-next
(2fbade662450): the composed tree builds cleanly and
hsr_prp_redbox.sh passes on the composed kernel.
---
Changes in v5:
Both v4 Sashiko reports (NIPA and Gemini) were reviewed in full.
The two blocking findings are the patch 1 and patch 3 changes below;
v5 also addresses the server-wait and message findings. The remaining
reports concern pre-existing issues, intentional behavior, disproven
claims, or non-blocking test/documentation suggestions.
- Patch 3: a plain GSO aggregate arriving on a LAN slave is no
longer dropped. Admission now uses a content-based,
VLAN/offload-aware classifier (hsr_gso_effective_proto()): plain
aggregates are segmented on every ingress role, restoring local
delivery and valid forwarding; only aggregates whose effective
protocol is ETH_P_HSR or ETH_P_PRP are dropped as unrecoverable.
- Patch 1: the netdev_WARN() in netif_disable_gro() is removed.
Devices with fixed-on GRO_HW (for example virtio-net guests
without VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) no longer splat on
ordinary HSR setup, and enslavement succeeds whether or not GRO
could be disabled. The commit message states the best-effort
contract and names patch 3 as the fallback
for plain, trailer-free GSO aggregates; Ali's Reviewed-by
and Tested-by from the v3 thread are not carried since the payload
changed.
- Patch 4: adds the LAN-slave plain-GSO regression and bounds the
iperf3 server wait.
- Patch 2 is payload- and message-identical to v4.
Previous postings (newest first):
v4: https://lore.kernel.org/netdev/20260803222211.877-1-xiexinet@gmail.com/
v3: https://lore.kernel.org/netdev/20260731090224.18-1-xiexinet@gmail.com/
v2: https://lore.kernel.org/netdev/20260724161253.79-1-xiexinet@gmail.com/
v1: https://lore.kernel.org/netdev/20260722171836.196-1-xiexinet@gmail.com/
Xin Xie (4):
net: hsr: fix packet drops caused by GRO superpackets
net: hsr: shrink seqnr_lock to sequence counter updates
net: hsr: unfold GSO super-packets at the forward entry
selftests: net: hsr: cover GSO super-packets on PRP slave ingress
include/linux/netdevice.h | 2 +
net/core/dev.c | 15 +
net/core/dev_api.c | 21 +
net/hsr/hsr_device.c | 17 +-
net/hsr/hsr_forward.c | 111 ++-
net/hsr/hsr_slave.c | 16 +-
tools/testing/selftests/net/hsr/Makefile | 1 +
.../selftests/net/hsr/hsr_gro_superpacket.sh | 631 ++++++++++++++++++
8 files changed, 787 insertions(+), 27 deletions(-)
create mode 100755 tools/testing/selftests/net/hsr/hsr_gro_superpacket.sh
--
2.43.0
next reply other threads:[~2026-08-07 14:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 14:07 Xin Xie [this message]
2026-08-07 14:07 ` [PATCH net v5 1/4] net: hsr: fix packet drops caused by GRO superpackets Xin Xie
2026-08-07 14:07 ` [PATCH net v5 2/4] net: hsr: shrink seqnr_lock to sequence counter updates Xin Xie
2026-08-07 14:07 ` [PATCH net v5 3/4] net: hsr: unfold GSO super-packets at the forward entry Xin Xie
2026-08-07 14:07 ` [PATCH net v5 4/4] selftests: net: hsr: cover GSO super-packets on PRP slave ingress Xin Xie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260807140751.1351-1-xiexinet@gmail.com \
--to=xiexinet@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fmaurer@redhat.com \
--cc=horms@kernel.org \
--cc=kees@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luka.gejak@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petr.wozniak@gmail.com \
--cc=qingfang.deng@linux.dev \
--cc=sdf.kernel@gmail.com \
--cc=shuah@kernel.org \
--cc=skhawaja@google.com \
--cc=stable@vger.kernel.org \
--cc=xiaoliang.yang_1@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.