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

[Xin Xie <xiexinet@gmail.com>]

On 23/09/2026 12:37, Sebastian Andrzej Siewior wrote:
> This fix relies on the bitmap seq nr handling while the Fixes commits
> below do not have it. Doesn't this revert the synchronisation change
> leading to the problem it tried to solve at least in the stable kernels?

You're right. Shrinking the lock can reintroduce ordering drops on 
pre-bitmap kernels, and the sender's bitmap does not make reordering safe 
for older peers.

Across ten VM runs per mode against an unmodified pre-bitmap HSRv0
peer, the narrowed-lock control delivered 19,128 of 20,000 test frames
at the peer's master. The ordered-consumer prototype delivered all
20,000 exactly once.

I'll rework patch 2 around a single consumer for locally numbered
traffic, including supervision. Each frame would be submitted to all
its lower devices before the next frame is numbered. An idle caller
would process only its own input inline; contention or re-entry would
queue input to one BH worker.

No HSR lock would be held across segmentation or dev_queue_xmit().
Deferred inputs would retain their core TX recursion depth. This
preserves the original per-lower submission ordering without relying
on bitmap tolerance.

On PREEMPT_RT, consumer ownership would not provide priority inheritance
from queued producers; progress depends on the consumer being scheduled.
I will test this explicitly.

-- 
Xin