Re: [PATCH net v2 0/2] bridge: cfm: correct CC receive monitoring transitions

[Nikolay Aleksandrov <razor@blackwall.org>]

On 28/10/2026 18:47, Baek Kyu, Kim wrote:
> Two CC transition bugs affect CFM receive monitoring. When CC is
> re-enabled with a new interval, the first RX check uses the previous
> interval. After CC is disabled, a received CCM can still change peer
> status even when its RX work cannot be queued.
> 
> Patch 1 stores the new CC configuration before enabling peer RX work.
> Patch 2 keeps RX work disabled while CC is off and skips CCM status
> processing during that time.
> 
> The v1 submission covered the RX work restart. This revision also
> addresses the two review findings. The interval fix is a separate
> patch because it has a distinct failure condition.
> 
> The combined series passed 8 CC interval/transition checks and 3 CCM
> status checks under ARM64 QEMU/KVM with bridge/veth. The CCM status
> test failed 2 of its 3 checks on the v1 image as expected.
> 
> Baek Kyu, Kim (2):
>    bridge: cfm: Store the new CC configuration before enabling peers
>    bridge: cfm: ignore CCM while CC is disabled
> 
>   net/bridge/br_cfm.c | 22 ++++++++++++++++------
>   1 file changed, 16 insertions(+), 6 deletions(-)
> 
> ---
> v1: https://lkml.iu.edu/2610.3/01364.html
> v2:
>    - Add the CC enable interval fix as patch 1/2.
>    - Skip CCM status updates while CC is disabled in patch 2/2.
>    - Retain the RX work disable/enable fix from v1 in patch 2/2.
> 

Hi,
Are you actually using CFM anywhere in production? We have been discussing
deprecating cfm and mrp in the bridge as noone seems interested and they have
proven as sources of bugs over time. These don't seem like critical fixes
so I would target net-next when it opens up.

Cheers,
  Nik