netdev - Re: [PATCHv2 net-next 2/3] bonding: restructure ad_churn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eaac2f5e-842e-4a18-a7a0-8a7ba2794ef9@redhat.com>
Date: Wed, 21 Jan 2026 08:58:13 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org,
 Jay Vosburgh <jv@...sburgh.net>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Simon Horman <horms@...nel.org>, Mahesh Bandewar <maheshb@...gle.com>,
 Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
 Liang Li <liali@...hat.com>
Subject: Re: [PATCHv2 net-next 2/3] bonding: restructure ad_churn_machine

On 1/21/26 12:11 AM, Jakub Kicinski wrote:
> On Tue, 20 Jan 2026 09:29:14 +0100 Paolo Abeni wrote:
>> On 1/19/26 9:22 PM, Jakub Kicinski wrote:
>>> On Wed, 14 Jan 2026 06:49:20 +0000 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.  
>>>
>>> Paolo, how do you feel about his patch with 2+ weeks until final?
>>> The first patch is definitely suitable for net. If this one is not
>>> it should not have a Fixes tag. I'd lean towards getting them all
>>> into -rc7 if we can.  
>>
>> My personal preference would be for 2/3 landing into net-next: the code
>> looks correct to me, but refactor has IMHO still to much potential for
>> regressions do land directly into net and the blamed commit is quite old.
>>
>> I suggested targeting net-next while retaining the Fixes tag as we
>> already had complex fixes landing into net-next in the past.
> 
> The appropriate way to delay propagation of the fix to add:
> 
> Cc: <stable@...r.kernel.org> # after 4 weeks
> 
> not to merge things into -next.

I went over the code as carefully as I could and I don't see any obvious
problem, so I don't have a so strong opinion vs net, but to hopefully
clarify: my thinking is that this is net-next material because it's an
invasive refactor with behavior change. My preference would be let the
code be tested in next/net-next for a while before landing into mainline.

/P