Re: [Bridge] [PATCH net-next 0/9] Use __vlan_hwaccel_*() helpers

From: Michał Mirosław Date: Fri, 09 Nov 2018 00:17:58 +0100 > This series removes from networking core and driver code an assumption > about how VLAN tag presence is stored in an skb. This will allow to free > up overloading of VLAN.CFI bit to incidate tag's presence. This looks good, series

Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries

From: Nikolay Aleksandrov Date: Sat, 27 Oct 2018 12:07:47 +0300 > Recently a check was added which prevents marking of routers with zero > source address, but for IPv6 that cannot happen as the relevant RFCs > actually forbid such packets: > RFC 2710 (MLDv1): > "To be valid, the Query message

Re: [Bridge] [PATCH net-next v2 00/18] mlxsw: Add VxLAN support

From: Ido Schimmel Date: Wed, 17 Oct 2018 08:53:02 + > This patchset adds support for VxLAN offload in the mlxsw driver. Series applied, thanks.

Re: [Bridge] [PATCH][net-next][v2] net: bridge: fix a possible memory leak in __vlan_add

From: Li RongQing Date: Mon, 15 Oct 2018 19:00:31 +0800 > After per-port vlan stats, vlan stats should be released > when fail to add vlan > > Fixes: 9163a0fc1f0c0 ("net: bridge: add support for per-port vlan stats") > CC: bridge@lists.linux-foundation.org > cc: Nikolay Aleksandrov > CC: Roopa

Re: [Bridge] [PATCH net-next] net: bridge: add support for per-port vlan stats

From: Nikolay Aleksandrov Date: Fri, 12 Oct 2018 13:41:16 +0300 > This patch adds an option to have per-port vlan stats instead of the > default global stats. The option can be set only when there are no port > vlans in the bridge since we need to allocate the stats if it is set > when vlans are

Re: [Bridge] [PATCH net-next] bridge: mcast: Default back to multicast enabled state

From: Ido Schimmel Date: Mon, 1 Oct 2018 11:57:01 +0300 > Commit 13cefad2f2c1 ("net: bridge: convert and rename mcast disabled") > converted the 'multicast_disabled' field to an option bit named > 'BROPT_MULTICAST_ENABLED'. > > While the old field was implicitly initialized to 0, the new field

Re: [Bridge] [PATCH net-next] net: bridge: explicitly zero is_sticky in fdb_create

From: Nikolay Aleksandrov Date: Thu, 27 Sep 2018 15:05:10 +0300 > We need to explicitly zero is_sticky when creating a new fdb, otherwise > we might get a stale value for a new entry. > > Fixes: 435f2e7cc0b7 ("net: bridge: add support for sticky fdb entries") > Signed-off-by: Nikolay

Re: [Bridge] [PATCH net-next v2 0/9] net: bridge: convert bool options to bits

From: Nikolay Aleksandrov Date: Wed, 26 Sep 2018 17:04:03 +0300 > On 26/09/18 17:00, Nikolay Aleksandrov wrote: >> Hi, >> A lot of boolean bridge options have been added around the net_bridge >> structure resulting in holes and more importantly different cache lines >> that need to be fetched in

Re: [Bridge] [PATCH net-next v2] net: bridge: add support for sticky fdb entries

From: Nikolay Aleksandrov Date: Tue, 11 Sep 2018 09:39:53 +0300 > Add support for entries which are "sticky", i.e. will not change their port > if they show up from a different one. A new ndm flag is introduced for that > purpose - NTF_STICKY. We allow to set it only to non-local entries. > >

Re: [Bridge] [PATCH v1] bridge: Switch to bitmap_zalloc()

From: Andy Shevchenko Date: Thu, 30 Aug 2018 13:33:18 +0300 > Switch to bitmap_zalloc() to show clearly what we are allocating. > Besides that it returns pointer of bitmap type instead of opaque void *. > > Signed-off-by: Andy Shevchenko Applied to net-next, thanks.

Re: [Bridge] [PATCH net-next v3 0/2] net: bridge: add support for backup port

From: Nikolay Aleksandrov Date: Mon, 23 Jul 2018 11:16:57 +0300 > This set introduces a new bridge port option that allows any port to have > any other port (in the same bridge of course) as its backup and traffic > will be forwarded to the backup port when the primary goes down. This is >

