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

Message-ID: <OF3F503F34.0DCEF024-ON88257297.0010A9D5-88257297.00126F62@us.ibm.com>
Date:	Tue, 6 Mar 2007 19:21:30 -0800
From:	David Stevens <dlstevens@...ibm.com>
To:	"Andy Gospodarek" <gospo@...hat.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

 > >    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.]

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.
        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'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.

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