netdev - bonding: why zero out bond_dev->dev_addr when last slave removed?

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: <5035458C.9000804@genband.com>
Date:	Wed, 22 Aug 2012 14:48:12 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	Jay Vosburgh <fubar@...ibm.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	netdev <netdev@...r.kernel.org>
Subject: bonding: why zero out bond_dev->dev_addr when last slave removed?

Hi all,

I've got a couple questions about the bonding driver.

I was wondering about the rationale for zeroing out bond_dev->dev_addr 
when the last slave is removed from the bond.

Assuming bond0 is currently using the mac address of eth0 then doing

ifenslave -d bond0 eth0
ifenslave -d bond0 eth1
ifenslave bond0 eth1
ifenslave bond0 eth0

ends up changing the MAC address of the bond link. Given that the bond 
itself stays up during this time, why don't we let the bond device keep 
it's previous MAC address (at least if fail_over_mac is zero)?

Is this to account for the case where we move the bond to totally 
different devices such that the old MAC no longer belongs to one of the 
slaves but instead belongs to a NIC outside the bond?

Chris

-- 

Chris Friesen
Software Designer

3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html