Re: [Bridge] [PATCH net-next 1/2] net: bridge: add support for raw sysfs port options

From: Nikolay Aleksandrov Date: Fri, 20 Jul 2018 17:48:25 +0300 > + spin_lock_bh(>br->lock); > + ret = brport_attr->store_raw(p, (char *)buf); > + spin_unlock_bh(>br->lock); Please respect the const here. Have the methods do a kstrncup(); ... kfree();

Re: [Bridge] [PATCH net-next v3 0/8] Make /sys/class/net per net namespace objects belong to container

From: Tyler Hicks Date: Fri, 20 Jul 2018 21:56:46 + > This is a revival of an older patch set from Dmitry Torokhov: > > > https://lore.kernel.org/lkml/1471386795-32918-1-git-send-email-dmitry.torok...@gmail.com/ > > My submission of v2 is here: > > >

Re: [Bridge] [PATCH v2 net-next 0/7] Make /sys/class/net per net namespace objects belong to container

From: David Miller Date: Wed, 18 Jul 2018 13:17:34 +0900 (KST) > Ok, I can't let this series rot forever, so I'll apply it to net-next. Unfortunately, I had to revert, this breaks the build: arch/x86/kernel/cpu/intel_rdt_rdtgroup.c:1506:7: error: too few arguments to funct

Re: [Bridge] [PATCH v2 net-next 0/7] Make /sys/class/net per net namespace objects belong to container

From: Tyler Hicks Date: Fri, 13 Jul 2018 16:05:42 + > I'm reviving this patch set because we would like this feature for > system containers. One specific use case that we have is that libvirt is > unable to configure its bridge device inside of a system container due > to the bridge files

Re: [Bridge] [PATCH v2 net-next 0/7] Make /sys/class/net per net namespace objects belong to container

From: Tyler Hicks Date: Fri, 13 Jul 2018 16:05:42 + > Eric had previously provided feedback that he didn't favor these changes > affecting all layers of the stack and that most of the changes could > remain local to drivers/base/core.c. That feedback is certainly sensible > but I wanted to

Re: [Bridge] [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl()

From: Garry McNulty Date: Thu, 21 Jun 2018 21:14:27 +0100 > br_port_get_rtnl() can return NULL if the network device is not a bridge > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and > br_port_fill_slave_info() callbacks dereference this pointer without > checking. Currently

Re: [Bridge] [PATCH net v2] net: bridge: Fix locking in br_fdb_find_port()

From: Petr Machata Date: Fri, 08 Jun 2018 15:11:47 +0200 > Callers of br_fdb_find() need to hold the hash lock, which > br_fdb_find_port() doesn't do. However, since br_fdb_find_port() is not > doing any actual FDB manipulation, the hash lock is not really needed at > all. So convert to

Re: [Bridge] [PATCH net-next v4 0/8] net: bridge: Notify about bridge VLANs

From: Petr Machata Date: Wed, 30 May 2018 02:55:34 +0200 > In commit 946a11e7408e ("mlxsw: spectrum_span: Allow bridge for gretap > mirror"), mlxsw got support for offloading mirror-to-gretap such that > the underlay packet path involves a bridge. In that case, the offload is > also influenced

Re: [Bridge] [PATCH net-next] net: bridge: Lock before br_fdb_find()

From: Petr Machata Date: Mon, 28 May 2018 17:44:16 +0200 > Callers of br_fdb_find() need to hold the hash lock, which > br_fdb_find_port() doesn't do. Add the missing lock/unlock > pair. > > Signed-off-by: Petr Machata If all of the these uses of br_fdb_find_port() are safe, then it should

Re: [Bridge] [PATCH net-next] net: bridge: add support for port isolation

From: Nikolay Aleksandrov Date: Thu, 24 May 2018 11:56:48 +0300 > This patch adds support for a new port flag - BR_ISOLATED. If it is set > then isolated ports cannot communicate between each other, but they can > still communicate with non-isolated ports. The same

Re: [Bridge] [PATCH net-next 0/4] mlxsw: Support VLAN devices in mirroring offloads

From: Ido Schimmel Date: Thu, 10 May 2018 13:13:02 +0300 > Petr says: > > When offloading "tc action mirred mirror", there are several scenarios > where VLAN devices can show up, that mlxsw can offload on Spectrum > machines. > > I) A direct mirror to a VLAN device on top

