netdev - Re: [Bonding-devel] [PATCH 3/3] bonding: Improve IGMP join processing

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] [day] [month] [year] [list]

Message-ID: <20070309165344.GA29496@gospo.rdu.redhat.com>
Date:	Fri, 9 Mar 2007 11:53:45 -0500
From:	Andy Gospodarek <andy@...yhouse.net>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	Andy Gospodarek <andy@...yhouse.net>,
	bonding-devel@...ts.sourceforge.net,
	Brian Haley <brian.haley@...com>, fubar@...ux.vnet.ibm.com,
	netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: [Bonding-devel] [PATCH 3/3] bonding: Improve IGMP join processing

On Tue, Mar 06, 2007 at 07:21:30PM -0800, David Stevens wrote:
>  > >    Marking the master down would, I believe, issue notifiers that
> > > the device has gone down.  Various things, network manager sort of
> > > applications in particular, listen to those, so I'm not sure it's a 
> good
> > > idea.  I think there are other side effects as well, I'm thinking it
> > > would flush routes associated with the interface as well.
> 
> [BTW, you can call ip_mc_down()/ip_mc_up() directly w/o getting there
>         from the notifiers -- then no side-effects.]
> 

While this might seem like a nice solution if we think only about what
would cause the smallest change to igmp.c (since you just need to add a
small patch to export additional symbols), I shudder to think about the
disruption that this could cause in the network in some cases.

> Andy Gospodarek wrote:
> > 
> > I agree with Jay here.  I hate that bonding has to have so much
> > knowledge about upper layer protocols, but for the ones that are
> > stateful like IGMP we will need fixes like the one proposed.
> 
>         I have no problem with bonding having knowledge of ULP's (I
> don't like it, but I don't have to look at it :-) ), but the
> patch is doing it the other way around. What I don't like about the
> proposed patch is that it's adding knowledge of bonding to IGMP.

I disagree with this statement.  Why does adding an extra function to
aide in the transmission of additional igmp joins cause igmp to have
knowledge of bonding?

>         And IGMP does work fine in this case, w/o flooding or the
> proposed patch. It just has the risk of losing multicast packets
> during one query interval, and that only happens if you're
> using a switch that does IGMP snooping.

I feel like igmp snooping is a pretty widely used feature and I would
guess that it is used by anyone doing a/b bonding that has concerns
about igmp failover.

>         I'd like the patch a lot better if it were basicly this:
> 
> mc_bond_fudge(void)
> {
>         ip_mc_down(masterdev);
> /*do whatever you need to do to switch the slave */
>         ip_mc_up(masterdev);
> }
> 
>         That doesn't go through the notifier chain, uses existing
> functions, doesn't have any refcnt issues, and most importantly
> could/should reside in a bonding source file and not in igmp.c. :-)
>         But RTNL is required whether you use up/down or roll your
> own variant, so it sounds like you have other issues to resolve too.

The RTNL stuff would be all done work if Jay would just accept my
workqueue patch.  ;-)

> 
>                                                         +-DLS
> 
> 
> -
> 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
-
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