Re: [Bridge] [PATCH net-next v3 5/5] selftests: forwarding: tests of locked port feature

On 18/02/2022 17:51, Hans Schultz wrote: > These tests check that the basic locked port feature works, so that no 'host' > can communicate (ping) through a locked port unless the MAC address of the > 'host' interface is in the forwarding database of the bridge. > > Signed-off-by: Hans Schultz >

Re: [Bridge] [PATCH net-next v3 2/5] net: bridge: Add support for offloading of locked port flag

On 18/02/2022 17:51, Hans Schultz wrote: > Various switchcores support setting ports in locked mode, so that > clients behind locked ports cannot send traffic through the port > unless a fdb entry is added with the clients MAC address. > > Signed-off-by: Hans Schultz > --- >

Re: [Bridge] [PATCH net-next v3 1/5] net: bridge: Add support for bridge port in locked mode

On 18/02/2022 17:51, Hans Schultz wrote: > In a 802.1X scenario, clients connected to a bridge port shall not > be allowed to have traffic forwarded until fully authenticated. > A static fdb entry of the clients MAC address for the bridge port > unlocks the client and allows bidirectional

Re: [Bridge] [RFC net-next 0/9] net: bridge: vlan: Multiple Spanning Trees

On 16/02/2022 17:56, Tobias Waldekranz wrote: > On Wed, Feb 16, 2022 at 17:28, Nikolay Aleksandrov wrote: >> On 16/02/2022 15:29, Tobias Waldekranz wrote: >>> The bridge has had per-VLAN STP support for a while now, since: >>> >>>

Re: [Bridge] [RFC net-next 0/9] net: bridge: vlan: Multiple Spanning Trees

On 16/02/2022 15:29, Tobias Waldekranz wrote: > The bridge has had per-VLAN STP support for a while now, since: > > https://lore.kernel.org/netdev/20200124114022.10883-1-niko...@cumulusnetworks.com/ > > The current implementation has some problems: > > - The mapping from VLAN to STP state is

Re: [Bridge] [PATCH net v2] net: bridge: multicast: notify switchdev driver whenever MC processing gets disabled

