linux-kernel - [PATCH 3.2 099/107] bonding: correct the MAC address for "follow" fail_over

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: <lsq.1444349548.728861147@decadent.org.uk>
Date:	Fri, 09 Oct 2015 01:12:28 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:	akpm@...ux-foundation.org,
	"dingtianhong" <dingtianhong@...wei.com>,
	"David S. Miller" <davem@...emloft.net>,
	"Nikolay Aleksandrov" <nikolay@...ulusnetworks.com>
Subject: [PATCH 3.2 099/107] bonding: correct the MAC address for "follow"
  fail_over_mac policy

3.2.72-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: dingtianhong <dingtianhong@...wei.com>

[ Upstream commit a951bc1e6ba58f11df5ed5ddc41311e10f5fd20b ]

The "follow" fail_over_mac policy is useful for multiport devices that
either become confused or incur a performance penalty when multiple
ports are programmed with the same MAC address, but the same MAC
address still may happened by this steps for this policy:

1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
   bond0 has the same mac address with eth0, it is MAC1.

2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
   eth1 is backup, eth1 has MAC2.

3) ifconfig eth0 down
   eth1 became active slave, bond will swap MAC for eth0 and eth1,
   so eth1 has MAC1, and eth0 has MAC2.

4) ifconfig eth1 down
   there is no active slave, and eth1 still has MAC1, eth2 has MAC2.

5) ifconfig eth0 up
   the eth0 became active slave again, the bond set eth0 to MAC1.

Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
MAC address, it will break this policy for ACTIVE_BACKUP mode.

This patch will fix this problem by finding the old active slave and
swap them MAC address before change active slave.

Signed-off-by: Ding Tianhong <dingtianhong@...wei.com>
Tested-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Signed-off-by: David S. Miller <davem@...emloft.net>
[bwh: Backported to 3.2:
 - bond_for_each_slave() takes an extra int paramter
 - Use compare_ether_addr() instead of ether_addr_equal()]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 drivers/net/bonding/bond_main.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -861,6 +861,23 @@ static void bond_mc_swap(struct bonding
 	}
 }
 
+static struct slave *bond_get_old_active(struct bonding *bond,
+					 struct slave *new_active)
+{
+	struct slave *slave;
+	int i;
+
+	bond_for_each_slave(bond, slave, i) {
+		if (slave == new_active)
+			continue;
+
+		if (!compare_ether_addr(bond->dev->dev_addr, slave->dev->dev_addr))
+			return slave;
+	}
+
+	return NULL;
+}
+
 /*
  * bond_do_fail_over_mac
  *
@@ -898,6 +915,9 @@ static void bond_do_fail_over_mac(struct
 		write_unlock_bh(&bond->curr_slave_lock);
 		read_unlock(&bond->lock);
 
+		if (!old_active)
+			old_active = bond_get_old_active(bond, new_active);
+
 		if (old_active) {
 			memcpy(tmp_mac, new_active->dev->dev_addr, ETH_ALEN);
 			memcpy(saddr.sa_data, old_active->dev->dev_addr,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/