Re: [PATCH net v2] ip6mr: fix stale iterator

On 31/01/18 16:49, Dmitry Vyukov wrote: > On Wed, Jan 31, 2018 at 3:29 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> When we dump the ip6mr mfc entries via proc, we initialize an iterator >> with the table to dump but we don't clear the c

[PATCH net v2] ip6mr: fix stale iterator

000 R15: WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0 lib/usercopy.c:26 Reported-by: syzbot <bot+eceb3204562c41a438fa1f2335e0fe4f6886d...@syzkaller.appspotmail.com> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH net] ip6mr: fix stale iterator cache pointer

000 R15: WARNING: CPU: 1 PID: 3195 at lib/usercopy.c:26 _copy_to_user+0xb5/0xc0 lib/usercopy.c:26 Reported-by: syzbot <bot+eceb3204562c41a438fa1f2335e0fe4f6886d...@syzkaller.appspotmail.com> Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com&g

Re: [PATCH net-next v2] net: link_watch: mark bonding link events urgent

v) || netif_is_lag_master(dev)) > return true; > > return netif_carrier_ok(dev) && qdisc_tx_changing(dev); > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [Patch net] 8021q: fix a memory leak for VLAN 0 device

On 01/10/2018 01:06 AM, Cong Wang wrote: > On Tue, Jan 9, 2018 at 2:53 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> On 01/10/2018 12:47 AM, Cong Wang wrote: >>> On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov >>> <niko...@c

Re: [Patch net] 8021q: fix a memory leak for VLAN 0 device

On 01/10/2018 12:47 AM, Cong Wang wrote: > On Tue, Jan 9, 2018 at 2:30 PM, Nikolay Aleksandrov > <niko...@cumulusnetworks.com> wrote: >> >> Just for reference - this is identical to the first part of: >> https://patchwork.ozlabs.org/patch/252891/ >> >> I k

Re: [Patch net] 8021q: fix a memory leak for VLAN 0 device

On 09/01/18 23:40, Cong Wang wrote: > A vlan device with vid 0 is allow to creat by not able to be fully > cleaned up by unregister_vlan_dev() which checks for vlan_id!=0. > > Also, VLAN 0 is probably not a valid number and it is kinda > "reserved" for HW accelerating devices, but it is probably

[PATCH net v2] net: bridge: fix early call to br_stp_change_bridge_id and plug newlink leaks

@offset=128 Fixes: 30313a3d5794 ("bridge: Handle IFLA_ADDRESS correctly when creating bridge device") Fixes: 5b8d5429daa0 ("bridge: netlink: register netdevice before executing changelink") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- v2: it's b

Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id

On 12/18/2017 04:22 PM, Nikolay Aleksandrov wrote: > On 12/18/2017 04:24 AM, Toshiaki Makita wrote: >> On 2017/12/16 20:31, Nikolay Aleksandrov wrote: > [snip] >> ... >>> err = br_changelink(dev, tb, data, extack); >>> - if (err) >>> + if (err)

Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id

