netdev - Re: [PATCH net-next 5/5] rocker: remove support for legacy VLAN ndo ops

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:	Thu, 11 Jun 2015 09:00:06 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	David Miller <davem@...emloft.net>,
	Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
	Netdev <netdev@...r.kernel.org>,
	Jiří Pírko <jiri@...nulli.us>,
	"simon.horman@...ronome.com" <simon.horman@...ronome.com>
Subject: Re: [PATCH net-next 5/5] rocker: remove support for legacy VLAN ndo
 ops

Full quote below. So what is the consensus on this topic?
I read the emails but i dont see a resolution.

cheers,
jamal

On 06/03/15 08:08, Jamal Hadi Salim wrote:
> On 06/02/15 10:30, Scott Feldman wrote:
>> On Tue, Jun 2, 2015 at 4:43 AM, Jamal Hadi Salim <jhs@...atatu.com>
>> wrote:
>>> On 06/02/15 03:10, Scott Feldman wrote:
>>>
>
>>> Question to ask when looking at something of this nature:
>>> Will it work with no suprises if you used today's unmodified app?
>>> The default behavior shouldnt change and unfortunately it does here.
>>
>> The default behavior does change, yes, but there shouldn't be any
>> surprises even if using today's unmodified app.
>
> [..]
>
> [....]
>
>>
>> Ha, you're giving the behavior for "bridge fdb" command, where self is
>> the default.
>>
>
> Yes, sorry ;->
>
>> For "bridge link" and "bridge vlan", the default is master.  The user
>> must explicitly specify "self" to act on the device side of the port.
>>
>
>
> Not sure what "device side of the port" is intended to mean. But:
> iproute2, user can specify device is either the bridge or bridge port.
> I think that is the key.
> This is used in combination with the self/master flags to decide
> behavior in the kernel.
> Summary, assuming flag bits master:self
>
> user setting: 00 (none set - which is default iproute2 behavior).
> Kernel behavior:
> if (bridge port targeted)
>          sets the vlan bitmap on the bridge port.
> else
>          sets the vlan bitmap on the bridge.
>
> ******* Above is what we want to maintain unchanged.
> If you are saying it doesnt change, then we are fine.
>
> user setting: 01 (self on)
> kernel behavior: no difference from default
>
> user setting: 1x (master on, self doesnt matter)
> kernel behavior:
> if (bridge port targeted)
>          sets the bitmap on the bridge port.
>          sets the bitmap on the bridge as well. <--------
> else
>          sets the bitmap on the bridge.
>
>
> BTW: given the vlan change are reflected from the bowels of
> br_vlan_info() - is it redundant there is a call in br_afset
> afterwards which says something like
> "if master is set and target is bridge port then call hardware
> setting thing"?
>
> dont have much time - so i may be confusing something.
>
>> It's unfortunate the iproute2 defaults aren't consistent between
>> commands.  Maybe someone knows the history here and can explain.
>>
>
> Not sure. Too many cooks with specific use cases? There are many
> thing in bridge that i wish were different.
> Unfortunately when things get to this level Dave's famous "a horse has
> left the barn"  principle applies. Despite my whining, over time,
> even shit doesnt smell anymore. I almost feel we need an
> ABI police force (refer to Jiri's talk at netconf).
> It is much easier to fix kernel changes.
>
> cheers,
> jamal

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