netdev - Re: [PATCH]: net/bonding: Enable to change device type before enslaving

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]

Date:	Wed, 16 Apr 2008 12:27:46 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	Moni Shoua <monis@...taire.com>
cc:	netdev <netdev@...r.kernel.org>, Olga Stern <olgas@...taire.com>,
	Or Gerlitz <ogerlitz@...taire.com>
Subject: Re: [PATCH]: net/bonding: Enable to change device type before enslaving 

Moni Shoua <monis@...taire.com> wrote:

>> 	Does this mean that the automatic selection on first enslavement
>> is no longer needed, and all setting of the type for IB devices must
>> occur prior to first enslavement?
>> 
>> 	Or is this more of a special case for some devices, and the
>> automatic selection is still correct for most cases?
>> 
>
>I think that the later is closer to the truth. 
>The goal is to modify the bonding module to work with IPoIB slaves but
>with as small as possible changes to what already exists.
>
>In details, the bonding net device device gets its type by
>ether_setup(), which runs for all types of slaves and I don't see a way
>to change that.  However, bonding master for IPoIB slaves requires a
>different device type setting before it comes up for some OSs (redhat 4
>for instance). On other OSs I don't see the problem and I guess that
>this is because master becomes up only after it has slaves.

	If I'm reading the above correctly, then this type selection is
only needed for Red Hat 4 (or, really, versions of bonding prior to when
the bonding master started to set its carrier state based upon the state
of the slaves), correct?

	If that's the case, then is this patch is fixing a problem that
doesn't exist in the mainline?  If this isn't a problem with the current
driver (where "current" here seems to be bonding 3.0.3 and later, which
is about two years old), I don't see why it should go into the mainline.

	Am I misunderstanding something?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@...ibm.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