Re: [Bridge] [PATCH net-next] net: dsa: fix added_by_user switchdev notification

From: Vivien Didelot Date: Tue, 8 May 2018 23:03:12 -0400 > Commit 161d82de1ff8 ("net: bridge: Notify about !added_by_user FDB > entries") causes the below oops when bringing up a slave interface, > because dsa_port_fdb_add is still scheduled, but with a

Re: [Bridge] [PATCH net-next mlxsw v2 0/2] bridge: FDB: Notify about removal of non-user-added entries

From: Petr Machata Date: Thu, 03 May 2018 14:43:40 +0200 > Device drivers may generally need to keep in sync with bridge's FDB. In > particular, for its offload of tc mirror action where the mirrored-to > device is a gretap device, mlxsw needs to listen to a number of events,

Re: [Bridge] [PATCH net-next] net: bridge: avoid duplicate notification on up/down/change netdev events

From: Nikolay Aleksandrov Date: Thu, 3 May 2018 13:47:24 +0300 > While handling netdevice events, br_device_event() sometimes uses > br_stp_(disable|enable)_port which unconditionally send a notification, > but then a second notification for the same event is sent

Re: [Bridge] [PATCH net-next v3 0/6] mlxsw: SPAN: Support routes pointing at bridges

From: Ido Schimmel Date: Sun, 29 Apr 2018 10:56:07 +0300 > Petr says: > > When mirroring to a gretap or ip6gretap netdevice, the route that > directs the encapsulated packets can reference a bridge. In that case, > in the software model, the packet is switched. > > Thus

Re: [Bridge] [PATCH net-next v2 0/6] mlxsw: SPAN: Support routes pointing at bridges

From: Ido Schimmel Date: Fri, 27 Apr 2018 18:11:05 +0300 > Changes from v1 to v2: > > - Change the suite of bridge accessor functions to br_vlan_pvid_rtnl(), > br_vlan_info_rtnl(), br_fdb_find_port_rtnl(). Please address Stephen Hemminger's feedback, otherwise this

Re: [Bridge] [PATCH net-next] bridge: use hlist_entry_safe

From: YueHaibing Date: Thu, 26 Apr 2018 11:07:05 +0800 > Use hlist_entry_safe() instead of open-coding it. > > Signed-off-by: YueHaibing Applied, thanks.

Re: [Bridge] [PATCH V2] treewide/net: Rename eth_stp_addr to ether_stp_addr

From: Joe Perches Date: Sat, 31 Mar 2018 11:34:06 -0700 > eth_stp_addr is not in the same form as the other global ether__addr > addresses like ether_broadcast_addr. > > Convert it treewide. > > Miscellanea: > > o Add comment to the ether_stp_addr define to show it's for

Re: [Bridge] [PATCH net-next 0/2] net: bridge: MTU handling changes

From: Nikolay Aleksandrov Date: Fri, 30 Mar 2018 13:46:17 +0300 > As previously discussed the recent changes break some setups and could lead > to packet drops. Thus the first patch reverts the behaviour for the bridge > to follow the minimum MTU but also keeps the

Re: [Bridge] [PATCH 3/4] net: Use octal not symbolic permissions

Applied.

Re: [Bridge] [PATCH net-next] net: bridge: fix direct access to bridge vlan_enabled and use helper

From: Nikolay Aleksandrov Date: Fri, 23 Mar 2018 18:27:06 +0200 > We need to use br_vlan_enabled() helper otherwise we'll break builds > without bridge vlans: > net/bridge//br_if.c: In function ‘br_mtu’: > net/bridge//br_if.c:458:8: error: ‘const struct net_bridge’

Re: [Bridge] [RFC PATCH v2] bridge: make it possible for packets to traverse the bridge without hitting netfilter

From: David Woodhouse Date: Fri, 09 Mar 2018 15:31:15 + > Eschewing a 15% speedup on the basis that "well, even though we've had > three of these already for a decade, we're worried that adding a fourth > might open the floodgates to further patches" does seem a little

