Re: [PATCH net v4 2/4] net: hsr: shrink seqnr_lock to sequence counter updates
From: Hangbin Liu
Date: Sat Aug 08 2026 - 02:44:43 EST
On Fri, Aug 07, 2026 at 04:49:36PM +0200, Xin Xie wrote:
> On 07/08/2026 16:27, Hangbin Liu wrote:
> >
> > Maybe use a shorter commit description.
> >
> > Note: Avoid these macros in fast path, prefer per-cpu or per-queue counters.
> >
> > And the counters in hsr_deliver_master() also need to protected. Especially
> > multicast.
> >
> > Thanks
> > Hangbin
>
> Thanks.
>
> The long commit description was from v4. I reworked and shortened it in v5:
>
> https://lore.kernel.org/netdev/20260807140751.1351-3-xiexinet@xxxxxxxxx/
This length is much shorter. It would be nice to mention Felix's patch, which
is why we can remove the lock from forwarding path now.
And use tag like
Cc: <stable@xxxxxxxxxxxxxxx> # aae9d6b616b5: hsr: Implement more robust duplicate discard for HSR
as Simon suggested.
Maybe also
Reported-by: syzbot+fbf74291c3b7e753b481@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes: https://syzkaller.appspot.com/bug?extid=fbf74291c3b7e753b481
>
> Regarding the statistics, Paolo previously suggested addressing the HSR dev stats races in a separate series, since there are already several occurrences:
>
> https://lore.kernel.org/netdev/4fc3b9f1-4bef-4b34-ae7a-e89037cce829@xxxxxxxxxx/
>
> Would you prefer that I drop the DEV_STATS_* conversions from the next revision and address all HSR statistics consistently in a follow-up, including hsr_deliver_master() and multicast, rather than adding per-CPU accounting to this series?
>
Makes sense to me. The counter problem should be a separate issue apart
from this one.
Thanks
Hangbin