netdev - Re: [PATCH net-next v2 6/9] hsr: Implement more robust duplicate discard for HSR

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260203120813.hSgDgi4e@linutronix.de>
Date: Tue, 3 Feb 2026 13:08:13 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Felix Maurer <fmaurer@...hat.com>
Cc: netdev@...r.kernel.org, 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, petrm@...dia.com, antonio@...nvpn.net,
	Yoann Congal <yoann.congal@...le.fr>
Subject: Re: [PATCH net-next v2 6/9] hsr: Implement more robust duplicate
 discard for HSR

On 2026-02-03 12:49:39 [+0100], Felix Maurer wrote:
> I think the duplicates can occur on RedBoxes if they are used to couple
> the HSR ring and another redundant network (either with a PRP network
> through HSR-PRP mode or with an HSR network through HSR-HSR mode, which
> we both don't implement at the moment). In both cases, two RedBoxes are
> used to maintain redundancy and both independently inject a frame they
> receive into the HSR ring (see Figure 12 and 16 in the IEC
> 62439-3:2021). But it's also the RedBoxes that would remove the
> duplicates, so we would be aware that we should discard duplicates on
> port A and B.
> 
> However, I'm not sure if these are the only cases where duplicates are
> to be expected in the ring and I don't want to prematurely make the
> decision to just forward everything within the ring.

I would have to study the spec first to understand how PRP, HSR mix
works with the redbox before I can give a statement. But yeah…

> > If you track duplicates for A and B in a single "bitmap" then this would
> > mode X.
> 
> I think I didn't understand this clearly and I mixed this up in some of
> my replies, so just to make sure; there are two ideas:
> 1) Track port A and B together, i.e., don't forward the
>    counter-duplicate, i.e., Mode X (which is optional to implement).
> 2) Don't track duplicates for port A or B at all. We consider duplicates
>    in the ring as a failure of another node.
> 
> We don't consider 1), i.e., Mode X, at the moment. We are only
> discussing idea 2), right?

correct.

> > I nag here a bit because you allocate 16 + (128 / 8) * 4 * 64 = 4112
> > bytes for this bitmap per node. That is a bit over 4kib. Then adding and
> > removing sequences got a bit more expensive. Anyway. There is table
> > F.19+ specifying HSR tests and don't find "forwarding duplicate over
> > port A". So lets keep it.
> 
> I totally understand that. It's quite some memory for each node and I'm
> very much in for reducing that. But I'd suggest that, for now, we follow
> what we had before and what the standard explicitly asks, which is to
> track (and discard) duplicates on port A and B as well. I'm not sure if
> we should diverge from the standard in one of the few points where it is
> explicit. If I understand your last sentence correctly, you're okay with
> that as well?

Yes. Because you reworked the duplicate-detect algorithm and I would
like to keep the "unrelated" details (tracking A, B, …) as it was so if
it serious regressions get reported we can easily pin point it. So we
replace just one thing and both multiples. At the expense that more
memory is now consumed but this is fine I hope.
So this might be for the future.

> Thanks,
>    Felix

Sebastian