From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E970281370 for ; Fri, 27 Feb 2026 00:53:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772153584; cv=none; b=UpukZcUTze49EAK4XCh5oMfG3EQ1PqxlQyEsAczHZ6Z7zPwlC2uUYVuXNC1fsmHHrt+vLc/DxWfeZVDr+/q40oK5zAjmCP5PUdA3F11nkOjXTekNCJKGSfAZXmXxcKz1eWD7rRTESfJ3idoMbzr9nLF+QW74vhsk3XdSw+alGW0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772153584; c=relaxed/simple; bh=V58AsEXtDlXDbNdeDBd1zzEWI/NozXCvECRYKv0veUM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NjnS6HplfLA5wLexbODW3LeyUEz0tw83d/q9XxBlL24wPOW6x/bVUxmHKn3ueJTU+JJ/YM0QLtYzDkGPspzUtNyRrVX2vpGgJ5D6TwmHuNlGsFQSiF1Jh9Afm+uUnLBMcUD+BjlMVGGXZPamQzjHwDgxXkx+EAvFHow+ruwn9dc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YMBJobID; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YMBJobID" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2add623cb27so9647185ad.3 for ; Thu, 26 Feb 2026 16:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772153583; x=1772758383; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=9gbpHB3N8fWBNDFn5ovPsYhngGHkPr0G2QGOAHfoIKs=; b=YMBJobIDBmh570RCF1WW+1QFR6izNsYPEATR801y2qMr0DFqBi8cu1OZQOqa+ViNnM J28EloQ+m8/8Tx93S3qPD3b0fdFfuSDAXdtPyLLYA354KRtoTMeWewnyE61lZYoFOg/y iX+COvhxI9VG0+AbSk40LQZXQDazOO+Eq+tpBuQrOlB2pn4VG2jExZF9iOj+tx32ldfg QfwK7yxxpkaAtEWzszcluFrM7eL+RTotwo6Jt7vAABxVwAsraLrwBdetHzWNWbWLFzAJ 989HNfjN5I1nuOw8WspmHdMiWHr1dfz5B0JLseLeSUssJfs4zgHtl0KVjRW7be/CInvR lmCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772153583; x=1772758383; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9gbpHB3N8fWBNDFn5ovPsYhngGHkPr0G2QGOAHfoIKs=; b=hFTe3t7l0V4LmB7y736nbtBD7HdiewFmleIKRwJhnebWjET4kZKe7VcR92POiQjeyt /7HyFGVhvZUFQlZYRMacyZbLGMZDXELwBDhWfZo/O58GyYx3De4ECQjNYaFmdlTXXGWb lnS/mAOlXVW+OHAykU/OaUUwCgU6FNi6IpeSFQ8j9l1BPJCXneYgr9SQzpxONBNK3MeZ 459poVNZzzNL1mco6Y96lHJnOJsR3iKSQpa2s/XzbljEdArAZfr2SRC2KZHn8YIpPoQr CqNJRW9BNttTfyMjqK4brOHO09eHoMEfo1TkssUyR88jz84t+oG6IXJ9Kcr7t0Ok3kcj 7wZA== X-Forwarded-Encrypted: i=1; AJvYcCUjznEY3O/EkTbi5ES4FMXMnU1oOqrBn96M7k6u3toeW6vLkLvAzQ50bkBU+FKwhssYfSjRk8z3SZH/hpY=@vger.kernel.org X-Gm-Message-State: AOJu0YzdCoPr6TWsWoF826BKrev9rtESEonizf58Y81ZVdTSij3B2Vqc KoNyVUBQXqCVzvOEFOcJX04iJ2m/jBh8URW/wyL59BDz+5ymL0/pvW7S X-Gm-Gg: ATEYQzyMbwIwRBv+9VSW0IoPNgeHQzoQPyNzcPG/lvZ0m/jrhJ62cM+LEPI1IaZ2DsW ufUVzwl9xXhmQEFWI7ENIQSbsVmjtuIZpt3032+rWZJQaQ9pJ7fkit+51FV2+EPNZhU4z3JPX8I 6fe9XgvnejOHAeYJu91SkT2u2DWODBE7M0+Qr7dLAiIiZb+cTdTkKrdeyosKg2g9Jm83FvDg6tB VQIYrgaWlQoANps16AIJSPWeLnVsgt7xLL/BXoZuTchKOq4cXBbrcg3/EC43sMoKVwoXWm3z29S pzNjlOJ3o1cDGpUWqv9B9tDOWln0lvslUkWc8c1E+C3fLXv44SXHAl+9wbsMXCIJRPW6kzTJCvb NvLfH6JQ3VjglooI8eHUih2oL2RBrXaUZWzXTCWhEk63A2CsuYr6VUQshLxMiozXJHwcethiIGt 08c1cwAU+fY0Lunt2P4IObLZ11jY8= X-Received: by 2002:a17:903:2312:b0:2a9:cb10:42b with SMTP id d9443c01a7336-2ae2e3f7cc2mr8443145ad.44.1772153582912; Thu, 26 Feb 2026 16:53:02 -0800 (PST) Received: from fedora ([209.132.188.88]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2adfb5b22fesm51253065ad.2.2026.02.26.16.52.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Feb 2026 16:53:02 -0800 (PST) Date: Fri, 27 Feb 2026 00:52:54 +0000 From: Hangbin Liu To: Jay Vosburgh Cc: netdev@vger.kernel.org, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Shuah Khan , Nikolay Aleksandrov , Mahesh Bandewar , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Liang Li Subject: Re: [PATCHv3 net 2/3] bonding: restructure ad_churn_machine Message-ID: References: <20260226125331.28147-1-liuhangbin@gmail.com> <20260226125331.28147-3-liuhangbin@gmail.com> <941081.1772152606@famine> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <941081.1772152606@famine> On Thu, Feb 26, 2026 at 04:36:46PM -0800, Jay Vosburgh wrote: > Hangbin Liu wrote: > > >The current ad_churn_machine implementation only transitions the > >actor/partner churn state to churned or none after the churn timer expires. > >However, IEEE 802.1AX-2014 specifies that a port should enter the none > >state immediately once the actor’s port state enters synchronization. > > > >Another issue is that if the churn timer expires while the churn machine is > >not in the monitor state (e.g. already in churn), the state may remain > >stuck indefinitely with no further transitions. This becomes visible in > >multi-aggregator scenarios. For example: > > > >Ports 1 and 2 are in aggregator 1 (active) > >Ports 3 and 4 are in aggregator 2 (backup) > > > >Ports 1 and 2 should be in none > >Ports 3 and 4 should be in churned > > > >If a failover occurs due to port 2 link down/up, aggregator 2 becomes active. > >Under the current implementation, the resulting states may look like: > > > >agg 1 (backup): port 1 -> none, port 2 -> churned > >agg 2 (active): ports 3,4 keep in churned. > > > >The root cause is that ad_churn_machine() only clears the > >AD_PORT_CHURNED flag and starts a timer. When a churned port becomes active, > >its RX state becomes AD_RX_CURRENT, preventing the churn flag from being set > >again, leaving no way to retrigger the timer. Fixing this solely in > >ad_rx_machine() is insufficient. > > > >This patch rewrites ad_churn_machine according to IEEE 802.1AX-2014 > >(Figures 6-23 and 6-24), ensuring correct churn detection, state transitions, > >and timer behavior. With new implementation, there is no need to set > >AD_PORT_CHURNED in ad_rx_machine(). > > > >Fixes: 14c9551a32eb ("bonding: Implement port churn-machine (AD standard 43.4.17).") > >Reported-by: Liang Li > >Tested-by: Liang Li > >Signed-off-by: Hangbin Liu > > I missed this last time it was posted, but reading it now I > think the functional change looks good, but I question the usefulness of > including the 25 line ASCII art version of the state diagram. > > The standard is publicly available, so a comment saying that the > state machine logic conforms to IEEE 802.1AX-2014 figures 6-23 and 6-24 > should be sufficient. Anyone seriously checking the code against the > standard will need to read the relevant text, so they'll be looking it > up anyway. I added it here to help new readers and reviewers understand the logic quickly. If you think there’s no need to include it in the code, maybe we can move it to the commit description? Thanks Hangbin