[PATCH 0/2] bonding: Two small fixes

	Two small fixes to bonding for the mainline.

	1: Mishandling of RTNL due to what looks like a merge error.

	2: Turn off the new validate_addr check when devices are set 
up.  For backwards compatibility, the bonding master must be able to be
set up with a MAC address of all zeroes.

	Patches are against linux-2.6, and apply cleanly
to netdev-2.6#upstream-linus.  Please apply for 2.6.24.

	-J


---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

	Looks like I incorrectly merged one of the rtnl lock changes,
so that one function, bonding_show_active_slave, held rtnl but didn't
release it, and another, bonding_store_active_slave, never held rtnl but
did release it.

	Fixed so the first function doesn't mess with rtnl, and the
second correctly acquires and releases rtnl.

	Bug reported by Moni Shoua [off-list ref]


Signed-off-by: Jay Vosburgh <redacted>

---
 drivers/net/bonding/bond_sysfs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 7a06ade..b29330d 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c

@@ -1193,8 +1193,6 @@ static ssize_t bonding_show_active_slave(struct device *d,
 	struct bonding *bond = to_bond(d);
 	int count;
 
-	rtnl_lock();
-
 	read_lock(&bond->curr_slave_lock);
 	curr = bond->curr_active_slave;
 	read_unlock(&bond->curr_slave_lock);

@@ -1216,7 +1214,9 @@ static ssize_t bonding_store_active_slave(struct device *d,
         struct slave *new_active = NULL;
 	struct bonding *bond = to_bond(d);
 
+	rtnl_lock();
 	write_lock_bh(&bond->lock);
+
 	if (!USES_PRIMARY(bond->params.mode)) {
 		printk(KERN_INFO DRV_NAME
 		       ": %s: Unable to change active slave; %s is in mode %d\n",

-- 
1.5.3.4.206.g58ba4-dirty

The standard validate_addr handler refuses to accept the all zeroes address
as valid.  However, it's common historical practice for the bonding
master to be configured up prior to having any slaves, at which time the
master will have a MAC address of all zeroes.

Resolved by setting the dev->validate_addr to NULL.  The master still can't
end up with an invalid address, as the set_mac_address function tests
for validity.

Signed-off-by: Jay Vosburgh <redacted>

---
 drivers/net/bonding/bond_main.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6937ef0..a198404 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c

@@ -4405,6 +4405,7 @@ static int bond_init(struct net_device *bond_dev, struct bond_params *params)
 	bond_dev->set_multicast_list = bond_set_multicast_list;
 	bond_dev->change_mtu = bond_change_mtu;
 	bond_dev->set_mac_address = bond_set_mac_address;
+	bond_dev->validate_addr = NULL;
 
 	bond_set_mode_ops(bond, bond->params.mode);
 

-- 
1.5.3.4.206.g58ba4-dirty

Jay Vosburgh wrote:

	Looks like I incorrectly merged one of the rtnl lock changes,
so that one function, bonding_show_active_slave, held rtnl but didn't
release it, and another, bonding_store_active_slave, never held rtnl but
did release it.

	Fixed so the first function doesn't mess with rtnl, and the
second correctly acquires and releases rtnl.

	Bug reported by Moni Shoua [off-list ref]

I ran some shallow tests and it seems that the patch fixes  the problem.

thanks

On Tue, Nov 06, 2007 at 01:33:28PM -0800, Jay Vosburgh wrote:

	Looks like I incorrectly merged one of the rtnl lock changes,
so that one function, bonding_show_active_slave, held rtnl but didn't
release it, and another, bonding_store_active_slave, never held rtnl but
did release it.

	Fixed so the first function doesn't mess with rtnl, and the
second correctly acquires and releases rtnl.

	Bug reported by Moni Shoua [off-list ref]


Signed-off-by: Jay Vosburgh <redacted>

applied 1-2