Re: [PATCH net v4 2/4] net: hsr: shrink seqnr_lock to sequence counter updates

[Hangbin Liu <liuhangbin@gmail.com>]

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@gmail.com/

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@vger.kernel.org> # aae9d6b616b5: hsr: Implement more robust duplicate discard for HSR

as Simon suggested.

Maybe also

Reported-by: syzbot+fbf74291c3b7e753b481@syzkaller.appspotmail.com
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@redhat.com/
> 
> 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