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

[Xin Xie <xiexinet@gmail.com>]

On 14/10/2026 17:18, Sebastian Andrzej Siewior wrote:
> 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.

Yes. The same chain also exists with a bond or team device as the port,
and with a macvlan or ipvlan whose lower device is an HSR master. So I
will make the check "a port must not have lower devices", for slave A/B
and for the interlink. A physical NIC or a veth passes; bridge, bond,
team, macvlan and ipvlan are refused. The only real setup this excludes
is a bridge used directly as the interlink; a veth into that bridge
still works.

> Or (c) tell HSR to reject bridge ports. This should avoid the case and
> the problem.

Nobody else has commented in the meantime, so I will go with your
suggestion. In v8 the lock stays as it is today, and patch 2 becomes
the port check with the syzbot Reported-by. Narrowing the lock can be a
separate change later, outside this fix series. Patch 3 then segments
before taking seqnr_lock and numbers each segment under it.

Hangbin, you dropped your patch in August because this series covered
the same place. With this the syzbot report is closed by the port
check, and narrowing seqnr_lock becomes a separate change. If you want
to pick your patch up again for that, I have no objection; the stable
prerequisite tag Simon suggested and the per-CPU TX counters would then
belong there.

One case the check cannot see is a tunnel device used as a port whose
route goes over the HSR master itself. I would leave that alone unless
you want the re-entry guard from (a) as well.


-- 
Xin