On 2026-10-14 16:48:55 [+0200], Xin Xie wrote: > > What are stacked HSR devices? Looking from the setup in the referenced > > report this is a bridge device attached to a HSR ring. > > An announce frame is sent and this goes to hsr_dev_xmit(). This does not > > look like a normal setup. Is this something you use or is this something > > the bot came up with? > It is the setup from the syzbot report, not something we use. In that > report the slave port of one HSR device is a bridge, and one bridge > port is a second HSR device. The announce frame of the first device > holds its seqnr_lock, goes through the bridge, and ends in > hsr_dev_xmit() of the second device, which takes its own seqnr_lock. > Lockdep sees the same lock class twice and reports it. With two > devices this is not a real deadlock. It only becomes one when the > transmit path comes back to the same device.
Okay. In that case, could you please teach HSR to reject bridge ports at the very least? Given that HSR is a ring and PRP faces two networks, I don't think a bridge setup would make sense here. So rejecting this should be any easy fix. … > So for v8 I see two simple options: > (a) Keep seqnr_lock across the submission like today and only break > the re-entry: a frame that enters HSR transmit while this CPU is > already inside HSR forwarding is dropped and counted. Ordering is > kept, but all forwarding of one device stays serialized. > (b) Narrow the lock to the counter update, as in v6 and in Hangbin's > patch [1]. Several CPUs can forward in parallel. A receiver without > the bitmap discard can drop a reordered frame, so the patch would > carry "Cc: <[email protected]> # aae9d6b616b5: ..." as Simon > suggested there, and the TX statistics move to per-CPU counters. > > I would prefer (b) because of the parallel forwarding, if the old > receiver limitation is acceptable to you. Otherwise (a). > > Hangbin, Simon, your view is welcome too. > > Patch 3 works with both: it segments before the lock, and each > segment is numbered and submitted under the lock. Or (c) tell HSR to reject bridge ports. This should avoid the case and the problem. Sebastian