Re: [Bridge] [PATCH net] bridge: Fix VLAN reference count problem

From: Ido Schimmel Date: Sun, 25 Feb 2018 21:59:06 +0200 > When a VLAN is added on a port, a reference is taken on the > corresponding master VLAN entry. If it does not already exist, then it > is created and a reference taken. > > However, in the second case a reference is

Re: [Bridge] [PATCH] net: bridge: Fix uninitialized error in br_fdb_sync_static()

From: Geert Uytterhoeven Date: Thu, 1 Feb 2018 11:25:27 +0100 > With gcc-4.1.2.: > > net/bridge/br_fdb.c: In function ‘br_fdb_sync_static’: > net/bridge/br_fdb.c:996: warning: ‘err’ may be used uninitialized in this > function > > Indeed, if the list is empty,

Re: [Bridge] [PATCH] bridge: return boolean instead of integer in br_multicast_is_router

From: "Gustavo A. R. Silva" Date: Thu, 18 Jan 2018 17:37:45 -0600 > Return statements in functions returning bool should use > true/false instead of 1/0. > > This issue was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva

Re: [Bridge] [PATCH v1] bridge: Use helpers to handle MAC address

From: Andy Shevchenko Date: Tue, 19 Dec 2017 20:10:53 +0200 > Use > %pM to print MAC > mac_pton() to convert it from ASCII to binary format, and > ether_addr_copy() to copy. > > Signed-off-by: Andy Shevchenko

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

From: Nikolay Aleksandrov Date: Mon, 18 Dec 2017 17:35:09 +0200 > 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

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

From: Nikolay Aleksandrov Date: Tue, 12 Dec 2017 16:02:50 +0200 > Before this patch the bridge used a fixed 256 element hash table which > was fine for small use cases (in my tests it starts to degrade > above 1000 entries), but it wasn't enough for medium or large >

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

From: Nikolay Aleksandrov Date: Mon, 13 Nov 2017 18:30:55 +0200 > Found another missing port flag policy entry for IFLA_BRPORT_VLAN_TUNNEL > so add it now. > > CC: Roopa Prabhu > Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink

Re: [Bridge] [PATCH 1/2] [net-next] net: bridge: Convert timers to use timer_setup()

From: Allen Pais Date: Fri, 3 Nov 2017 11:51:10 +0530 > switch to using the new timer_setup() and from_timer() api's. > > Signed-off-by: Allen Pais Applied.

Re: [Bridge] [PATCH net-next] net: Define eth_stp_addr in linux/etherdevice.h

From: Egil Hjelmeland Date: Thu, 2 Nov 2017 10:36:48 +0100 > The lan9303 driver defines eth_stp_addr as a synonym to > eth_reserved_addr_base to get the STP ethernet address 01:80:c2:00:00:00. > > eth_reserved_addr_base is also used to define the start of Bridge

Re: [Bridge] [PATCH 1/2] net: bridge: Convert timers to use timer_setup()

From: Allen Pais Date: Thu, 2 Nov 2017 10:58:50 +0530 > switch to using the new timer_setup() and from_timer() api's. > > Signed-off-by: Allen Pais These two patches do not apply cleanly to net-next, please respin.

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

From: Nikolay Aleksandrov Date: Wed, 1 Nov 2017 12:18:13 +0200 > Currently the bridge device doesn't generate any notifications upon vlan > modifications on itself because it doesn't use the generic bridge > notifications. > With the recent changes we know if

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

From: Nikolay Aleksandrov Date: Mon, 30 Oct 2017 12:56:33 +0200 > 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

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

From: Nikolay Aleksandrov Date: Fri, 27 Oct 2017 13:19:35 +0300 > 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

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

From: Nikolay Aleksandrov Date: Thu, 26 Oct 2017 01:14:19 +0300 > 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,

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

From: Nikolay Aleksandrov Date: Thu, 19 Oct 2017 20:17:32 +0300 > 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

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

From: Nikolay Aleksandrov Date: Thu, 19 Oct 2017 19:10:11 +0300 > Self-NAK > Dave, please ignore this set and apologies for the noise. OK

Re: [Bridge] [PATCH net-next v6 0/3] bridge: neigh msg proxy and flood suppression support

