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

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

[Baek Kyu, Kim]

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.

-- 
2.55.0

[PATCH net v2 1/2] bridge: cfm: Store the new CC configuration before enabling peers

[Baek Kyu, Kim]

br_cfm_cc_config_set() enables existing peers before storing the new
CC configuration. The receive timer therefore starts with the previous
expected interval, delaying CCM loss detection when enabling CC with a
shorter interval. For example, disabling CC at 1s and re-enabling it at
100ms schedules the first check after 250ms instead of 25ms, before
rounding to jiffies.

Save the disabled-to-enabled transition and store the new configuration
before enabling peers. Keep cancellation on disable before replacing
the configuration.

Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.")
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
---
On the combined v2 kernel under ARM64 QEMU/KVM, all 8 CC interval and
transition checks passed with bridge/veth and netlink configuration.

 net/bridge/br_cfm.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
index 9dcc97d63a6f..28b40dbf4073 100644
--- a/net/bridge/br_cfm.c
+++ b/net/bridge/br_cfm.c
@@ -634,6 +634,7 @@ int br_cfm_cc_config_set(struct net_bridge *br,
 {
 	struct br_cfm_peer_mep *peer_mep;
 	struct br_cfm_mep *mep;
+	bool enable;
 
 	ASSERT_RTNL();
 
@@ -648,17 +649,20 @@ int br_cfm_cc_config_set(struct net_bridge *br,
 	if (memcmp(config, &mep->cc_config, sizeof(*config)) == 0)
 		return 0;
 
-	if (config->enable && !mep->cc_config.enable)
-		/* CC is enabled */
-		hlist_for_each_entry(peer_mep, &mep->peer_mep_list, head)
-			cc_peer_enable(peer_mep);
-
 	if (!config->enable && mep->cc_config.enable)
 		/* CC is disabled */
 		hlist_for_each_entry(peer_mep, &mep->peer_mep_list, head)
 			cc_peer_disable(peer_mep);
 
+	enable = config->enable && !mep->cc_config.enable;
+
 	mep->cc_config = *config;
+
+	if (enable)
+		/* CC is enabled */
+		hlist_for_each_entry(peer_mep, &mep->peer_mep_list, head)
+			cc_peer_enable(peer_mep);
+
 	mep->ccm_rx_snumber = 0;
 	mep->ccm_tx_snumber = 1;
 
-- 
2.55.0

[PATCH net v2 2/2] bridge: cfm: ignore CCM while CC is disabled

[Baek Kyu, Kim]

A valid CCM received after CC is disabled can clear the peer defect
and restart its RX timer. Cancelling pending work does not stop a later
receive from queuing it again. Even with RX work disabled, that receive
can still update peer status and notify userspace.

Keep RX work disabled until CC is explicitly enabled, and skip CCM
processing while CC is disabled. This prevents a later CCM from changing
peer status or restarting RX monitoring.

Fixes: dc32cbb3dbd7 ("bridge: cfm: Kernel space implementation of CFM. CCM frame RX added.")
Signed-off-by: Baek Kyu, Kim <pocj8ur4in@gmail.com>
---
On ARM64 QEMU/KVM with bridge/veth, a valid CCM after the disable ACK
cleared the peer defect on v1 but left it set on the combined v2 kernel.
Re-enabling CC allowed a valid CCM to clear the defect. All 3 status
checks passed on v2; 2 failed on v1 as expected.

 net/bridge/br_cfm.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/bridge/br_cfm.c b/net/bridge/br_cfm.c
index 28b40dbf4073..115cccf1d327 100644
--- a/net/bridge/br_cfm.c
+++ b/net/bridge/br_cfm.c
@@ -150,12 +150,13 @@ static void cc_peer_enable(struct br_cfm_peer_mep *peer_mep)
 	memset(&peer_mep->cc_status, 0, sizeof(peer_mep->cc_status));
 	peer_mep->ccm_rx_count_miss = 0;
 
+	enable_delayed_work(&peer_mep->ccm_rx_dwork);
 	ccm_rx_timer_start(peer_mep);
 }
 
 static void cc_peer_disable(struct br_cfm_peer_mep *peer_mep)
 {
-	cancel_delayed_work_sync(&peer_mep->ccm_rx_dwork);
+	disable_delayed_work_sync(&peer_mep->ccm_rx_dwork);
 }
 
 static struct sk_buff *ccm_frame_build(struct br_cfm_mep *mep,
@@ -414,6 +415,9 @@ int br_cfm_frame_rx(struct net_bridge_port *port, struct sk_buff *skb)
 
 	if (hdr->opcode == BR_CFM_OPCODE_CCM) {
 		/* CCM PDU received. */
+		if (!READ_ONCE(mep->cc_config.enable))
+			return 1;
+
 		/* MA ID is after common header + sequence number + MEP ID */
 		maid = skb_header_pointer(skb,
 					  CFM_CCM_PDU_MAID_OFFSET,
@@ -699,6 +703,8 @@ int br_cfm_cc_peer_mep_add(struct net_bridge *br, const u32 instance,
 	peer_mep->mepid = mepid;
 	peer_mep->mep = mep;
 	INIT_DELAYED_WORK(&peer_mep->ccm_rx_dwork, ccm_rx_work_expired);
+	/* Keep RX work disabled until CC is enabled. */
+	disable_delayed_work(&peer_mep->ccm_rx_dwork);
 
 	if (mep->cc_config.enable)
 		cc_peer_enable(peer_mep);
-- 
2.55.0

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

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

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

[Baek Kyu, Kim]

Both issues were raised in Sashiko's review of v1. I had also identified the stale interval ordering during an earlier manual inspection of the CC enable path. I validated both changes under ARM64 QEMU/KVM while preparing the two-patch v2 series.