On 15/02/2022 18:53, Oleksandr Mazur wrote: > Whenever bridge driver hits the max capacity of MDBs, it disables > the MC processing (by setting corresponding bridge option), but never > notifies switchdev about such change (the notifiers are called only upon > explicit setting of this option,

Re: [Bridge] [PATCH] net: bridge: multicast: notify switchdev driver whenever MC processing gets disabled

(+CC Ido) On 15/02/2022 07:13, Jakub Kicinski wrote: > On Fri, 11 Feb 2022 15:14:26 +0200 Oleksandr Mazur wrote: >> Whenever bridge driver hits the max capacity of MDBs, it disables >> the MC processing (by setting corresponding bridge option), but never >> notifies switchdev about such change

[Bridge] [PATCH net] MAINTAINERS: bridge: update my email

I'm leaving NVIDIA and my email account will stop working in a week, update it with my personal account. Signed-off-by: Nikolay Aleksandrov --- Routing through -net to get merged in net-next so there are no discrepancies. It applies also to net-next if that is preferred. MAINTAINERS | 2 +- 1

Re: [Bridge] [PATCH] net: bridge: Slightly optimize br_stp_change_bridge_id()

On 12/02/2022 11:58, Christophe JAILLET wrote: > ether_addr_equal_64bits() can easy be used in place of ether_addr_equal() > here. > Padding in the 'net_bridge_port' structure is already there because it is a > huge structure and the required fields are not at the end. > 'oldaddr' is local to the

Re: [Bridge] [PATCH net-next 2/4] net: bridge: dsa: Add support for offloading of locked port flag

On 07/02/2022 12:07, Hans Schultz wrote: > Various switchcores support setting ports in locked mode, so that > clients behind locked ports cannot send traffic through the port > unless a fdb entry is added with the clients MAC address. > > Among the switchcores that support this feature is the

Re: [Bridge] [PATCH] net: bridge: vlan: fix memory leak in __allowed_ingress

On 27/01/2022 09:49, Tim Yi wrote: > When using per-vlan state, if vlan snooping and stats are disabled, > untagged or priority-tagged ingress frame will go to check pvid state. > If the port state is forwarding and the pvid state is not > learning/forwarding, untagged or priority-tagged frame

[Bridge] [PATCH net] net: bridge: vlan: fix single net device option dumping

When dumping vlan options for a single net device we send the same entries infinitely because user-space expects a 0 return at the end but we keep returning skb->len and restarting the dump on retry. Fix it by returning the value from br_vlan_dump_dev() if it completed or there was an error. The

Re: [Bridge] [RFC bpf-next 1/2] net: bridge: add unstable br_fdb_find_port_from_ifindex helper

On 26/01/2022 14:50, Toke Høiland-Jørgensen wrote: > Nikolay Aleksandrov writes: > >> On 26/01/2022 13:27, Lorenzo Bianconi wrote: On 24/01/2022 19:20, Lorenzo Bianconi wrote: > Similar to bpf_xdp_ct_lookup routine, introduce > br_fdb_find_port_from_ifindex unstable helper in order

Re: [Bridge] [RFC bpf-next 1/2] net: bridge: add unstable br_fdb_find_port_from_ifindex helper

On 26/01/2022 13:27, Lorenzo Bianconi wrote: >> On 24/01/2022 19:20, Lorenzo Bianconi wrote: >>> Similar to bpf_xdp_ct_lookup routine, introduce >>> br_fdb_find_port_from_ifindex unstable helper in order to accelerate >>> linux bridge with XDP. br_fdb_find_port_from_ifindex will perform a >>>

Re: [Bridge] [PATCH net] net: bridge: vlan: Fix dumping with ifindex

On 25/01/2022 10:24, Nikolay Aleksandrov wrote: > On 25/01/2022 08:19, Benjamin Poirier wrote: >> Specifying ifindex in a RTM_GETVLAN dump leads to an infinite repetition >> of the same entries. netlink_dump() normally calls the dump function >> repeatedly until it returns 0 which

Re: [Bridge] [PATCH net] net: bridge: vlan: Fix dumping with ifindex

On 25/01/2022 08:19, Benjamin Poirier wrote: > Specifying ifindex in a RTM_GETVLAN dump leads to an infinite repetition > of the same entries. netlink_dump() normally calls the dump function > repeatedly until it returns 0 which br_vlan_rtm_dump() never does in > that case. > > Fixes:

Re: [Bridge] [RFC bpf-next 1/2] net: bridge: add unstable br_fdb_find_port_from_ifindex helper

On 24/01/2022 19:20, Lorenzo Bianconi wrote: > Similar to bpf_xdp_ct_lookup routine, introduce > br_fdb_find_port_from_ifindex unstable helper in order to accelerate > linux bridge with XDP. br_fdb_find_port_from_ifindex will perform a > lookup in the associated bridge fdb table and it will return

Re: [Bridge] [PATCH bpf-next v2] net: don't include filter.h from net/sock.h

On 29/12/2021 02:49, Jakub Kicinski wrote: > sock.h is pretty heavily used (5k objects rebuilt on x86 after > it's touched). We can drop the include of filter.h from it and > add a forward declaration of struct sk_filter instead. > This decreases the number of rebuilt objects when bpf.h > is

[Bridge] [PATCH net v2] net: bridge: mcast: fix br_multicast_ctx_vlan_global_disabled helper

We need to first check if the context is a vlan one, then we need to check the global bridge multicast vlan snooping flag, and finally the vlan's multicast flag, otherwise we will unnecessarily enable vlan mcast processing (e.g. querier timers). Fixes: 7b54aaaf53cb ("net: bridge: multicast: add

[Bridge] [PATCH net] net: bridge: mcast: fix br_multicast_ctx_vlan_global_disabled helper

We need to first check if the context is a vlan one, then we need to check the global bridge multicast vlan snooping flag, and finally the vlan's multicast flag, otherwise we will unnecessarily enable vlan mcast processing (e.g. querier timers). Fixes: 7b54aaaf53cb ("net: bridge: multicast: add

[Bridge] [PATCH net 2/2] net: bridge: mcast: add and enforce startup query interval minimum

As reported[1] if startup query interval is set too low in combination with large number of startup queries and we have multiple bridges or even a single bridge with multiple querier vlans configured we can crash the machine. Add a 1 second minimum which must be enforced by overwriting the value

[Bridge] [PATCH net 0/2] net: bridge: mcast: add and enforce query interval minimum

Hi, This set adds and enforces 1 second minimum value for bridge multicast query and startup query intervals in order to avoid rearming the timers too often which could lock and crash the host. I doubt anyone is using such low values or anything lower than 1 second, so it seems like a good

[Bridge] [PATCH net 1/2] net: bridge: mcast: add and enforce query interval minimum

As reported[1] if query interval is set too low and we have multiple bridges or even a single bridge with multiple querier vlans configured we can crash the machine. Add a 1 second minimum which must be enforced by overwriting the value if set lower (i.e. without returning an error) to avoid

Re: [Bridge] [PATCH net-next] net: bridge: Get SIOCGIFBR/SIOCSIFBR ioctl working in compat mode

On 24/12/2021 13:46, Remi Pommarel wrote: > In compat mode SIOC{G,S}IFBR ioctls were only supporting > BRCTL_GET_VERSION returning an artificially version to spur userland > tool to use SIOCDEVPRIVATE instead. But some userland tools ignore that > and use SIOC{G,S}IFBR unconditionally as seen with

Re: [Bridge] [PATCH net] net: bridge: fix ioctl old_deviceless bridge argument

On 22/12/2021 21:13, Remi Pommarel wrote: > Commit 561d8352818f ("bridge: use ndo_siocdevprivate") changed the > source and destination arguments of copy_{to,from}_user in bridge's > old_deviceless() from args[1] to uarg breaking SIOC{G,S}IFBR ioctls. > > Commit cbd7ad29a507 ("net: bridge: fix

Re: [Bridge] [PATCH] net/bridge: replace simple_strtoul to kstrtol

On 24/11/2021 06:13, Jakub Kicinski wrote: > On Mon, 22 Nov 2021 12:17:39 +0200 Nikolay Aleksandrov wrote: >>> # ip link add name br0 type bridge vlan_filtering 1 >>> # echo "0x88a8" > /sys/class/net/br0/bridge/vlan_protocol >>> bash: echo: write error: Invalid argument >> >> Good catch, Bernard

Re: [Bridge] [PATCH] net/bridge: replace simple_strtoul to kstrtol

On 22/11/2021 12:04, Ido Schimmel wrote: > On Thu, Nov 18, 2021 at 06:06:42PM -0800, Bernard Zhao wrote: >> simple_strtoull is obsolete, use kstrtol instead. >> >> Signed-off-by: Bernard Zhao >> --- >> net/bridge/br_sysfs_br.c | 7 +++ >> 1 file changed, 3 insertions(+), 4 deletions(-) >> >>

Re: [Bridge] [PATCH] net: bridge: Slightly optimize 'find_portno()'

On 14/11/2021 21:02, Christophe JAILLET wrote: > The 'inuse' bitmap is local to this function. So we can use the > non-atomic '__set_bit()' to save a few cycles. > > While at it, also remove some useless {}. > > Signed-off-by: Christophe JAILLET > --- > net/bridge/br_if.c | 8 > 1

Re: [Bridge] [PATCH net] selftests: net: bridge: update IGMP/MLD membership interval value

On 29/10/2021 13:53, Nikolay Aleksandrov wrote: > From: Nikolay Aleksandrov > > When I fixed IGMPv3/MLDv2 to use the bridge's multicast_membership_interval > value which is chosen by user-space instead of calculating it based on > multicast_query_interval and multicast_query_response_interval I

Re: [Bridge] [PATCH net v2] net: bridge: fix uninitialized variables when BRIDGE_CFM is disabled

On 28/10/2021 18:58, Ivan Vecera wrote: > Function br_get_link_af_size_filtered() calls br_cfm_{,peer}_mep_count() > that return a count. When BRIDGE_CFM is not enabled these functions > simply return -EOPNOTSUPP but do not modify count parameter and > calling function then works with

Re: [Bridge] [PATCH net] net: bridge: fix uninitialized variables when BRIDGE_CFM is disabled

On 27/10/2021 16:49, Ivan Vecera wrote: > Function br_get_link_af_size_filtered() calls br_cfm_{,peer}_mep_count() > but does not check their return value. When BRIDGE_CFM is not enabled > these functions return -EOPNOTSUPP but do not modify count parameter. > Calling function then works with

Re: [Bridge] [PATCHv2 net] net: bridge: mcast: QRI must be less than QI

On 20/10/2021 15:10, Hangbin Liu wrote: > On Wed, Oct 20, 2021 at 06:19:25PM +0800, Hangbin Liu wrote: >> On Wed, Oct 20, 2021 at 12:49:17PM +0300, Nikolay Aleksandrov wrote: >>> Nacked-by: Nikolay Aleksandrov >>> >>> I think we just discussed this a day ago? It is the same problem - >>> while we

Re: [Bridge] [PATCHv2 net] net: bridge: mcast: QRI must be less than QI

On 20/10/2021 05:40, Hangbin Liu wrote: > Based on RFC3376 8.3: > The number of seconds represented by the [Query Response Interval] > must be less than the [Query Interval]. > > Fixes: d902eee43f19 ("bridge: Add multicast count/interval sysfs entries") > Signed-off-by: Hangbin Liu > --- >

Re: [Bridge] [PATCH net] net: bridge: mcast: Do not allow users to set IGMP counter/timer to zero

On 19/10/2021 08:43, Hangbin Liu wrote: > Hi Nikolay, > > On Mon, Oct 18, 2021 at 01:28:14PM +0300, Nikolay Aleksandrov wrote: >> On 18/10/2021 11:26, Hangbin Liu wrote: >>> There is no meaning to set an IGMP counter/timer to 0. Or it will cause >>> unexpected behavior. E.g. if set

Re: [Bridge] [PATCH net] net: bridge: mcast: Do not allow users to set IGMP counter/timer to zero

On 18/10/2021 11:26, Hangbin Liu wrote: > There is no meaning to set an IGMP counter/timer to 0. Or it will cause > unexpected behavior. E.g. if set multicast_membership_interval to 0, > bridge will remove the mdb immediately after adding. > > Fixes: 79b859f573d6 ("bridge: netlink: add support

Re: [Bridge] [PATCH v3 net-next] net: make use of helper netif_is_bridge_master()

On 16/10/2021 14:21, Kyungrok Chung wrote: > Make use of netdev helper functions to improve code readability. > Replace 'dev->priv_flags & IFF_EBRIDGE' with netif_is_bridge_master(dev). > > Signed-off-by: Kyungrok Chung > --- > > v1->v2: > - Apply fixes to batman-adv, core too. > > v2->v3: >

Re: [Bridge] [PATCH v2 net-next] net: make use of helper netif_is_bridge_master()

On 16/10/2021 08:04, Kyungrok Chung wrote: > Make use of netdev helper functions to improve code readability. > Replace 'dev->priv_flags & IFF_EBRIDGE' with netif_is_bridge_master(dev). > > Signed-off-by: Kyungrok Chung > --- > > v1->v2: > - Apply fixes to batman-adv, core too. > >

Re: [Bridge] [PATCH net-next v4 10/15] net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report

On 15/10/2021 09:36, Hangbin Liu wrote: > On Fri, Oct 15, 2021 at 10:52:00AM +0800, Hangbin Liu wrote: >>> - mod_timer(>timer, now + br->multicast_membership_interval); >>> + if (igmpv2_mldv1) >>> + mod_timer(>timer, now + br->multicast_membership_interval); >> >> Hi Nikolay, >> >>

Re: [Bridge] [PATCH net-next] net: bridge: make use of helper netif_is_bridge_master()

On 12/10/2021 17:18, Kyungrok Chung wrote: > Make use of netdev helper functions to improve code readability. > Replace 'dev->priv_flags & IFF_EBRIDGE' with netif_is_bridge_master(dev). > > Signed-off-by: Kyungrok Chung > --- > net/bridge/br.c | 4 ++-- > net/bridge/br_fdb.c

Re: [Bridge] [PATCH net] net: bridge: mcast: Associate the seqcount with its protecting lock.

On 28/09/2021 17:10, Sebastian Andrzej Siewior wrote: > From: Thomas Gleixner > > The sequence count bridge_mcast_querier::seq is protected by > net_bridge::multicast_lock but seqcount_init() does not associate the > seqcount with the lock. This leads to a warning on PREEMPT_RT because >

Re: [Bridge] [syzbot] KASAN: slab-out-of-bounds Read in add_del_if

On 03/09/2021 14:42, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not trigger any > issue: > > Reported-and-tested-by: syzbot+24b98616278c31afc...@syzkaller.appspotmail.com > > Tested on: > > commit: d15040a3 Merge branch 'bridge-ioctl-fixes'

Re: [Bridge] [syzbot] KASAN: slab-out-of-bounds Read in add_del_if

On 03/09/2021 12:03, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:3bdc70669eb2 Merge branch 'devlink-register' That is an older commit, before my ioctl fixes. I think this issue has been already fixed by my patch-set: commit d15040a33883 Merge:

Re: [Bridge] [PATCH v3 net-next] net: bridge: change return type of br_handle_ingress_vlan_tunnel

On 23/08/2021 13:21, Kangmin Park wrote: > br_handle_ingress_vlan_tunnel() is only referenced in > br_handle_frame(). If br_handle_ingress_vlan_tunnel() is called and > return non-zero value, goto drop in br_handle_frame(). > > But, br_handle_ingress_vlan_tunnel() always return 0. So, the >

Re: [Bridge] [PATCH v2 net-next] net: bridge: change return type of br_handle_ingress_vlan_tunnel

On 23/08/2021 12:56, Kangmin Park wrote: > br_handle_ingress_vlan_tunnel() is only referenced in > br_handle_frame(). If br_handle_ingress_vlan_tunnel() is called and > return non-zero value, goto drop in br_handle_frame(). > > But, br_handle_ingress_vlan_tunnel() always return 0. So, the >

Re: [Bridge] [PATCH net-next] net: bridge: replace __vlan_hwaccel_put_tag with skb_vlan_push

On 23/08/2021 12:12, Kangmin Park wrote: > 2021년 8월 23일 (월) 오후 6:00, Nikolay Aleksandrov 님이 작성: >> >> On 23/08/2021 09:19, Kangmin Park wrote: >> >> This changes behaviour though, I don't like changing code just for the sake >> of it. >> Perhaps the author had a reason to use hwaccel_put_tag

Re: [Bridge] [PATCH net-next] net: bridge: replace __vlan_hwaccel_put_tag with skb_vlan_push

On 23/08/2021 09:19, Kangmin Park wrote: > br_handle_ingress_vlan_tunnel() is called in br_handle_frame() and > goto drop when br_handle_ingress_vlan_tunnel() return non-zero. > > But, br_handle_ingress_vlan_tunnel() always return 0. So, the goto > routine is currently meaningless. > > However,

Re: [Bridge] [PATCH net-next 4/6] net: bridge: mcast: dump ipv4 querier state

On 16/08/2021 11:33, Dan Carpenter wrote: > Hi Nikolay, > > url: > https://github.com/0day-ci/linux/commits/Nikolay-Aleksandrov/net-bridge-mcast-dump-querier-state/20210813-230258 > base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git >

Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry

On 10/08/2021 13:38, Vladimir Oltean wrote: > On Tue, Aug 10, 2021 at 01:15:32PM +0300, Nikolay Aleksandrov wrote: >> On 10/08/2021 13:09, Vladimir Oltean wrote: >>> On Tue, Aug 10, 2021 at 09:46:34AM +0300, Ido Schimmel wrote: On Mon, Aug 09, 2021 at 04:05:22PM +, Vladimir Oltean wrote:

Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry

On 10/08/2021 13:09, Vladimir Oltean wrote: > On Tue, Aug 10, 2021 at 09:46:34AM +0300, Ido Schimmel wrote: >> On Mon, Aug 09, 2021 at 04:05:22PM +, Vladimir Oltean wrote: >>> On Mon, Aug 09, 2021 at 03:16:40PM +0300, Ido Schimmel wrote: I have at least once selftest where I forgot the

Re: [Bridge] [PATCH net v3] net: bridge: fix memleak in br_add_if()

On 09/08/2021 16:20, Yang Yingliang wrote: > I got a memleak report: > > BUG: memory leak > unreferenced object 0x607ee521a658 (size 240): > comm "syz-executor.0", pid 955, jiffies 4294780569 (age 16.449s) > hex dump (first 32 bytes, cpu 1): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [Bridge] [PATCH net v2] net: bridge: fix memleak in br_add_if()

On 09/08/2021 12:02, Yang Yingliang wrote: > I got a memleak report: > > BUG: memory leak > unreferenced object 0x607ee521a658 (size 240): > comm "syz-executor.0", pid 955, jiffies 4294780569 (age 16.449s) > hex dump (first 32 bytes, cpu 1): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [Bridge] [PATCH net-next 1/3] net: bridge: fix ioctl locking

On 05/08/2021 11:29, Nikolay Aleksandrov wrote: > From: Nikolay Aleksandrov > > Before commit ad2f99aedf8f ("net: bridge: move bridge ioctls out of > .ndo_do_ioctl") the bridge ioctl calls were divided in two parts: > one was deviceless called by sock_ioctl and didn't expect rtnl to be held, >

Re: [Bridge] [PATCH net-next] net: bridge: switchdev: fix incorrect use of FDB flags when picking the dst device

On 02/08/2021 14:36, Vladimir Oltean wrote: > Nikolay points out that it is incorrect to assume that it is impossible > to have an fdb entry with fdb->dst == NULL and the BR_FDB_LOCAL bit in > fdb->flags not set. This is because there are reader-side places that > test_bit(BR_FDB_LOCAL, >flags)

Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry

On 02/08/2021 02:17, Vladimir Oltean wrote: > Currently it is possible to add broken extern_learn FDB entries to the > bridge in two ways: > > 1. Entries pointing towards the bridge device that are not local/permanent: > > ip link add br0 type bridge > bridge fdb add 00:01:02:03:04:05 dev br0

Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry

On 02/08/2021 12:20, Vladimir Oltean wrote: > On Mon, Aug 02, 2021 at 10:42:41AM +0300, Nikolay Aleksandrov wrote: >> On 02/08/2021 02:17, Vladimir Oltean wrote: >>> Currently it is possible to add broken extern_learn FDB entries to the >>> bridge in two ways: >>> >>> 1. Entries pointing towards

Re: [Bridge] [syzbot] possible deadlock in br_ioctl_call

On 01/08/2021 16:14, Hillf Danton wrote: > On Sun, 01 Aug 2021 03:34:24 -0700 >> syzbot found the following issue on: >> >> HEAD commit:3bdc70669eb2 Merge branch 'devlink-register' >> git tree: net-next >> console output: https://syzkaller.appspot.com/x/log.txt?x=11ee370a30 >> kernel

Re: [Bridge] [PATCH net] net: bridge: validate the NUD_PERMANENT bit when adding an extern_learn FDB entry

On 02/08/2021 02:17, Vladimir Oltean wrote: > Currently it is possible to add broken extern_learn FDB entries to the > bridge in two ways: > > 1. Entries pointing towards the bridge device that are not local/permanent: > > ip link add br0 type bridge > bridge fdb add 00:01:02:03:04:05 dev br0

Re: [Bridge] [PATCH net v2 1/2] bridge: implement missing ndo_uninit()

On 08/04/17 16:49, Ido Schimmel wrote: > On Sat, Apr 08, 2017 at 09:30:42AM -0400, Stephen Hemminger wrote: >> On Sat, 8 Apr 2017 14:41:58 +0300 >> wrote: >> >>> static void br_dev_free(struct net_device *dev) >>> { >>> - struct net_bridge *br = netdev_priv(dev); >>> -

Re: [Bridge] [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 18:36, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 18:27:37 +0300 > Nikolay Aleksandrov wrote: > >> On 07/04/17 18:22, Stephen Hemminger wrote: >>> On Fri, 7 Apr 2017 17:19:48 +0300 >>> Nikolay Aleksandrov wrote: >>>

Re: [Bridge] [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 18:22, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 17:19:48 +0300 > Nikolay Aleksandrov wrote: > >> On 07/04/17 17:10, Stephen Hemminger wrote: >>> On Fri, 7 Apr 2017 15:49:15 +0300 >>> wrote: >>> From: Ido Schimmel

Re: [Bridge] [PATCH net] bridge: netlink: register netdevice before executing changelink

On 07/04/17 17:10, Stephen Hemminger wrote: > On Fri, 7 Apr 2017 15:49:15 +0300 > wrote: > >> From: Ido Schimmel >> >> Peter reported a kernel oops when executing the following command: >> >> $ ip link add name test type bridge vlan_default_pvid 1 >> >>

[Bridge] [PATCH net-next 1/2] net: bridge: allow SW learn to take over HW fdb entries

Allow to take over an entry which was previously learned via HW when it shows up from a SW port. This is analogous to how HW takes over SW learned entries already. Suggested-by: Roopa Prabhu Signed-off-by: Nikolay Aleksandrov ---

[Bridge] [PATCH net-next 2/2] net: bridge: allow to add externally learned entries from user-space

The NTF_EXT_LEARNED flag was added for switchdev and externally learned entries, but it can also be used for entries learned via a software in user-space which requires dynamic entries that do not expire. One such case that we have is with quagga and evpn which need dynamic entries but also

[Bridge] [PATCH net-next 0/2] net: bridge: allow user-space to add ext learned entries

Hi, This set adds the ability to add externally learned entries from user-space. For symmetry and proper function we need to allow SW entries to take over HW learned ones (similar to how HW can take over SW entries currently) which is needed for our use case (evpn) where we have pure SW ports and

Re: [Bridge] [PATCH v2] net: bridge: allow IPv6 when multicast flood is disabled

On 01/03/17 11:55, Mike Manning wrote: > Even with multicast flooding turned off, IPv6 ND should still work so > that IPv6 connectivity is provided. Allow this by continuing to flood > multicast traffic originated by us. > > Fixes: b6cb5ac8331b ("net: bridge: add per-port multicast flood flag") >

Re: [Bridge] [PATCH] net: bridge: allow IPv6 when multicast flood is disabled

On 01/03/17 11:57, Mike Manning wrote: > On 28/02/17 09:20, Nikolay Aleksandrov wrote: >> We are aware of this and have discussed it, but I’m not sure this is the >> best way to fix it, >> it will still allow local IPv4 mcast to be flooded on all ports even with >> that flag removed and >> that

Re: [Bridge] [PATCH] net: bridge: allow IPv6 when multicast flood is disabled

> On Feb 27, 2017, at 7:11 PM, Mike Manning wrote: > +CC bridge maintainers > Even with multicast flooding turned off, IPv6 ND should still work so > that IPv6 connectivity is provided. Allow this by continuing to flood > multicast traffic originated by us. And similar

[Bridge] [PATCH net-next 3/3] bridge: fdb: converge fdb_delete_by functions into one

We can simplify the logic of entries pointing to the bridge by converging the fdb_delete_by functions, this would allow us to use the same function for both cases since the fdb's dst is set to NULL if it is pointing to the bridge thus we can always check for a port match. Signed-off-by: Nikolay

[Bridge] [PATCH net-next 1/3] bridge: fdb: converge fdb searching functions into one

Before this patch we had 3 different fdb searching functions which was confusing. This patch reduces all of them to one - fdb_find_rcu(), and two flavors: br_fdb_find() which requires hash_lock and br_fdb_find_rcu which requires RCU. This makes it clear what needs to be used, we also remove two

[Bridge] [PATCH net-next 2/3] bridge: fdb: add proper lock checks in searching functions

In order to avoid new errors add checks to br_fdb_find and fdb_find_rcu functions. The first requires hash_lock, the second obviously RCU. Signed-off-by: Nikolay Aleksandrov --- net/bridge/br_fdb.c | 4 net/bridge/br_private.h | 9 + 2 files

Re: [Bridge] [PATCH net-next] bridge: avoid unnecessary read of jiffies

On 07/02/17 17:46, Stephen Hemminger wrote: > > Jiffies is volatile so read it once. > > Signed-off-by: Stephen Hemminger > --- > net/bridge/br_fdb.c | 6 -- > net/bridge/br_input.c | 6 -- > 2 files changed, 8 insertions(+), 4 deletions(-) > Yep, good

[Bridge] [PATCH net-next] bridge: tunnel: fix attribute checks in br_parse_vlan_tunnel_info

These checks should go after the attributes have been parsed otherwise we're using tb uninitialized. Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support") Reported-by: Colin Ian King Signed-off-by: Nikolay Aleksandrov ---

Re: [Bridge] [PATCH][net-next] net: bridge: remove redundant check to see if err is set

On 07/02/17 11:56, Colin King wrote: > From: Colin Ian King > > The error check on err is redundant as it is being checked > previously each time it has been updated. Remove this redundant > check. > > Detected with CoverityScan, CID#140030("Logically dead code") > >

Re: [Bridge] bridge: per vlan dst_metadata netlink support

On 07/02/17 12:25, Colin Ian King wrote: > Hi, > > Static analysis with CoverityScan on net/bridge/br_netlink_tunnel.c has > picked up and issue where tb[] is being referenced but contains > uninitialized data. > > 222 int br_parse_vlan_tunnel_info(struct nlattr *attr, > 223

Re: [Bridge] [PATCH net-next 0/4] bridge: improve cache utilization

On 04/02/17 22:46, Stephen Hemminger wrote: > On Sat, 4 Feb 2017 18:05:05 +0100 > Nikolay Aleksandrov wrote: > >> Hi all, >> This is the first set which begins to deal with the bad bridge cache >> access patterns. The first patch rearranges the bridge and port

[Bridge] [PATCH net-next 4/4] bridge: fdb: write to used and updated at most once per jiffy

Writing once per jiffy is enough to limit the bridge's false sharing. After this change the bridge doesn't show up in the local load HitM stats. Suggested-by: David S. Miller Signed-off-by: Nikolay Aleksandrov --- net/bridge/br_fdb.c | 3 ++-

Re: [Bridge] [PATCH net-next v5] bridge: multicast to unicast

On 21/01/17 21:01, Linus Lüssing wrote: > From: Felix Fietkau > > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the

Re: [Bridge] [PATCH net-next v4] bridge: multicast to unicast

On 19/01/17 03:45, Linus Lüssing wrote: > From: Felix Fietkau > > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the

[Bridge] [PATCH net-next v3 2/2] net: bridge: add per-port multicast flood flag

Add a per-port flag to control the unknown multicast flood, similar to the unknown unicast flood flag and break a few long lines in the netlink flag exports. Signed-off-by: Nikolay Aleksandrov --- v3: don't change br_auto_mask v2: no change

[Bridge] [PATCH net-next v3 1/2] net: bridge: change unicast boolean to exact pkt_type

Remove the unicast flag and introduce an exact pkt_type. That would help us for the upcoming per-port multicast flood flag and also slightly reduce the tests in the input fast path. Signed-off-by: Nikolay Aleksandrov --- v3: no change v2: make pkt_type an enum as per

[Bridge] [PATCH net-next v3 0/2] net: bridge: add per-port unknown multicast flood control

Hi, The first patch prepares the forwarding path by having the exact packet type passed down so we can later filter based on it and the per-port unknown mcast flood flag introduced in the second patch. It is similar to how the per-port unknown unicast flood flag works. Nice side-effects of patch

Re: [Bridge] [PATCH net] bridge: re-introduce 'fix parsing of MLDv2 reports'

On 31/08/16 14:16, Davide Caratti wrote: > commit bc8c20acaea1 ("bridge: multicast: treat igmpv3 report with > INCLUDE and no sources as a leave") seems to have accidentally reverted > commit 47cc84ce0c2f ("bridge: fix parsing of MLDv2 reports"). This > commit brings back a change to

Re: [Bridge] [PATCH net-next v2 2/2] net: bridge: add per-port multicast flood flag

On 31/08/16 08:02, Nikolay Aleksandrov wrote: > On 31/08/16 03:37, Linus Lüssing wrote: >> On Tue, Aug 30, 2016 at 05:23:08PM +0200, Nikolay Aleksandrov via Bridge >> wrote: >>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c >>> index 1da3221845f1..ed0dd33

[Bridge] [PATCH net] net: bridge: don't increment tx_dropped in br_do_proxy_arp

pskb_may_pull may fail due to various reasons (e.g. alloc failure), but the skb isn't changed/dropped and processing continues so we shouldn't increment tx_dropped. CC: Kyeyoon Park CC: Roopa Prabhu CC: Stephen Hemminger

[Bridge] [PATCH net-next v2 0/2] net: bridge: add per-port unknown multicast flood control

Hi, The first patch prepares the forwarding path by having the exact packet type passed down so we can later filter based on it and the per-port unknown mcast flood flag introduced in the second patch. It is similar to how the per-port unknown unicast flood flag works. Nice side-effects of patch

Re: [Bridge] [PATCH net-next 1/2] net: bridge: change unicast boolean to exact pkt_type

On 30/08/16 17:00, Nikolay Aleksandrov wrote: > On 30/08/16 16:59, Stephen Hemminger wrote: [snip] >>> if (p->state == BR_STATE_LEARNING) >>> goto drop; >>> >>> BR_INPUT_SKB_CB(skb)->brdev = br->dev; >>> >>> - local_rcv = !!(br->dev->flags & IFF_PROMISC); >>> - >>> if

Re: [Bridge] [PATCH net-next 1/2] net: bridge: change unicast boolean to exact pkt_type

On 30/08/16 16:59, Stephen Hemminger wrote: > On Tue, 30 Aug 2016 15:08:58 +0200 > Nikolay Aleksandrov wrote: > >> -if (!is_broadcast_ether_addr(dest) && is_multicast_ether_addr(dest) && >> -br_multicast_rcv(br, p, skb, vid)) >> -goto drop; >>

Re: [Bridge] [PATCH net-next 1/2] net: bridge: change unicast boolean to exact pkt_type

On 30/08/16 16:56, Stephen Hemminger wrote: > On Tue, 30 Aug 2016 15:08:58 +0200 > Nikolay Aleksandrov wrote: > >> /* br_forward.c */ >> +enum { >> +BR_PKT_UNICAST, >> +BR_PKT_MULTICAST, >> +BR_PKT_BROADCAST >> +}; >> int br_dev_queue_push_xmit(struct

[Bridge] [PATCH net-next 2/2] net: bridge: add per-port multicast flood flag

Add a per-port flag to control the unknown multicast flood, similar to the unknown unicast flood flag and break a few long lines in the netlink flag exports. Signed-off-by: Nikolay Aleksandrov --- include/linux/if_bridge.h| 3 ++- include/uapi/linux/if_link.h |

[Bridge] [PATCH net-next 1/2] net: bridge: change unicast boolean to exact pkt_type

Remove the unicast flag and introduce an exact pkt_type. That would help us for the upcoming per-port multicast flood flag and also slightly reduce the tests in the input fast path. Signed-off-by: Nikolay Aleksandrov --- net/bridge/br_device.c | 8

[Bridge] [PATCH net-next 0/2] net: bridge: add per-port unknown multicast flood control

Hi, The first patch prepares the forwarding path by having the exact packet type passed down so we can later filter based on it and the per-port unknown mcast flood flag introduced in the second patch. It is similar to how the per-port unknown unicast flood flag works. Nice side-effects of patch

[Bridge] [PATCH net-next] net: bridge: export also pvid flag in the xstats flags

When I added support to export the vlan entry flags via xstats I forgot to add support for the pvid since it is manually matched, so check if the entry matches the vlan_group's pvid and set the flag appropriately. Signed-off-by: Nikolay Aleksandrov ---

[Bridge] [PATCH net-next 2/2] net: bridge: export vlan flags with the stats

Use one of the vlan xstats padding fields to export the vlan flags. This is needed in order to be able to distinguish between master (bridge) and port vlan entries in user-space when dumping the bridge vlan stats. Signed-off-by: Nikolay Aleksandrov ---

Re: [Bridge] [PATCH net-next 2/4] net: bridge: rearrange flood vs unicast receive paths

> On Jul 15, 2016, at 10:35 AM, Cong Wang wrote: > > On Wed, Jul 13, 2016 at 8:10 PM, Nikolay Aleksandrov > wrote: >> This patch removes one conditional from the unicast path by using the fact >> that skb is NULL only when the packet is

[Bridge] [PATCH net-next 4/4] net: bridge: remove _deliver functions and consolidate forward code

Before this patch we had two flavors of most forwarding functions - _forward and _deliver, the difference being that the latter are used when the packets are locally originated. Instead of all this function pointer passing and code duplication, we can just pass a boolean noting that the packet was

[Bridge] [PATCH net-next 3/4] net: bridge: drop skb2/skb0 variables and use a local_rcv boolean

Currently if the packet is going to be received locally we set skb0 or sometimes called skb2 variables to the original skb. This can get confusing and also we can avoid one conditional on the fast path by simply using a boolean and passing it around. Thanks to Roopa for the name suggestion.

[Bridge] [PATCH net-next 0/4] net: bridge: simplify receive path and consolidate forwarding paths

Hi all, This set tries to simplify the receive and forwarding paths. Patch 01 is a trivial style adjustment, patch 02 removes one conditional from the unicast fast path, patch 03 removes another conditional and more imporantly removes the skb0/skb2 ambiguity about locally receiving the skb and

[Bridge] [PATCH net-next v2 0/2] net: bridge: add support for IGMP/MLD stats

Hi all, This patchset adds support for the new IFLA_STATS_LINK_XSTATS_SLAVE attribute which can be used with RTM_GETSTATS in order to export per-slave statistics. It works by passing the attribute to the linkxstats callback and if the callback user supports it - it should dump that slave's stats.

[Bridge] [PATCH net-next v2 1/2] net: rtnetlink: add support for the IFLA_STATS_LINK_XSTATS_SLAVE attribute

This patch adds support for the IFLA_STATS_LINK_XSTATS_SLAVE attribute which allows to export per-slave statistics if the master device supports the linkxstats callback. The attribute is passed down to the linkxstats callback and it is up to the callback user to use it (an example has been added

[Bridge] [PATCH net-next v2 2/2] net: bridge: add support for IGMP/MLD stats and export them via netlink

This patch adds stats support for the currently used IGMP/MLD types by the bridge. The stats are per-port (plus one stat per-bridge) and per-direction (RX/TX). The stats are exported via netlink via the new linkxstats API (RTM_GETSTATS). In order to minimize the performance impact, a new option is

  1   2   >