From: Roopa Prabhu Date: Fri, 6 Oct 2017 22:12:36 -0700 > From: Roopa Prabhu > > This series implements arp and nd suppression in the bridge > driver for ethernet vpns. It implements rfc7432, section 10 >

Re: [Bridge] [PATCH net-next v5 0/3] bridge: neigh msg proxy and flood suppression support

From: Roopa Prabhu Date: Fri, 6 Oct 2017 19:35:27 -0700 > On Fri, Oct 6, 2017 at 11:34 AM, Roopa Prabhu > wrote: >> From: Roopa Prabhu >> >> This series implements arp and nd suppression in the bridge >> driver

Re: [Bridge] [PATCH v2 net-next 0/7] net: Plumb extack error reporting to enslavements

From: David Ahern Date: Wed, 4 Oct 2017 17:48:44 -0700 > Another round of extending extack error reporting, this time for > enslavements through ndo_add_slave and notifiers. > > v2 > - changed how the messages are added to bonding driver per Jiri's request > - fixed spectrum

Re: [Bridge] [PATCH net-next v4 1/3] bridge: add new BR_NEIGH_SUPPRESS port flag to suppress arp and nd flood

From: Roopa Prabhu Date: Tue, 3 Oct 2017 22:12:31 -0700 > BR_ARP_PROXY flag but has a few semantic differences to conform This should be "BR_PROXYARP". Otherwise this series looks fine to me, but I see there will be a v5 respin.

Re: [Bridge] [net-next v3] bridge: trigger RTM_NEWLINK when interface is modified by bridge ioctl

From: Vincent Bernat Date: Thu, 21 Sep 2017 12:05:25 +0200 > Currently, there is a difference in netlink events received when an > interface is modified through bridge ioctl() or through netlink. This > patch generates additional events when an interface is added to or >

Re: [Bridge] [PATCH net-next v2] bridge: also trigger RTM_NEWLINK when interface is released from bridge

From: Vincent Bernat Date: Thu, 21 Sep 2017 00:12:53 +0200 > ❦ 20 septembre 2017 15:57 -0600, David Ahern  : > >> The DELLINK is for AF_BRIDGE family (ifi_family). Adding family to >> print_linkinfo and running the monitor I get: >> >> >> [LINK]family 0:

Re: [Bridge] [PATCH net-next v2] bridge: also trigger RTM_NEWLINK when interface is released from bridge

From: Vincent Bernat Date: Sat, 16 Sep 2017 16:18:33 +0200 David, I am CC:'ing you because you've done work in this area over the past year. I'm applying this patch, it's been sitting since the 16th and likes entirely correct to me. But if you have objections just let me

Re: [Bridge] [PATCH net-next] bridge: switchdev: Use an helper to clear forward mark

From: Ido Schimmel Date: Sun, 3 Sep 2017 17:44:13 +0300 > Instead of using ifdef in the C file. > > Signed-off-by: Ido Schimmel > Suggested-by: Nikolay Aleksandrov > Tested-by: Yotam Gigi Applied.

Re: [Bridge] [PATCH net-next] bridge: add tracepoint in br_fdb_update

From: Roopa Prabhu Date: Wed, 30 Aug 2017 22:18:13 -0700 > From: Roopa Prabhu > > This extends bridge fdb table tracepoints to also cover > learned fdb entries in the br_fdb_update path. Note that > unlike other tracepoints I have moved

Re: [Bridge] [PATCH net-next v3] bridge: fdb add and delete tracepoints

From: Roopa Prabhu Date: Tue, 29 Aug 2017 13:16:57 -0700 > From: Roopa Prabhu > > A few useful tracepoints to trace bridge forwarding > database updates. > > Signed-off-by: Roopa Prabhu > --- > v2: address

Re: [Bridge] [PATCH 5/7] RDS: make rhashtable_params const

From: Bhumika Goyal Date: Fri, 25 Aug 2017 19:51:45 +0530 > Make this const as it is either used during a copy operation or passed > to a const argument of the function rhltable_init > > Signed-off-by: Bhumika Goyal Applied.

Re: [Bridge] [PATCH 4/7] ipv4: make net_protocol const