On 12/18/2017 04:24 AM, Toshiaki Makita wrote: > On 2017/12/16 20:31, Nikolay Aleksandrov wrote: [snip] > ... >> err = br_changelink(dev, tb, data, extack); >> -if (err) >> +if (err) { >> +/* clean possible fdbs from

Re: [PATCH net] net: bridge: fix early call to br_stp_change_bridge_id

On 16/12/17 13:31, Nikolay Aleksandrov wrote: > The early call to br_stp_change_bridge_id in bridge's newlink can cause > a memory leak if an error occurs during the newlink because the fdb > entries are not cleaned up if a different lladdr was specified, also > another

[PATCH net] net: bridge: fix early call to br_stp_change_bridge_id

0xd5df2ab5 @offset=128 Fixes: a4b816d8ba1c ("bridge: Change local fdb entries whenever mac address of bridge device changes") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- Consequently this also would fix the null ptr deref due to the rhashtable not b

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 12:40, Nikolay Aleksandrov wrote: > On 16/12/17 11:29, Nikolay Aleksandrov wrote: >> On 16/12/17 11:17, Nikolay Aleksandrov wrote: >>> On 16/12/17 02:37, Andrei Vagin wrote: >>>> Hi, >>>> >>>> We run criu tests for linux-next a

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:29, Nikolay Aleksandrov wrote: > On 16/12/17 11:17, Nikolay Aleksandrov wrote: >> On 16/12/17 02:37, Andrei Vagin wrote: >>> Hi, >>> >>> We run criu tests for linux-next and today we get this bug: >>> >>> The kernel version

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 11:17, Nikolay Aleksandrov wrote: > On 16/12/17 02:37, Andrei Vagin wrote: >> Hi, >> >> We run criu tests for linux-next and today we get this bug: >> >> The kernel version is 4.15.0-rc3-next-20171215 >> >> [ 235.397328] BUG: una

Re: BUG: unable to handle kernel NULL pointer dereference in fdb_find_rcu

On 16/12/17 02:37, Andrei Vagin wrote: > Hi, > > We run criu tests for linux-next and today we get this bug: > > The kernel version is 4.15.0-rc3-next-20171215 > > [ 235.397328] BUG: unable to handle kernel NULL pointer dereference > at 000c > [ 235.398624] IP:

Re: [PATCH net-next] net: bridge: use rhashtable for fdbs

On 12/12/17 20:02, Stephen Hemminger wrote: > On Tue, 12 Dec 2017 16:02:50 +0200 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> +memcpy(__entry->addr, f->key.addr.addr, ETH_ALEN); > > Maybe use ether_addr_copy() here? > Th

Re: [PATCH net-next] net: bridge: use rhashtable for fdbs

On 12/12/17 20:07, Stephen Hemminger wrote: > On Tue, 12 Dec 2017 16:02:50 +0200 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> Before this patch the bridge used a fixed 256 element hash table which >> was fine for small use cases (in my tests it star

[PATCH net-next] net: bridge: use rhashtable for fdbs

-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- After this I'll post patches for the per-port fdb limit option. Later we can get rid of hash_lock altogether though that requires much more careful changes. include/trace/events/bridge.h | 4 +- net/bridge/br_device.c| 10 +

Re: [PATCH] net: bridge: add max_fdb_count

On 17/11/17 08:14, Nikolay Aleksandrov wrote: > On 17/11/17 07:26, Willy Tarreau wrote: >> Hi Stephen, >> >> On Thu, Nov 16, 2017 at 04:27:18PM -0800, Stephen Hemminger wrote: >>> On Thu, 16 Nov 2017 21:21:55 +0100 >>> Vincent Bernat <ber...@luffy.cx&

Re: [PATCH] net: bridge: add max_fdb_count

On 17/11/17 07:26, Willy Tarreau wrote: > Hi Stephen, > > On Thu, Nov 16, 2017 at 04:27:18PM -0800, Stephen Hemminger wrote: >> On Thu, 16 Nov 2017 21:21:55 +0100 >> Vincent Bernat wrote: >> >>> ? 16 novembre 2017 20:23 +0100, Andrew Lunn  : >>> struct

Re: [PATCH] net: bridge: add max_fdb_count

On 16 November 2017 21:23:25 EET, Andrew Lunn wrote: >> Linux bridges can also be used in small embedded devices. With no >limit, >> the likely result from those devices being attacked is the device >gets >> thrown away for being unreliable. > >Hi Sarah > >Just to get a gut

Re: [PATCH] net: bridge: add max_fdb_count

On 16/11/17 11:20, Sarah Newman wrote: > On 11/15/2017 11:31 PM, Nikolay Aleksandrov wrote: >> On 15/11/17 21:27, Sarah Newman wrote: >>> Current memory and CPU usage for managing bridge fdb entries is unbounded. >>> Add a parameter max_fdb_count, controlled from s

Re: [PATCH] net: bridge: add max_fdb_count

On 15/11/17 21:27, Sarah Newman wrote: > Current memory and CPU usage for managing bridge fdb entries is unbounded. > Add a parameter max_fdb_count, controlled from sysfs, which places an upper > limit on the number of entries. Defaults to 1024. > > When max_fdb_count is met or exceeded, whether

[PATCH net] net: bridge: add vlan_tunnel to bridge port policies

Found another missing port flag policy entry for IFLA_BRPORT_VLAN_TUNNEL so add it now. CC: Roopa Prabhu <ro...@cumulusnetworks.com> Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- n

Re: [PATCH v4 net-next 0/6] IGMP snooping for local traffic

On 10.11.2017 00:10, Andrew Lunn wrote: > The linux bridge supports IGMP snooping. It will listen to IGMP > reports on bridge ports and keep track of which groups have been > joined on an interface. It will then forward multicast based on this > group membership. > > When the bridge adds or

Re: [PATCH v3 net-next 3/5] net: bridge: Add/del switchdev object on host join/leave

ev.h | 1 + > net/bridge/br_mdb.c | 39 +++ > net/switchdev/switchdev.c | 2 ++ > 3 files changed, 42 insertions(+) > One minor nit below, functionally looks good. Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> > di

Re: [PATCH v3 net-next 2/5] net: bridge: Send notification when host join/leaves a group

should rewrite __br_mdb_notify to be more readable, but that is beyond the scope of this set and can be done later. Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [PATCH v3 net-next 1/5] net: bridge: Rename mglist to host_joined

/bridge/br_input.c | 2 +- > net/bridge/br_mdb.c | 2 +- > net/bridge/br_multicast.c | 14 +++--- > net/bridge/br_private.h | 2 +- > 4 files changed, 10 insertions(+), 10 deletions(-) > Much better, thanks! Acked-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH net-next] net: bridge: add notifications for the bridge dev on vlan change

the liberty to rearrange each modified function's local variables in reverse xmas tree as well. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- There is still one case where a notification is not generated - when using the vlan flag BRIDGE_VLAN_INFO_MASTER (cur

[PATCH net-next] net: bridge: add neigh_suppress to bridge port policies

Add an entry for IFLA_BRPORT_NEIGH_SUPPRESS to bridge port policies. Fixes: 821f1b21cabb ("bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c | 1 + 1 file chan

[PATCH net-next v6 0/2] bridge: make setlink/dellink notifications more accurate

3: rebased to latest net-next and fixed non-vlan config functions reported by kbuild test bot v2: pass changed down to vlan add instead of masking errors Thanks, Nik Nikolay Aleksandrov (2): bridge: netlink: make setlink/dellink notifications more accurate bridge: vlan: signal if anything chang

[PATCH net-next v6 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> Acked-by: Stephen Hemminger <step...@networkplumber.or

[PATCH net-next v6 2/2] bridge: vlan: signal if anything changed on vlan add

was updated. We cannot return an error because there are valid use cases that will be broken (e.g. overlapping range add) and also we can't risk masking errors due to calls into drivers for vlan add which can potentially return anything. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.

Re: [PATCH net-next v5 2/2] bridge: vlan: signal if anything changed on vlan add

On 27/10/17 11:24, Toshiaki Makita wrote: > On 2017/10/26 22:41, Nikolay Aleksandrov wrote: >> Before this patch there was no way to tell if the vlan add operation >> actually changed anything, thus we would always generate a notification >> on adds. Let's make the notif

Re: [PATCH net-next v5 2/2] bridge: vlan: signal if anything changed on vlan add

On 27/10/17 04:55, Toshiaki Makita wrote: > On 2017/10/26 22:41, Nikolay Aleksandrov wrote: >> Before this patch there was no way to tell if the vlan add operation >> actually changed anything, thus we would always generate a notification >> on adds. Let's make the notif

[PATCH net-next v5 2/2] bridge: vlan: signal if anything changed on vlan add

was updated. We cannot return an error because there are valid use cases that will be broken (e.g. overlapping range add) and also we can't risk masking errors due to calls into drivers for vlan add which can potentially return anything. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.

[PATCH net-next v5 0/2] bridge: make setlink/dellink notifications more accurate

instead of masking errors Thanks, Nik Nikolay Aleksandrov (2): bridge: netlink: make setlink/dellink notifications more accurate bridge: vlan: signal if anything changed on vlan add net/bridge/br_netlink.c| 51 +--- net/bridge/br_netlink_tunnel.c | 14

[PATCH net-next v5 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> Acked-by: Stephen Hemminger <step...@networkplumber.or

Re: [Bridge] [PATCH net-next v4 2/2] bridge: vlan: signal if anything changed on vlan add

On 26/10/17 14:02, Nikolay Aleksandrov wrote: > On 26/10/17 13:16, Toshiaki Makita wrote: >> On 2017/10/26 7:52, Nikolay Aleksandrov wrote: >> ... >>> @@ -559,6 +574,7 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 >>> flags) >>> >>>

Re: [Bridge] [PATCH net-next v4 2/2] bridge: vlan: signal if anything changed on vlan add

On 26/10/17 13:16, Toshiaki Makita wrote: > On 2017/10/26 7:52, Nikolay Aleksandrov wrote: > ... >> @@ -559,6 +574,7 @@ int br_vlan_add(struct net_bridge *br, u16 vid, u16 >> flags) >> >> ASSERT_RTNL(); >> >> +*changed = false; &g

Re: [PATCH net-next v3 1/2] bridge: netlink: make setlink/dellink notifications more accurate

On 26/10/17 11:17, Stephen Hemminger wrote: > On Thu, 26 Oct 2017 00:59:41 +0300 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> Before this patch we had cases that either sent notifications when there >> were in fact no changes (e.g. non-existent

[PATCH net-next v4 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c

[PATCH net-next v4 2/2] bridge: vlan: signal if anything changed on vlan add

was updated. We cannot return an error because there are valid use cases that will be broken (e.g. overlapping range add) and also we can't risk masking errors due to calls into drivers for vlan add which can potentially return anything. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.

[PATCH net-next v4 0/2] bridge: make setlink/dellink notifications more accurate

was actually updated. v4: set changed always to false in the non-vlan config case and retested v3: rebased to latest net-next and fixed non-vlan config functions reported by kbuild test bot v2: pass changed down to vlan add instead of masking errors Thanks, Nik Nikolay Aleksandrov (2

Re: [PATCH net-next v3 0/2] bridge: make setlink/dellink notifications more accurate

On 26/10/17 00:59, Nikolay Aleksandrov wrote: ... > > v3: rebased to latest net-next and fixed non-vlan config functions reported > by kbuild test bot And obviously fixed them wrong, grr... sorry about the noise again, I'll resend v4 with the proper fix. > v2: pass changed down

[PATCH net-next v3 2/2] bridge: vlan: signal if anything changed on vlan add

was updated. We cannot return an error because there are valid use cases that will be broken (e.g. overlapping range add) and also we can't risk masking errors due to calls into drivers for vlan add which can potentially return anything. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.

[PATCH net-next v3 0/2] bridge: make setlink/dellink notifications more accurate

was actually updated. v3: rebased to latest net-next and fixed non-vlan config functions reported by kbuild test bot v2: pass changed down to vlan add instead of masking errors Thanks, Nik Nikolay Aleksandrov (2): bridge: netlink: make setlink/dellink notifications more accurate bridge

[PATCH net-next v3 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c

Re: [PATCH net-next v2 0/2] bridge: make setlink/dellink notifications more accurate

On 24/10/17 15:32, Nikolay Aleksandrov wrote: > Hi, > Before this set the bridge would generate a notification on vlan add or del > even if they didn't actually do any changes, which confuses listeners and > is generally not preferred. We could also lose notifications on actual >

[PATCH net-next v2 2/2] bridge: vlan: signal if anything changed on vlan add

was updated. We cannot return an error because there are valid use cases that will be broken (e.g. overlapping range add) and also we can't risk masking errors due to calls into drivers for vlan add which can potentially return anything. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.

[PATCH net-next v2 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c

[PATCH net-next v2 0/2] bridge: make setlink/dellink notifications more accurate

was actually updated. Can't say that I am happy with this change, but currently I don't see any simpler way which doesn't affect user-space. v2: pass changed down to vlan add instead of masking errors Thanks, Nik Nikolay Aleksandrov (2): bridge: netlink: make setlink/dellink notifications

[PATCH net] net: bridge: fix returning of vlan range op errors

When vlan tunnels were introduced, vlan range errors got silently dropped and instead 0 was returned always. Restore the previous behaviour and return errors to user-space. Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support") Signed-off-by: Nikolay Aleksan

Re: [PATCH net-next 0/2] bridge: make setlink/dellink notifications more accurate

On 19/10/17 18:54, Nikolay Aleksandrov wrote: > Hi, > Before this set the bridge would generate a notification on vlan add or del > even if they didn't actually do any changes, which confuses listeners and > is generally not preferred. We could also lose notifications on actual >

[PATCH net-next 0/2] bridge: make setlink/dellink notifications more accurate

overlapping vlan range add or script return expectations we clear it on return, the functions used by vlan add are not expected to return EEXIST. Thanks, Nik Nikolay Aleksandrov (2): bridge: netlink: make setlink/dellink notifications more accurate bridge: vlan: return EEXIST on add if nothing

[PATCH net-next 2/2] bridge: vlan: return EEXIST on add if nothing changed

in any way. We just need to be careful about a few places that could re-add the same vlan with the same flags not to return any errors on EEXIST. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c | 5 + net/bridge/br_vlan.c

[PATCH net-next 1/2] bridge: netlink: make setlink/dellink notifications more accurate

missing vlans inside and still everything in that range will be cleared, this is mostly used to clear the whole vlan config with a single call, i.e. range 1-4094. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/bridge/br_netlink.c

[PATCH iproute2 net-next] ip: bridge_slave: add neigh_suppress to the type help and man pages

Add neigh_suppress to the type help and document it in ip-link's man page. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- ip/iplink_bridge_slave.c | 1 + man/man8/ip-link.8.in| 7 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --gi

Re: [PATCH net-next v2 1/1] bridge: return error code when deleting Vlan

On 13/10/17 19:00, Roman Mashak wrote: > Nikolay Aleksandrov <niko...@cumulusnetworks.com> writes: > > > [...] > >>>> Why do you want to return the error code here? Walking the code paths >>>> seems like ENOENT or err from switchdev_po

[PATCH iproute2 net-next] ip: bridge_slave: add support for per-port group_fwd_mask

This patch adds the iproute2 support for getting and setting the per-port group_fwd_mask. It also tries to resolve the value into a more human friendly format by printing the known protocols instead of only the raw value. The man page is also updated with the new option. Signed-off-by: Nikolay

Re: [PATCH net-next v2 1/1] bridge: return error code when deleting Vlan

On 13.10.2017 05:03, Jamal Hadi Salim wrote: > On 17-10-12 02:12 PM, Nikolay Aleksandrov wrote: >> On 12/10/17 21:07, Roman Mashak wrote: > >>> For example, if you attempt to delete a non-existing vlan on a port, >>> the current code succeeds and also sends eve

Re: [PATCH net-next v2 1/1] bridge: return error code when deleting Vlan

On 12/10/17 21:07, Roman Mashak wrote: > On Thu, Oct 12, 2017 at 10:19 AM, David Ahern wrote: >> On 10/12/17 7:51 AM, Roman Mashak wrote: >>> v2: >>> Return err immediately if nbp_vlan_delete() fails (pointed by David Ahern) >>> >>> Signed-off-by: Roman Mashak

Re: [patch net-next v2 1/5] net: bridge: Notify on bridge device mrouter state changes

learning-off states > --- > include/net/switchdev.h | 1 + > net/bridge/br_multicast.c | 38 +++--- > 2 files changed, 36 insertions(+), 3 deletions(-) > Much simpler, I like it. Thanks! Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too

On 08/10/17 12:39, Nikolay Aleksandrov wrote: > On 08/10/17 08:23, Yotam Gigi wrote: >> On 10/05/2017 03:09 PM, Nikolay Aleksandrov wrote: >>> On 05/10/17 13:36, Jiri Pirko wrote: >>>> From: Yotam Gigi <yot...@mellanox.com> >>>> >>>>

Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too

On 08/10/17 08:23, Yotam Gigi wrote: > On 10/05/2017 03:09 PM, Nikolay Aleksandrov wrote: >> On 05/10/17 13:36, Jiri Pirko wrote: >>> From: Yotam Gigi <yot...@mellanox.com> >>> >>> Every bridge port is in one of four mcast router port states: >>>

Re: [patch net-next 2/6] net: bridge: Notify on bridge device mrouter state changes

; net/bridge/br_multicast.c | 21 - > 2 files changed, 21 insertions(+), 1 deletion(-) > LGTM, but if we switch to using the timer state it will need some adjustment. Anyway for this version, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next 3/6] net: bridge: Export bridge multicast router state

> Reviewed-by: Nogah Frankel <nog...@mellanox.com> > Signed-off-by: Jiri Pirko <j...@mellanox.com> > --- > include/linux/if_bridge.h | 5 + > net/bridge/br_multicast.c | 12 > 2 files changed, 17 insertions(+) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too

On 05/10/17 15:09, Nikolay Aleksandrov wrote: > On 05/10/17 13:36, Jiri Pirko wrote: >> From: Yotam Gigi <yot...@mellanox.com> >> >> Every bridge port is in one of four mcast router port states: >> - MDB_RTR_TYPE_PERM - the port is set by the user to be an mrou

Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too

On 05/10/17 15:09, Nikolay Aleksandrov wrote: > On 05/10/17 13:36, Jiri Pirko wrote: >> From: Yotam Gigi <yot...@mellanox.com> >> >> Every bridge port is in one of four mcast router port states: >> - MDB_RTR_TYPE_PERM - the port is set by the user to be an mrou

Re: [patch net-next 1/6] net: bridge: Use the MDB_RTR_TYPE_TEMP on bridge device too

On 05/10/17 13:36, Jiri Pirko wrote: > From: Yotam Gigi > > Every bridge port is in one of four mcast router port states: > - MDB_RTR_TYPE_PERM - the port is set by the user to be an mrouter port >regardless of IGMP queries. > - MDB_RTR_TYPE_DISABLED - the port is set

Re: [patch net-next v2 3/7] ipv4: ipmr: Don't forward packets already forwarded by hardware

@@ -1859,10 +1859,33 @@ static inline int ipmr_forward_finish(struct net > *net, struct sock *sk, > return dst_output(net, sk, skb); > } > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next v2 2/7] ipv4: ipmr: Add the parent ID field to VIF struct

attr.orig_dev = dev; > + if (!switchdev_port_attr_get(dev, )) { > + memcpy(v->dev_parent_id.id, attr.u.ppid.id, attr.u.ppid.id_len); > + v->dev_parent_id.id_len = attr.u.ppid.id_len; > + } else { > + v->dev_parent_id.id_len = 0; > + } > v->rate_limit = vifc->vifc_rate_limit; > v->local = vifc->vifc_lcl_addr.s_addr; > v->remote = vifc->vifc_rmt_addr.s_addr; > Looks good, thanks! Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH net] net: rtnetlink: fix info leak in RTM_GETSTATS call

-by: Alexander Potapenko <gli...@google.com> Fixes: 10c9ead9f3c6 ("rtnetlink: add new RTM_GETSTATS message to dump link stats") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- net/core/rtnetlink.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/

Re: [PATCH net-next] net: bridge: add per-port group_fwd_mask with less restrictions

On 30/09/17 00:51, Stephen Hemminger wrote: > On Sat, 30 Sep 2017 00:01:24 +0300 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> On 29/09/17 18:14, Stephen Hemminger wrote: >>> On Wed, 27 Sep 2017 16:12:44 +0300 >>> Nikolay Aleksand

Re: [PATCH net-next] net: bridge: add per-port group_fwd_mask with less restrictions

On 29/09/17 18:14, Stephen Hemminger wrote: > On Wed, 27 Sep 2017 16:12:44 +0300 > Nikolay Aleksandrov <niko...@cumulusnetworks.com> wrote: > >> We need to be able to transparently forward most link-local frames via >> tunnels (e.g. vxlan, qinq). Currently the

Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct

On 28/09/17 20:34, Jiri Pirko wrote: > From: Yotam Gigi > > In order to allow the ipmr module to do partial multicast forwarding > according to the device parent ID, add the device parent ID field to the > VIF struct. This way, the forwarding path can use the parent ID field

Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct

On 29/09/17 12:29, Nikolay Aleksandrov wrote: > On 28/09/17 20:34, Jiri Pirko wrote: >> From: Yotam Gigi <yot...@mellanox.com> >> >> In order to allow the ipmr module to do partial multicast forwarding >> according to the device parent ID, add the device par

Re: [patch net-next 2/7] ipv4: ipmr: Add the parent ID field to VIF struct

On 28/09/17 20:34, Jiri Pirko wrote: > From: Yotam Gigi > > In order to allow the ipmr module to do partial multicast forwarding > according to the device parent ID, add the device parent ID field to the > VIF struct. This way, the forwarding path can use the parent ID field

Re: [patch net-next v3 06/12] net: mroute: Check if rule is a default rule

LE_TABLES > v1->v2: > - Update the lastuse MFC entry field too, in addition to packets an bytes. > --- > include/linux/mroute.h | 7 +++ > net/ipv4/ipmr.c| 12 > 2 files changed, 19 insertions(+) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

[PATCH net-next] net: bridge: add per-port group_fwd_mask with less restrictions

this patch with LACP and STP forwarding over VxLAN and qinq tunnels. Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- note: I left the permissions like this to be consistent with all the other port options. include/uapi/linux/if_link.h | 1 + net/bridge/br_input.c| 1

Re: [patch net-next v2 07/12] mlxsw: spectrum: Add the multicast routing offloading logic

On 24/09/17 20:22, Jiri Pirko wrote: > From: Yotam Gigi > > Add the multicast router offloading logic, which is in charge of handling > the VIF and MFC notifications and translating it to the hardware logic API. > > The offloading logic has to overcome several obstacles in

Re: [patch net-next v2 06/12] net: mroute: Check if rule is a default rule

On 25/09/17 12:45, Jiri Pirko wrote: > Mon, Sep 25, 2017 at 03:28:21AM CEST, linyunsh...@huawei.com wrote: >> Hi, Jiri >> >> On 2017/9/25 1:22, Jiri Pirko wrote: >>> From: Yotam Gigi >>> >>> When the ipmr starts, it adds one default FIB rule that matches all packets >>> and

Re: [patch net-next v2 03/12] ipmr: Add FIB notification access functions

On 25/09/17 12:47, Jiri Pirko wrote: > Mon, Sep 25, 2017 at 11:40:16AM CEST, niko...@cumulusnetworks.com wrote: >> On 25/09/17 12:35, Nikolay Aleksandrov wrote: >>> On 24/09/17 20:22, Jiri Pirko wrote: >>>> From: Yotam Gigi <yot...@mellanox.com> >>>

Re: [patch net-next v2 03/12] ipmr: Add FIB notification access functions

On 25/09/17 12:35, Nikolay Aleksandrov wrote: > On 24/09/17 20:22, Jiri Pirko wrote: >> From: Yotam Gigi <yot...@mellanox.com> >> >> Make the ipmr module register as a FIB notifier. To do that, implement both >> the ipmr_seq_read and ipmr_dump ops. >> >

Re: [patch net-next v2 06/12] net: mroute: Check if rule is a default rule

+++ > 2 files changed, 17 insertions(+) > I saw the comment and am fine with the patch either way, so you can add my: Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> Thanks

Re: [patch net-next v2 05/12] net: ipmr: Add MFC offload indication

ev->ifindex) < 0) > return -EMSGSIZE; > > + if (c->mfc_flags & MFC_OFFLOAD) > + rtm->rtm_flags |= RTNH_F_OFFLOAD; > + > if (!(mp_attr = nla_nest_start(skb, RTA_MULTIPATH))) > return -EMSGSIZE; > > Thanks! Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next v2 03/12] ipmr: Add FIB notification access functions

c | 137 > ++++++++++- > 3 files changed, 153 insertions(+), 2 deletions(-) > LGTM, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next v2 02/12] ipmr: Add reference count to MFC entries

+++ > net/ipv4/ipmr.c | 8 +--- > 2 files changed, 26 insertions(+), 3 deletions(-) > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next v2 01/12] fib: notifier: Add VIF add and delete event types

_EVENT_NH_DEL, > + FIB_EVENT_VIF_ADD, > + FIB_EVENT_VIF_DEL, > }; > > struct fib_notifier_ops { > Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com>

Re: [patch net-next 02/12] ipmr: Add reference count to MFC entries

On 21/09/17 09:43, Jiri Pirko wrote: > From: Yotam Gigi > > Next commits will introduce MFC notifications through the atomic > fib_notification chain, thus allowing modules to be aware of MFC entries. > > Due to the fact that modules may need to hold a reference to an MFC

Re: [patch net-next 04/12] ipmr: Send FIB notifications on MFC and VIF entries

53 insertions(+) > LGTM, I only wish we could consolidate all of these call_ipmr_mfc_entry_notifiers() calls inside mroute_netlink_event() but it will need an additional argument for the ADD vs REPLACE cases. Anyway, Reviewed-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> >

Re: [patch net-next 05/12] net: ipmr: Add MFC offload indication

On 21/09/17 09:43, Jiri Pirko wrote: > From: Yotam Gigi > > Allow drivers, registered to the fib notification chain indicate whether a > multicast MFC route is offloaded or not, similarly to unicast routes. The > indication of whether a route is offloaded is done using the

Re: [patch net-next 03/12] ipmr: Add FIB notification access functions

On 21/09/17 09:43, Jiri Pirko wrote: > From: Yotam Gigi > > Make the ipmr module register as a FIB notifier. To do that, implement both > the ipmr_seq_read and ipmr_dump ops. > > The ipmr_seq_read op returns a sequence counter that is incremented on > every notification

[PATCH net] net: bonding: fix tlb_dynamic_lb default value

ault param initialization for tlb_dynamic_lb which will always set it to 1 as before. Fixes: 8b426dc54cf4 ("bonding: remove hardcoded value") Signed-off-by: Nikolay Aleksandrov <niko...@cumulusnetworks.com> --- drivers/net/bonding/bond_main.c | 17 +++-- 1 file changed, 7 i

Re: [PATCH] net: bonding: Fix transmit load balancing in balance-alb mode if specified by sysfs

On 11 September 2017 19:07:33 EEST, "Mahesh Bandewar (महेश बंडेवार)" <mahe...@google.com> wrote: >On Sat, Sep 9, 2017 at 4:28 AM, Nikolay Aleksandrov ><niko...@cumulusnetworks.com> wrote: >> On 07/09/17 01:47, Kosuke Tatsukawa wrote: >>> Commit cbf

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 10/09/17 21:18, Roman Mashak wrote: > Nikolay Aleksandrov <niko...@cumulusnetworks.com> writes: > >> On 10/09/17 16:38, Roman Mashak wrote: > > [...] > >>> Since VLAN info is already in link messages, there is no other option but >>> dump it in m

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 10/09/17 16:38, Roman Mashak wrote: > Roopa Prabhu writes: > >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: >>> Signed-off-by: Roman Mashak >>> --- >>> bridge/link.c | 16 +--- >>> 1 file changed, 13

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 09/09/17 20:23, Jamal Hadi Salim wrote: > On 17-09-09 12:24 PM, Roopa Prabhu wrote: >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: [snip] > > Agree we should be turning on this stuff by default. i.e default stays > compressed; otherwise it a huge dump. > > Having

Re: [PATCH iproute2 3/3] bridge: request vlans along with link information

On 09/09/17 20:23, Jamal Hadi Salim wrote: > On 17-09-09 12:24 PM, Roopa Prabhu wrote: >> On Fri, Sep 8, 2017 at 2:52 PM, Roman Mashak wrote: >>> Signed-off-by: Roman Mashak >>> --- >>> bridge/link.c | 16 +--- >>> 1 file changed, 13

<    1   2   3   4   5   6   7   8   9   10   >