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