From: Bhumika Goyal Date: Fri, 25 Aug 2017 19:51:44 +0530 > Make these const as they are only passed to a const argument of the > function inet_add_protocol. > > Signed-off-by: Bhumika Goyal Applied.

Re: [Bridge] [PATCH 2/7] bridge: make ebt_table const

From: Bhumika Goyal Date: Fri, 25 Aug 2017 19:51:42 +0530 > Make this const as it is only passed to a const argument of the function > ebt_register_table. > > Signed-off-by: Bhumika Goyal Applied.

Re: [Bridge] [PATCH net] net: bridge: fix dest lookup when vlan proto doesn't match

From: Nikolay Aleksandrov Date: Thu, 13 Jul 2017 16:09:10 +0300 > With 802.1ad support the vlan_ingress code started checking for vlan > protocol mismatch which causes the current tag to be inserted and the > bridge vlan protocol & pvid to be set. The vlan tag

Re: [Bridge] [PATCH 1/1] bridge: mdb: fix leak on complete_info ptr on fail path

From: Eduardo Valentin Date: Tue, 11 Jul 2017 14:55:12 -0700 > We currently get the following kmemleak report: > unreferenced object 0x8800039d9820 (size 32): > comm "softirq", pid 0, jiffies 4295212383 (age 792.416s) > hex dump (first 32 bytes): > 00 0c e0 03 00

Re: [Bridge] [PATCH 00/36] v2 net subsystem misc refcounter conversions

From: Elena Reshetova Date: Tue, 4 Jul 2017 15:52:55 +0300 > Changes in v2: > * rebase on top of net-next > * currently by default refcount_t = atomic_t (*) and uses all >atomic standard operations unless CONFIG_REFCOUNT_FULL is enabled. >This is a

Re: [Bridge] [PATCH 1/1] bridge: mdb: report complete_info ptr as not a kmemleak

From: Eduardo Valentin Date: Mon, 3 Jul 2017 10:06:34 -0700 > We currently get the following kmemleak report: ... > This patch flags the complete_info ptr object as not a leak as it will > get freed when .complete_priv() is called, We don't call .complete_priv(). We call

Re: [Bridge] [PATCH] net: bridge: constify attribute_group structures.

From: Arvind Yadav Date: Thu, 29 Jun 2017 16:39:38 +0530 > attribute_groups are not supposed to change at runtime. All functions > working with attribute_groups provided by work with const > attribute_group. So mark the non-const structs as const. > > File size

Re: [Bridge] [PATCH 00/17] v2 net generic subsystem refcount conversions

From: Elena Reshetova Date: Wed, 28 Jun 2017 14:54:49 +0300 > If there are no objections to the patches, please merge them via > respective trees. This doesn't apply cleanly to the net-next tree, please respin.

Re: [Bridge] [PATCH net] net: bridge: fix a null pointer dereference in br_afspec

From: Nikolay Aleksandrov Date: Tue, 6 Jun 2017 01:26:24 +0300 > We might call br_afspec() with p == NULL which is a valid use case if > the action is on the bridge device itself, but the bridge tunnel code > dereferences the p pointer without checking, so check if

Re: [Bridge] [PATCH 0/2] net: Set maximum receive packet size on veth interfaces

From: Fredrik Markstrom Date: Tue, 9 May 2017 14:44:36 +0200 > Currently veth drops all packets larger then the mtu set on the > receiving end of the pair. This is inconsistent with most hardware > ethernet drivers. False. In fact, many pieces of ethernet hardware

Re: [Bridge] [PATCH net] bridge: netlink: account for IFLA_BRPORT_{B, M}CAST_FLOOD size and policy

From: Tobias Klauser Date: Fri, 5 May 2017 16:36:53 +0200 > The attribute sizes for IFLA_BRPORT_MCAST_FLOOD and > IFLA_BRPORT_BCAST_FLOOD weren't accounted for in br_port_info_size() > when they were added. Do so now and also add the corresponding policy > entries: > > Cc:

Re: [Bridge] [PATCH net-next v3] net: bridge: Fix improper taking over HW learned FDB

