[PATCH net-next 0/4] net: hsr: PRP RedBox (PRP-SAN) support
From: Xin Xie <hidden>
Date: 2026-07-04 23:47:07
Also in:
linux-kselftest, lkml
This series adds PRP RedBox support to the hsr driver: a PRP node that
proxies one or more SANs sitting behind an interlink port (IEC 62439-3,
PRP-SAN). HSR-SAN has been supported since commit 5055cccfc2d1 ("net: hsr:
Provide RedBox support (HSR-SAN)"); this extends the equivalent capability
to PRP, reusing the existing protocol-neutral proxy machinery
(proxy_node_db, hsr_proxy_announce(), hsr_prune_proxy_nodes()).
A SAN behind the interlink does bidirectional unicast with peers on the PRP
network, its source MAC is preserved on the wire, the PRP RCT is correct,
and the RedBox announces each proxied SAN with the RedBox-MAC TLV (Type 30)
in its supervision frames.
The series is bisect-safe: the datapath, duplicate discard and supervision
support are added first; the rtnetlink rejection of "type hsr ... interlink
<dev> proto 1" is removed only in patch 3, once the feature is complete.
Design notes:
- prp_drop_frame() does not walk the node tables. The destination
classification (PRP-network node vs proxied SAN) is resolved once per
frame in fill_frame_info() and cached in struct hsr_frame_info, so the
per egress-port drop decision is O(1) in the softIRQ path. The
classification is gated on PRP RedBox devices (prot_version == PRP_V1 &&
hsr->redbox), so HSR RedBox traffic is not affected.
- The LAN A/B duplicate test is factored into prp_is_lan_dup() so the new
PRP interlink rules in prp_drop_frame() do not change hsr_drop_frame()
behaviour, including the NETIF_F_HW_HSR_FWD path. This is software PRP
RedBox only; it adds no new hardware-offload contract.
- The supervision emitter uses pre-reserved tailroom (hsr_init_skb() +
skb_put()) on the existing GFP_ATOMIC path; no skb_linearize() or
pskb_expand_head(). The RedBox-MAC TLV is followed by an explicit EOT
(Type 0, Length 0); padding via skb_put_padto(ETH_ZLEN) and the 6-byte
PRP RCT remain at the absolute tail of the egress frame.
- The hsr_get_node() hsr_ethhdr length guard is relaxed only for PRP
supervision frames (prot_version == PRP_V1 && ETH_P_PRP && is_sup), which
are untagged with mac_len == ETH_HLEN. HSR (ETH_P_HSR) supervision is
front-tagged and keeps the original length requirement, so HSR
malformed-frame filtering is unchanged.
Testing (on a net-next v7.2-rc1 kernel built from this base, x86-64):
- checkpatch.pl --strict: patches 1-3 clean; patch 4 reports only the
expected "added file(s), does MAINTAINERS need updating?" note, which is
ignorable here -- MAINTAINERS already lists
tools/testing/selftests/net/hsr/ under HSR NETWORK PROTOCOL.
- git diff --check clean; the series git-am's onto the base commit.
- tools/testing/selftests/net/hsr/hsr_prp_redbox.sh: PASS on the patched
kernel (bidirectional unicast, SAN MAC preservation, RedBox-MAC TLV +
EOT in the proxy-announce).
- HSR regression on the same kernel: hsr_redbox.sh (HSR-SAN/RedBox),
hsr_ping.sh and prp_ping.sh all PASS, confirming the PRP changes do not
regress the existing HSR/PRP paths.
- netns checks: peer<->SAN 0% loss with no duplicates and a valid PRP RCT
on the wire; a silent SAN is pruned from the announce; zero driver
WARN/BUG/Oops/RCU-stall during the run.
Beyond the in-tree selftest, this exact series (applied to this base and
running as the net-next kernel on x86-64 hardware) was also validated with an
out-of-tree IEC 62439-3 conformance harness (supervision TLV chain, duplicate
discard, cross-LAN rejection, seqnr rollover, VLAN/multicast/GOOSE frame types
with the RCT verified at the absolute frame tail), and interoperability-tested
against a commercial PRP RedBox (Siemens SCALANCE X204RNA) over 100 Mbit/s
Fast Ethernet with NIC hardware (PTP) timestamping: a mid-stream single-LAN
outage of ~2 s at 10 kpps was bridged with zero lost and zero duplicate frames
(seamless PRP failover), and the duplicate-discard window held zero lost /
zero duplicates under netem asymmetric delay up to 100 ms (~1000 sequence
numbers in flight), 25% reorder, and 5% single-LAN loss. The failover and
impairment matrix was additionally repeated on a KASAN + lockdep + kmemleak
instrumented build of this kernel, including a 72-carrier-event link
flap-storm with deliberate double-LAN cuts: zero KASAN, lockdep, or kmemleak
findings. This out-of-tree testing is supplementary and not required to
evaluate the series.
Xin Xie (4):
net: hsr: add PRP interlink (RedBox) datapath and duplicate discard
net: hsr: emit RedBox-MAC TLV in PRP RedBox supervision frames
net: hsr: allow PRP RedBox (interlink) creation
selftests: net: hsr: add PRP RedBox test
net/hsr/hsr_device.c | 33 ++++++-
net/hsr/hsr_forward.c | 49 ++++++++--
net/hsr/hsr_framereg.c | 23 ++++-
net/hsr/hsr_framereg.h | 2 +
net/hsr/hsr_netlink.c | 8 +-
tools/testing/selftests/net/hsr/Makefile | 1 +
.../selftests/net/hsr/hsr_prp_redbox.sh | 96 +++++++++++++++++++
7 files changed, 191 insertions(+), 21 deletions(-)
create mode 100755 tools/testing/selftests/net/hsr/hsr_prp_redbox.sh
base-commit: b73bc9ca3686b78b642fb35dcc1fdf874ecb74a1
--
2.53.0