linux-kernel - [PATCH net-next] bonding: correct rr balancing during link failure

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-next>] [day] [month] [year] [list]

Message-ID: <X8f/WKR6/j9k+vMz@black-debian>
Date:   Wed, 02 Dec 2020 20:55:57 +0000
From:   Lars Everbrand <lars.everbrand@...tonmail.com>
To:     linux-kernel@...r.kernel.org
Cc:     Jay Vosburgh <j.vosburgh@...il.com>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
Subject: [PATCH net-next] bonding: correct rr balancing during link failure

This patch updates the sending algorithm for roundrobin to avoid
over-subscribing interface(s) when one or more interfaces in the bond is
not able to send packets. This happened when order was not random and
more than 2 interfaces were used.

Previously the algorithm would find the next available interface
when an interface failed to send by, this means that most often it is
current_interface + 1. The problem is that when the next packet is to be
sent and the "normal" algorithm then continues with interface++ which
then hits that same interface again.

This patch updates the resending algorithm to update the global counter
of the next interface to use.

Example (prior to patch):

Consider 6 x 100 Mbit/s interfaces in a rr bond. The normal order of links
being used to send would look like:
1 2 3 4 5 6  1 2 3 4 5 6  1 2 3 4 5 6 ...

If, for instance, interface 2 where unable to send the order would have been:
1 3 3 4 5 6  1 3 3 4 5 6  1 3 3 4 5 6 ...

The resulting speed (for TCP) would then become:
50 + 0 + 100 + 50 + 50 + 50 = 300 Mbit/s
instead of the expected 500 Mbit/s.

If interface 3 also would fail the resulting speed would be half of the
expected 400 Mbit/s (33 + 0 + 0 + 100 + 33 + 33).

Signed-off-by: Lars Everbrand <lars.everbrand@...tonmail.com>
---
 drivers/net/bonding/bond_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e0880a3840d7..e02d9c6d40ee 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4107,6 +4107,7 @@ static struct slave *bond_get_slave_by_id(struct bonding *bond,
 		if (--i < 0) {
 			if (bond_slave_can_tx(slave))
 				return slave;
+			bond->rr_tx_counter++;
 		}
 	}
 
@@ -4117,6 +4118,7 @@ static struct slave *bond_get_slave_by_id(struct bonding *bond,
 			break;
 		if (bond_slave_can_tx(slave))
 			return slave;
+		bond->rr_tx_counter++;
 	}
 	/* no slave that can tx has been found */
 	return NULL;
-- 
2.29.2