From: Arkadi Sharshevsky Date: Fri, 28 Apr 2017 22:39:07 +0300 > Commit 7e26bf45e4cb ("net: bridge: allow SW learn to take over HW fdb > entries") added the ability to "take over an entry which was previously > learned via HW when it shows up from a SW port". > > However,

Re: [Bridge] [PATCH net-next] net: bridge: notify on hw fdb takeover

From: Nikolay Aleksandrov Date: Fri, 14 Apr 2017 13:49:34 +0300 > Recently we added support for SW fdbs to take over HW ones, but that > results in changing a user-visible fdb flag thus we need to send a > notification, also it's consistent with how HW takes over SW

Re: [Bridge] [PATCH net v3 0/2] bridge: Fix kernel oops during bridge creation

From: ido...@idosch.org Date: Mon, 10 Apr 2017 14:59:26 +0300 > From: Ido Schimmel > > First patch adds a missing ndo_uninit() in the bridge driver, which is a > prerequisite for the second patch that actually fixes the oops. > > Please consider both patches for 4.4.y,

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

From: Nikolay Aleksandrov Date: Thu, 23 Mar 2017 12:27:11 +0200 > 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

Re: [Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Eric Dumazet Date: Tue, 21 Mar 2017 14:23:09 -0700 > It looks like our suggestion to get kernel builds with atomic_inc() > being exactly an atomic_inc() is not even discussed or implemented. > > Coding this would require less time than running a typical Google

Re: [Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Herbert Xu Date: Sun, 19 Mar 2017 00:47:59 +0800 > Eric Dumazet wrote: >> On Fri, 2017-03-17 at 07:42 +, Reshetova, Elena wrote: >> >>> Should we then first measure the actual numbers to understand what we >>> are talking here

Re: [Bridge] [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t

From: Kees Cook Date: Thu, 16 Mar 2017 11:38:25 -0600 > I am, of course, biased, but I think the evidence of actual > refcounting attacks outweighs the theoretical performance cost of > these changes. This is not theoretical at all. We count the nanoseconds that every

Re: [Bridge] [PATCH net] bridge: Fix error path in nbp_vlan_init

From: Yotam Gigi Date: Wed, 1 Mar 2017 16:50:45 +0200 > Fix error path order in nbp_vlan_init, so if switchdev_port_attr_set > call failes, the vlan_hash wouldn't be destroyed before inited. > > Fixes: efa5356b0d97 ("bridge: per vlan dst_metadata netlink support") > CC:

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

From: Stephen Hemminger Date: Tue, 7 Feb 2017 08:46:46 -0800 > Jiffies is volatile so read it once. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen.

Re: [Bridge] [PATCH net-next] bridge: remove unnecessary check for vtbegin in br_fill_vlan_tinfo_range

From: Roopa Prabhu Date: Tue, 7 Feb 2017 06:43:23 -0800 > From: Roopa Prabhu > > vtbegin should not be NULL in this function, Its already checked by the > caller. > > this should silence the below smatch complaint: >

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

From: Nikolay Aleksandrov Date: Tue, 7 Feb 2017 12:46:46 +0100 > 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

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

From: Colin King Date: Tue, 7 Feb 2017 10:56:38 + > 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

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

From: Nikolay Aleksandrov Date: Sat, 4 Feb 2017 18:05:05 +0100 > This is the first set which begins to deal with the bad bridge cache > access patterns. The first patch rearranges the bridge and port structs > a little so the frequently (and closely) accessed

Re: [Bridge] [PATCH net] ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches

From: Linus Lüssing Date: Fri, 3 Feb 2017 08:11:03 +0100 > When for instance a mobile Linux device roams from one access point to > another with both APs sharing the same broadcast domain and a > multicast snooping switch in between: > > 1)(c) <~~~> (AP1)

Re: [Bridge] [PATCH] [net-next] bridge: move maybe_deliver_addr() inside #ifdef

From: Arnd Bergmann Date: Wed, 25 Jan 2017 23:29:33 +0100 > The only caller of this new function is inside of an #ifdef checking > for CONFIG_BRIDGE_IGMP_SNOOPING, so we should move the implementation > there too, in order to avoid this harmless warning: > >

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

From: Linus Lüssing Date: Sat, 21 Jan 2017 21:01:32 +0100 > 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

Re: [Bridge] [PATCH net v3] bridge: netlink: call br_changelink() during br_dev_newlink()

From: Jiri Pirko Date: Fri, 20 Jan 2017 19:10:42 +0100 > Fri, Jan 20, 2017 at 06:12:17PM CET, c...@cera.cz wrote: >>Any bridge options specified during link creation (e.g. ip link add) >>are ignored as br_dev_newlink() does not process them. >>Use br_changelink() to do it. >>

Re: [Bridge] [PATCH net 0/3] net: bridge: fast ageing on topology change

From: Vivien Didelot Date: Sat, 10 Dec 2016 13:44:26 -0500 > 802.1D [1] specifies that the bridges in a network must use a short > value to age out dynamic entries in the Filtering Database for a period, > once a topology change has been communicated by the

Re: [Bridge] [PATCH 1/1] net: bridge: set error code on failure

From: Pan Bian Date: Sat, 3 Dec 2016 19:33:23 +0800 > Function br_sysfs_addbr() does not set error code when the call > kobject_create_and_add() returns a NULL pointer. It may be better to > return "-ENOMEM" when kobject_create_and_add() fails. > > Bugzilla:

Re: [Bridge] [PATCH] netfilter: bridge: clarify bridge/netfilter message

From: Stefan Agner Date: Wed, 28 Sep 2016 15:05:28 -0700 > When using bridge without bridge netfilter enabled the message > displayed is rather confusing and leads to belive that a deprecated > feature is in use. Use IS_MODULE to be explicit that the message only > affects users

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

From: Nikolay Aleksandrov Date: Wed, 31 Aug 2016 15:36:50 +0200 > 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.

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

From: Nikolay Aleksandrov Date: Thu, 25 Aug 2016 14:27:51 +0200 > 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

Re: [Bridge] [PATCH net-next 0/2] net: bridge: export vlan stats per-port with flags

From: Nikolay Aleksandrov Date: Wed, 17 Aug 2016 12:53:08 +0200 > This set adds the ability to export vlan stats per-port. Patch 01 makes > that possible by consolidating the bridge and port linkxstats calls. Then > patch 02 allows to dump the vlan entry flags in

Re: [Bridge] [PATCH net] bridge: Fix problems around fdb entries pointing to the bridge device

From: Toshiaki Makita Date: Thu, 4 Aug 2016 11:11:19 +0900 > Adding fdb entries pointing to the bridge device uses fdb_insert(), > which lacks various checks and does not respect added_by_user flag. > > As a result, some inconsistent behavior can happen: > *

Re: [Bridge] [PATCH net] bridge: Fix incorrect re-injection of LLDP packets

From: Ido Schimmel Date: Fri, 22 Jul 2016 14:56:20 +0300 > Commit 8626c56c8279 ("bridge: fix potential use-after-free when hook > returns QUEUE or STOLEN verdict") caused LLDP packets arriving through a > bridge port to be re-injected to the Rx path with skb->dev set to the

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

From: Nikolay Aleksandrov Date: Thu, 14 Jul 2016 06:09:58 +0300 > 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

Re: [Bridge] [PATCH net] net: bridge: fix vlan stats continue counter

From: Nikolay Aleksandrov Date: Mon, 27 Jun 2016 18:34:42 +0200 > I made a dumb off-by-one mistake when I added the vlan stats counter > dumping code. The increment should happen before the check, not after > otherwise we miss one entry when we continue dumping. > >

Re: [Bridge] [PATCH] etherdevice.h & bridge: netfilter: Add and use ether_addr_equal_masked

From: Joe Perches Date: Fri, 24 Jun 2016 11:32:26 -0700 > There are code duplications of a masked ethernet address comparison here > so make it a separate function instead. > > Miscellanea: > > o Neaten alignment of FWINV macro uses to make it clearer for the reader > >

Re: [Bridge] [PATCH net] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address

From: Linus Lüssing Date: Sat, 25 Jun 2016 16:20:28 +0200 > On Fri, Jun 24, 2016 at 12:35:18PM +0200, Daniel Danzberger wrote: >> The bridge is falsly dropping ipv6 mulitcast packets if there is: >> 1. No ipv6 address assigned on the brigde. >> 2. No external mld

<    1   2   3   4   5   >