Re: [PATCH net-next v4 1/4] net: hsr: add PRP interlink (RedBox) datapath and duplicate discard

[Xin Xie <xiexinet@gmail.com>]

On Fri, 24 Jul 2026 14:12:30 +0100 Simon Horman wrote:
> [Severity: High]
> ... does modifying the MAC header directly in hsr_xmit() corrupt
> shared packet data? [...]
> Should the skb be unshared before making these direct modifications?

I checked this against the v4 base and the series diff.

The shared-data write is real. hsr_xmit() writes
eth_hdr(skb)->h_source in place - the slave-address substitution
for master-originated frames, and the macaddress_redbox
substitution for the interlink port - on skbs that can be clones.
Multiple consumers can share the same packet data while needing
different source addresses: a PRP LAN broadcast or multicast can be
delivered to the master (source rewritten via
hsr_addr_subst_source()) and forwarded to the interlink (rewritten
to macaddress_redbox) from the same underlying buffer.

Two scope facts. This is pre-existing HSR RedBox code, present
since v6.11: hsr_xmit() itself is untouched by the series (patch
1/4's hsr_forward.c changes sit below it and do not modify its
body), and the series' only h_source-adjacent change moves an
existing ether_addr_copy() a few lines earlier in
hsr_dev_finalize(), where no skb is involved. But the series does
make the existing interlink path reachable for PRP.

I will handle this as an independent fix for the existing HSR/PRP
code, posted separately for net with its own Fixes: tag - not
folded into this feature series.

Would you like the feature series to wait for that fix, or may v4
proceed while it is reviewed separately?

(The hsr_create_tagged_frame() side question overlaps the third
finding in your 3/4 mail; it is answered there.)

--
Xin