netdev - Re: [PATCH next] bonding: Extending LACP MUX State Machine to include a Collecting State.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aaa613cf32a940eb26e6713650555a1efe181ea9.camel@thedillows.org>
Date: Thu, 21 Dec 2023 21:38:01 -0800
From: David Dillow <dave@...dillows.org>
To: jay.vosburgh@...onical.com
Cc: aahila@...gle.com, andy@...yhouse.net, daniel@...earbox.net,
        davem@...emloft.net, edumazet@...gle.com, herbert@...dor.apana.org.au,
        kuba@...nel.org, linux-kernel@...r.kernel.org, maheshb@...gle.com,
        martin.lau@...nel.org, netdev@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH next] bonding: Extending LACP MUX State Machine to
 include a Collecting State.

> I haven't read the patch in detail yet, but my overall question
> is: why do we need this?  This adds significant complexity to the
> state machine logic.  What real problem is this solving, i.e., what
> examples do you have of systems where a port is "in a state where
> it can receive incoming packets while not still distributing"?

Any time we add a new link to an aggregator, or the bond selects a new
aggegrator based on the selection policy, there is currently a race
where we start distributing traffic before our partner (usually a
switch) is ready to start collecting it, leading to dropped packets if
we're running traffic over the bond. We reliably hit this window,
making what should be a non-issue into a customer-visible packet-loss
event. Implementing the full state machine closes the window and makes
these maintenance events lossless.