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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Mar 2012 09:38:03 -0400 From: Andy Gospodarek <gospo@...hat.com> To: Jay Vosburgh <fubar@...ibm.com> Cc: Weiping Pan <panweiping3@...il.com>, Andy Gospodarek <andy@...yhouse.net>, "open list:BONDING DRIVER" <netdev@...r.kernel.org>, open list <linux-kernel@...r.kernel.org> Subject: Re: [PATCH net V3] bonding: send igmp report for its master On Thu, Mar 15, 2012 at 08:43:19PM -0700, Jay Vosburgh wrote: > Weiping Pan <panweiping3@...il.com> wrote: > > >Liang Zheng(lzheng@...hat.com) found that in the following topo, > >bonding does not send igmp report when we trigger a fail-over of bonding. > > > >eth0-- > > |-- bond0 -- br0 > >eth1-- > > > >modprobe bonding mode=1 miimon=100 resend_igmp=10 > >ifconfig bond0 up > >ifenslave bond0 eth0 eth1 > > > >brctl addbr br0 > >ifconfig br0 192.168.100.2/24 up > >brctl addif br0 bond0 > > > >Add 192.168.100.2(br0) into a multicast group, like 224.10.10.10, > >then trigger a fali-over in bonding. > >You can see that parameter "resend_igmp" does not work. > > > >The reason is that when we add br0 into a multicast group, > >it does not propagate multicast knowledge down to its ports. > > > >If we choose to propagate multicast knowledge down to all ports for bridge, > >then we have to track every change that is done to bridge, and keep a backup > >for all ports. It is hard to track, I think. > > > >Instead I choose to modify bonding to send igmp report for its master. > > > >Changelog: > >V2: correct comments > >V3: move this check into bond_resend_igmp_join_requests() > > > >Signed-off-by: Weiping Pan <panweiping3@...il.com> > >--- > > drivers/net/bonding/bond_main.c | 14 +++++++++++--- > > 1 files changed, 11 insertions(+), 3 deletions(-) > > > >diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c > >index 435984a..037fdd3 100644 > >--- a/drivers/net/bonding/bond_main.c > >+++ b/drivers/net/bonding/bond_main.c > >@@ -766,18 +766,26 @@ static void __bond_resend_igmp_join_requests(struct net_device *dev) > > */ > > static void bond_resend_igmp_join_requests(struct bonding *bond) > > { > >- struct net_device *vlan_dev; > >+ struct net_device *bond_dev, *vlan_dev, *master_dev; > > struct vlan_entry *vlan; > > > > read_lock(&bond->lock); > > > >+ bond_dev = bond->dev; > >+ > > /* rejoin all groups on bond device */ > >- __bond_resend_igmp_join_requests(bond->dev); > >+ __bond_resend_igmp_join_requests(bond_dev); > >+ > >+ /* rejoin all groups on its master */ > >+ master_dev = bond_dev->master; > >+ if (unlikely(master_dev)) { > >+ __bond_resend_igmp_join_requests(master_dev); > >+ } > > Will this do the right thing if the master is not a bridge? > Granted, right now the only other possible master is a team (since > bonding will not enslave itself), but is this generically safe and > desirable for any possible master_dev? > I agree with Jay. You should also check the private flags to see if IFF_BRIDGE_PORT is set. -- 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/
Powered by blists - more mailing lists