netdev - RE: [PATCH net-next] rocker: check for BRIDGE_FLAGS

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: <E4CD12F19ABA0C4D8729E087A761DC35067E7016@ORSMSX101.amr.corp.intel.com>
Date:	Tue, 10 Mar 2015 08:02:00 +0000
From:	"Arad, Ronen" <ronen.arad@...el.com>
To:	Jiri Pirko <jiri@...nulli.us>
CC:	Netdev <netdev@...r.kernel.org>,
	Roopa Prabhu <roopa@...ulusnetworks.com>,
	Scott Feldman <sfeldma@...il.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: RE: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
 setlink handler



>-----Original Message-----
>From: Jiri Pirko [mailto:jiri@...nulli.us]
>Sent: Tuesday, March 10, 2015 6:39 AM
>To: Arad, Ronen
>Cc: Netdev; Roopa Prabhu; Scott Feldman; David S. Miller
>Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
>setlink handler
>
>Tue, Mar 10, 2015 at 01:51:51AM CET, ronen.arad@...el.com wrote:
>>
>>
>>>-----Original Message-----
>>>From: Jiri Pirko [mailto:jiri@...nulli.us]
>>>Sent: Monday, March 09, 2015 4:08 PM
>>>To: Arad, Ronen
>>>Cc: Roopa Prabhu; Scott Feldman; Netdev; David S. Miller
>>>Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in bridge
>>>setlink handler
>>>
>>>Mon, Mar 09, 2015 at 04:59:13PM CET, ronen.arad@...el.com wrote:
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
>On
>>>>>Behalf Of Jiri Pirko
>>>>>Sent: Monday, March 09, 2015 6:41 AM
>>>>>To: Roopa Prabhu
>>>>>Cc: Scott Feldman; Netdev; David S. Miller
>>>>>Subject: Re: [PATCH net-next] rocker: check for BRIDGE_FLAGS_SELF in
>bridge
>>>>>setlink handler
>>>>>
>>>>>Mon, Mar 09, 2015 at 01:12:47AM CET, roopa@...ulusnetworks.com wrote:
>>>>>>On Sun, Mar 8, 2015 at 4:17 PM, Scott Feldman <sfeldma@...il.com> wrote:
>>>>>>
>>>>>>> On Sun, Mar 8, 2015 at 7:19 AM, roopa <roopa@...ulusnetworks.com>
>wrote:
>>>>>>> > On 3/6/15, 1:52 AM, Scott Feldman wrote:
>>>>>>>
>>[cut]
>>>>>
>>>>It would be nice to have switch driver implementation that could work
>>>>Consistently with and without the bridge driver. I expect use case where a
>>>bridge is only used when L3 is needed or to leverage L2 protocols that are
>>>implemented by the bridge driver (e.g. STP, IGMP snooping).
>>>>
>>>>If my driver can process setlink requests using SELF flag today, I'd like
>it
>>>>to work the same when setlink is propagated down from a bridge master or
>>>>from a team/bond master.
>>>
>>>I just want to note that the name of the op is "ndo_bridge_setlink" and
>>>it is specific for in-bridge use. Using it for team/bond seems very
>>>wrong to me.
>>>
>>
>>This propagation from master to its slaves is in a recently applied patch.
>>Are you suggesting reverting the patch which added
>>ndo_dflt_netdev_switch_port_bridge_setlink function which is set as the
>>ndo_bridge_setlink of both team and bond drivers?
>
>I'm not suggesting such thing. Proparation is correct. Origination is
>not. That was my point.
>
I'd like to make sure I understand your position. If only propagation is
correct, it would mean that a bridge device is always required for VLAN
filtering configuration.
This also mean that targeting "bridge vlan add vid VLAN-ID dev DEVNAME self"
to DEVNAME of a switch port type or team/bond is incorrect.
If this position is accepted, it would be best to enforce it, possibly in
rtnl_bridge_setlink().
My recollection is that others asked to preserve use-cases where SELF flag
is used for targeting port devices directly without using a bridge device.
>>
>>Would renaming this NDO to "ndo_master_setlink" address your concern?
>>It could clarify that this ndo deals with master devices and is not limited
>>To just bridge driver.
>
>Renaming ndo is not enough.... You would have to do much more.
>
>>
>>My interest here is the VLAN filtering policy which is provisioned using the
>>IFLA_AF_SPEC nested attribute of RTM_SETLINK command in PF_BRIDGE family.
>>VLAN policy is something that is common to Ethernet ports (physical or
>logical),
>>VLAN-aware bridge, or team/bond ports.
>>
>>It is a reasonable expectation of users to use the team/bond as target for
>>any configuration that has to be mirrored to all of their enslaved ports.
>>
>>[cut]
>>>>>--
>>>>>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