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

Hangbin Liu <[email protected]>
Newsgroups org.kernel.vger.linux-kselftest,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kernel.vger.stable
Message-ID <anbQR-XiDQ0G4cPo@fedora>
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/[email protected]/

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: <[email protected]> # aae9d6b616b5: hsr: Implement more robust duplicate discard for HSR

as Simon suggested.

Maybe also

Reported-by: [email protected]
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/[email protected]/
> 
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.