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: <20150310063926.GA1995@nanopsycho.orion>
Date:	Tue, 10 Mar 2015 07:39:26 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	"Arad, Ronen" <ronen.arad@...el.com>
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

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.

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