Re: [PATCH net v7 2/4] net: hsr: preserve submission order without a forwarding lock

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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: <stable@vger.kernel.org> # 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