netdev - Re: [PATCH net-next v2 0/9] 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXuK7NEW_2IZHu86@thinkpad>
Date: Thu, 29 Jan 2026 17:29:32 +0100
From: Felix Maurer <fmaurer@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, 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
Subject: Re: [PATCH net-next v2 0/9] hsr: Implement more robust duplicate
 discard algorithm

On Thu, Jan 29, 2026 at 04:29:22PM +0100, Sebastian Andrzej Siewior wrote:
> On 2026-01-26 10:28:18 [+0100], Felix Maurer wrote:
> >
> > I'll wait for feedback from Sebastian, but I'm also fine with merging
> > the fixes for the KUnit test into the other patches and reposting.
>
> Overall the new algorithm is very nice. Feel free to add
> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

Thank you very much for taking the time to review this series! I'll
address the parts as I wrote in the other replies.

As Jakub wrote, there is the transient build failure due to the KUnit
test needing changes. I discussed that with Simon as well (off-list). In
the v3, I'll add the respective fixes to the KUnit test to the patches
where I change the algorithm so the build passes all the time. As the
patches 4 and 6 will look quite different with that, I'll only add your
Reviewed by tag to the remaining ones and leave 4 and 6 subject to a
quick re-review by you.

> I made a few comments where I think it should be possible to avoid
> tracking the sequence number for interface A and B but since you
> preserve what is done now, I don't mind to keep it as-it and try to
> remove it later on (unless I'm wrong and it is not doable).

I replied to that directly, I don't think that's doable. But we can take
a look at the HW-offload case in the future.

Thanks,
   Felix