Since commit cc0e40700656b09d93b062ef6c818aa45429d09a, there is a
problem if you have the 8021q module loaded and you then attempt to
enslave a VLAN challenged interface. This is because VLAN 0 is
automatically added to the bond, and the new bond_vlan_used() function
simply checks for an empty list in bond->vlan_list without taking into
account that VLAN0 might be on the interface.
This specifically affects IPoIB interfaces in a bond if you do a
down/up cycle on the bond post-boot (during boot, the bonding module
is loaded prior to the 8021q module, so everything is fine).
Let me know if further information or testing is needed.
On Thu, Oct 11, 2012 at 10:28 AM, Jon Stanley [off-list ref] wrote:
This specifically affects IPoIB interfaces in a bond if you do a
down/up cycle on the bond post-boot (during boot, the bonding module
is loaded prior to the 8021q module, so everything is fine).
I hate replying to myself, but I've just been shown an instance where
it fails to come up at boot. The configuration involves tagged
Ethernet interfaces *and* IPoIB in a bond (obviously with no VLAN's on
the IPoIB bond), I probably wasn't clear on that in my original mail.
Thu, Oct 11, 2012 at 04:28:40PM CEST, jstanley@rmrf.net wrote:
Since commit cc0e40700656b09d93b062ef6c818aa45429d09a, there is a
problem if you have the 8021q module loaded and you then attempt to
enslave a VLAN challenged interface. This is because VLAN 0 is
automatically added to the bond, and the new bond_vlan_used() function
simply checks for an empty list in bond->vlan_list without taking into
account that VLAN0 might be on the interface.
This specifically affects IPoIB interfaces in a bond if you do a
down/up cycle on the bond post-boot (during boot, the bonding module
is loaded prior to the 8021q module, so everything is fine).
Let me know if further information or testing is needed.
Thanks for the report. I just fixed this by following patch:
http://patchwork.ozlabs.org/patch/191363/