netdev - [RFC net 0/6] hsr: Implement more robust duplicate discard algorithm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <cover.1766433800.git.fmaurer@redhat.com>
Date: Mon, 22 Dec 2025 21:57:30 +0100
From: Felix Maurer <fmaurer@...hat.com>
To: netdev@...r.kernel.org
Cc: davem@...emloft.net,
	edumazet@...gle.com,
	kuba@...nel.org,
	pabeni@...hat.com,
	horms@...nel.org,
	jkarrenpalo@...il.com,
	tglx@...utronix.de,
	mingo@...nel.org,
	allison.henderson@...cle.com,
	matttbe@...nel.org,
	petrm@...dia.com,
	bigeasy@...utronix.de
Subject: [RFC net 0/6] hsr: Implement more robust duplicate discard algorithm

The PRP duplicate discard algorithm does not work reliably with certain
link faults. Especially with packet loss on one link, the duplicate
discard algorithm drops valid packets. For a more thorough description
see patch 5.

My suggestion is to replace the current, drop window-based algorithm
with a new one that tracks the received sequence numbers individually
(description again in patch 5). I am sending this as an RFC to gather
feedback mainly on two points:

1. Is the design generally acceptable? Of course, this change leads to
   higher memory usage and more work to do for each packet. But I argue
   that this is an acceptable trade-off to make for a more robust PRP
   behavior with faulty links. After all, PRP is to be used in
   environments where redundancy is needed and people are ready to
   maintain two duplicate networks to achieve it.
2. As the tests added in patch 6 show, HSR is subject to similar
   problems. I do not see a reason not to use a very similar algorithm
   for HSR as well (with a bitmap for each port). Any objections to
   doing that (in a later patch series)? This will make the trade-off
   with memory usage more pronounced, as the hsr_seq_block will grow by
   three more bitmaps, at least for each HSR node (of which we do not
   expect too many, as an HSR ring can not be infinitely large).

Most of the patches in this series are for the selftests. This is mainly
to demonstrate the problems with the current duplicate discard
algorithms, not so much about gathering feedback. Especially patch 1 and
2 are rather preparatory cleanups that do not have much to do with the
actual problems the new algorithm tries to solve.

A few points I know not yet addressed are:
- HSR duplicate discard (see above).
- The KUnit test is not updated for the new algorithm. I will work on
  that before actual patch submission.
- Merging the sequence number blocks when two entries in the node table
  are merged because they belong to the same node.

Thank you for your feedback already!

Signed-off-by: Felix Maurer <fmaurer@...hat.com>

---

Felix Maurer (6):
  selftests: hsr: Add ping test for PRP
  selftests: hsr: Check duplicates on HSR with VLAN
  selftests: hsr: Add tests for faulty links
  selftests: hsr: Add tests for more link faults with PRP
  hsr: Implement more robust duplicate discard for PRP
  selftests: hsr: Add more link fault tests for HSR

 net/hsr/hsr_framereg.c                        | 181 ++++++---
 net/hsr/hsr_framereg.h                        |  24 +-
 tools/testing/selftests/net/hsr/Makefile      |   2 +
 tools/testing/selftests/net/hsr/hsr_ping.sh   | 198 +++------
 .../testing/selftests/net/hsr/link_faults.sh  | 376 ++++++++++++++++++
 tools/testing/selftests/net/hsr/prp_ping.sh   | 141 +++++++
 tools/testing/selftests/net/hsr/settings      |   2 +-
 7 files changed, 714 insertions(+), 210 deletions(-)
 create mode 100755 tools/testing/selftests/net/hsr/link_faults.sh
 create mode 100755 tools/testing/selftests/net/hsr/prp_ping.sh

--
2.52.0