On Mon, 06 Jul 2026 13:41:27 +0000, Xin Xie <[email protected]> wrote: > 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. >
The series looks good to me, I just found a couple of nits. Thank you!
