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
| ||
|
Date: Mon, 30 Mar 2015 17:44:03 -0700 From: Scott Feldman <sfeldma@...il.com> To: "Arad, Ronen" <ronen.arad@...el.com> Cc: Netdev <netdev@...r.kernel.org>, roopa <roopa@...ulusnetworks.com>, Jirí Pírko <jiri@...nulli.us>, Guenter Roeck <linux@...ck-us.net>, Florian Fainelli <f.fainelli@...il.com> Subject: Re: [PATCH net-next 11/18] switchdev: remove old netdev_switch_port_bridge_setlink On Mon, Mar 30, 2015 at 5:08 PM, Arad, Ronen <ronen.arad@...el.com> wrote: > > >>-----Original Message----- >>From: Scott Feldman [mailto:sfeldma@...il.com] >>Sent: Monday, March 30, 2015 2:28 PM >>To: Arad, Ronen >>Cc: roopa; Netdev; Jirí Pírko; Guenter Roeck; Florian Fainelli >>Subject: Re: [PATCH net-next 11/18] switchdev: remove old >>netdev_switch_port_bridge_setlink >> >>On Mon, Mar 30, 2015 at 1:46 PM, Arad, Ronen <ronen.arad@...el.com> wrote: >>> >>> >>>>-----Original Message----- >>>>From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org] On >>>>Behalf Of Scott Feldman >>>>Sent: Monday, March 30, 2015 1:20 PM >>>>To: roopa >>>>Cc: Netdev; Jiří Pírko; Guenter Roeck; Florian Fainelli >>>>Subject: Re: [PATCH net-next 11/18] switchdev: remove old >>>>netdev_switch_port_bridge_setlink >>>> >>>>On Mon, Mar 30, 2015 at 6:23 AM, roopa <roopa@...ulusnetworks.com> wrote: >>>>> On 3/30/15, 1:40 AM, sfeldma@...il.com wrote: >>>>>> >>>>>> From: Scott Feldman <sfeldma@...il.com> >>>>>> >>>>>> New attr-based bridge_setlink can recurse lower devs and recover on err, >>>>>> so >>>>>> remove old wrapper. Also, restore br_setlink back to original and don't >>>>>> call >>>>>> into SELF port driver. rtnetlink.c:bridge_setlink already does a call >>>>>> into >>>>>> port driver for SELF. >>>>>> >>>>>> Signed-off-by: Scott Feldman <sfeldma@...il.com> >>>>> >>>>> removing this now requires every vlan add to be a two step process, why ? >>>> >>>>No, that's not true. You want to use >>>>ndo_vlan_rx_add_vid/ndo_vlan_rx_kill_vid in your port driver, and then >>>>using either vlan driver standalone or the bridge driver vlan support >>>>will work. >>>> >>>>Try it. Implement ndo_vlan_rx_add_vid in your port driver and verify >>>>you get called to add VLAN to port with either: >>>> >>>> bridge vlan add dev swp1 vid 10 >>>> >>>> -or- >>>> >>>> vconfig add swp1 10 >>>> >>>>Same for deleting a VLAN, either of these two commands call into the >>>>port driver ndo_vlan_rx_kill_vid: >>>> >>>> bridge vlan del dev swp1 vid 10 >>>> >>>> -or- >>>> >>>> vconfig rem swp1 10 >>>> >>>> >>>>> bridge vlan add dev swp1 vid 10 >>>>> bridge vlan add dev swp1 vid 10 self >>>> >>>>Not necessary. The first command is sufficient if using >>>>ndo_vlan_rx_add_vid. >>> >>> This is not sufficient for VLAN filtering. Ndo_vlan_rx_add_vid does not >>> provide the vinfo flags PVID and UNTAGGED. Therefore it is not >>> an adequate replacement for propagating setlink/dellink messages to the >>> swithport driver or an alternative via swdev_attr. >> >>Glad you bring that point up. I think these can get cast as port >>attrs and set using swdev_attr. This is something swdev attr should >>open up is allowing more settings to be pushed down to port driver. >>I'll look into this one and include it with v2. > > It could be beneficial to build extensibility into swdev_attr. > An experimenter attribute designed to carry arbitrary data could allow > for passing new attributes and implementation specific attributes > without affecting any existing switchdev driver: > > enum swdev_attr_id { > SWDEV_ATTR_UNDEFINED, > SWDEV_ATTR_EXPERIMENTER, > SWDEV_ATTR_PORT_PARENT_ID, > SWDEV_ATTR_PORT_STP_STATE, > }; > > > struct swdev_experimenter_attr { > u32 exp_id; /* - MSB 0: low-order bytes are IEEE OUI */ > /* - MSB != 0: reserved for netdev */ > u32 exp_attr; > u16 exp_attr_size; > const void *exp_attr_data; > } > > struct swdev_attr { > enum swdev_attr_id attr; > u32 flags; > > union { > struct netdev_phys_item_id ppid; /* PORT_PARENT_ID */ > u8 stp_state; /* PORT_STP_STATE */ > unsigned long brport_flags; /* PORT_BRIDGE_FLAGS */ > /* netdev defined attributes abobe this line */ > struct swdev_experimenter_attr exp_attr; > }; I'm scared of void *'s. How would this be used? Maybe an example to illustrate the use-case would help. -- 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
Powered by blists - more mailing lists