Re: [Bridge] [PATCH v5 net-next 00/15] RX filtering in DSA

2021-06-29 Thread David Miller
From: Vladimir Oltean Date: Tue, 29 Jun 2021 22:09:23 +0300 > On Tue, Jun 29, 2021 at 09:58:22PM +0300, Vladimir Oltean wrote: >> On Tue, Jun 29, 2021 at 11:52:13AM -0700, David Miller wrote: >> > From: Vladimir Oltean >> > Date: Tue, 29 Jun 2021 17:06:43 +0300

Re: [Bridge] [PATCH v5 net-next 00/15] RX filtering in DSA

2021-06-29 Thread David Miller
From: Vladimir Oltean Date: Tue, 29 Jun 2021 17:06:43 +0300 > Changes in v5: > - added READ_ONCE and WRITE_ONCE for fdb->dst > - removed a paranoid WARN_ON in DSA > - added some documentation regarding how 'bridge fdb' is supposed to be > used with DSA Vlad, I applied v4, could you please

Re: [Bridge] [PATCH v3 net-next 07/11] net: prep switchdev drivers for concurrent SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS

2021-02-10 Thread David Miller
From: Vladimir Oltean Date: Wed, 10 Feb 2021 11:14:41 +0200 > From: Vladimir Oltean > > Because the bridge will start offloading SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS > while not serialized by any lock such as the br->lock spinlock, existing > drivers that treat that attribute and cache the

Re: [Bridge] [PATCH net] net: bridge: fdb: don't flush ext_learn entries

2020-09-28 Thread David Miller
From: Nikolay Aleksandrov Date: Mon, 28 Sep 2020 18:30:02 +0300 > From: Nikolay Aleksandrov > > When a user-space software manages fdb entries externally it should > set the ext_learn flag which marks the fdb entry as externally managed > and avoids expiring it (they're treated as static

Re: [Bridge] [PATCH net-next] net: bridge: mcast: remove only S, G port groups from sg_port hash

2020-09-25 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 25 Sep 2020 13:25:49 +0300 > From: Nikolay Aleksandrov > > We should remove a group from the sg_port hash only if it's an S,G > entry. This makes it correct and more symmetric with group add. Also > since *,G groups are not added to that hash we can hide a

Re: [Bridge] [PATCH net-next v2 00/16] net: bridge: mcast: IGMPv3/MLDv2 fast-path (part 2)

2020-09-23 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 22 Sep 2020 10:30:11 +0300 > This is the second part of the IGMPv3/MLDv2 support which adds support > for the fast-path. ... Series applied to net-next and build testing, thanks Nikolay.

Re: [Bridge] [PATCH net] net: bridge: br_vlan_get_pvid_rcu() should dereference the VLAN group under RCU

2020-09-21 Thread David Miller
From: Vladimir Oltean Date: Tue, 22 Sep 2020 01:07:09 +0300 > When calling the RCU brother of br_vlan_get_pvid(), lockdep warns: > > = > WARNING: suspicious RCU usage > 5.9.0-rc3-01631-g13c17acb8e38-dirty #814 Not tainted > - >

Re: [Bridge] [PATCH] Revert "net: linkwatch: add check for netdevice being present to linkwatch_do_dev"

2020-09-18 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 18 Sep 2020 12:35:02 + > Thanks for the analysis, I don't see any issues with checking if the device > isn't present. It will have to go through some testing, but no obvious > objections/issues. Have you tried if it fixes your case? > I have briefly gone

Re: [Bridge] [PATCH net-next] net: bridge: mcast: don't ignore return value of __grp_src_toex_excl

2020-09-16 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 15 Sep 2020 17:57:24 +0300 > When we're handling TO_EXCLUDE report in EXCLUDE filter mode we should > not ignore the return value of __grp_src_toex_excl() as we'll miss > sending notifications about group changes. > > Fixes: 5bf1e00b6849 ("net: bridge:

Re: [Bridge] [PATCH net-next] bridge: mcast: Fix incomplete MDB dump

2020-09-11 Thread David Miller
From: Ido Schimmel Date: Fri, 11 Sep 2020 16:24:47 +0300 > From: Ido Schimmel > > Each MDB entry is encoded in a nested netlink attribute called > 'MDBA_MDB_ENTRY'. In turn, this attribute contains another nested > attributed called 'MDBA_MDB_ENTRY_INFO', which encodes a single port > group

Re: [Bridge] [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3 support (part 1)

2020-09-02 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 2 Sep 2020 23:17:46 +0300 > i. e. this doesn't exclude IPv6 or makes it worse for it, on the > contrary the ops needed to > implement MLDv2 state transitions are in this set, they just need to > be extended for v6. > The new br_ip src group field contains

Re: [Bridge] [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3 support (part 1)

2020-09-02 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 2 Sep 2020 23:08:40 +0300 > Once all the infra (with fast-path) for IGMPv3 is in, MLDv2 should > be a much easier change, but I must admit given the amount of work > this required I haven't yet looked into MLDv2 in details. The > majority of the changes would

Re: [Bridge] [PATCH net-next v2 00/15] net: bridge: mcast: initial IGMPv3 support (part 1)

2020-09-02 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 2 Sep 2020 14:25:14 +0300 > Here're the sets that will come next (in order): > - Fast path patch-set which adds support for (S, G) mdb entries needed >for IGMPv3 forwarding, entry add source (kernel, user-space etc) >needed for IGMPv3 entry

Re: [Bridge] [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

2020-08-16 Thread David Miller
From: Linus Lüssing Date: Sun, 16 Aug 2020 22:24:24 +0200 > I'm aware that this is quite a hack, so I'm unsure if this is suitable > for upstream. On the other hand, the Android ticket isn't moving > anywhere and even if it were fixed in Android, I'd expect it to take > years until that fix

Re: [Bridge] [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

2020-08-16 Thread David Miller
From: Stephen Hemminger Date: Sun, 16 Aug 2020 15:08:13 -0700 > Rather than adding yet another feature to the bridge, could this hack be done > by > having a BPF hook? or netfilter module? Stephen please do not quote an entire huge patch just to add a small amount of commentary at the end.

Re: [Bridge] [PATCH net v2] net: bridge: clear skb private space on bridge dev xmit

2020-08-03 Thread David Miller
From: Nikolay Aleksandrov Date: Sun, 2 Aug 2020 15:50:39 +0300 > We need to clear all of the bridge private skb variables as they can be > stale due to the packet having skb->cb initialized earlier and then > transmitted through the bridge device. Similar memset is already done on > bridge's

Re: [Bridge] [PATCH net] net: bridge: clear bridge's private skb space on xmit

2020-08-03 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 31 Jul 2020 19:26:16 +0300 > We need to clear all of the bridge private skb variables as they can be > stale due to the packet being recirculated through the stack and then > transmitted through the bridge device. Similar memset is already done on > bridge's

Re: [Bridge] get rid of the address_space override in setsockopt v2

2020-07-26 Thread David Miller
From: Christoph Hellwig Date: Sun, 26 Jul 2020 09:03:11 +0200 > On Fri, Jul 24, 2020 at 03:43:42PM -0700, David Miller wrote: >> > Changes since v1: >> > - check that users don't pass in kernel addresses >> > - more bpfilter cleanups >> > - cosmetic m

Re: [Bridge] get rid of the address_space override in setsockopt v2

2020-07-24 Thread David Miller
From: Christoph Hellwig Date: Thu, 23 Jul 2020 08:08:42 +0200 > setsockopt is the last place in architecture-independ code that still > uses set_fs to force the uaccess routines to operate on kernel pointers. > > This series adds a new sockptr_t type that can contained either a kernel > or user

Re: [Bridge] [PATCH 24/24] net: pass a sockptr_t into ->setsockopt

2020-07-20 Thread David Miller
From: Stefan Schmidt Date: Mon, 20 Jul 2020 16:19:38 +0200 > For the ieee802154 part: > > Acked-by: Stefan Schmidt Please do not quote an entire patch just to add an ACK, trim it just to the commit message, or even less. Thank you.

Re: [Bridge] sockopt cleanups

2020-07-19 Thread David Miller
From: Christoph Hellwig Date: Fri, 17 Jul 2020 08:23:09 +0200 > this series cleans up various lose ends in the sockopt code, most > importantly removing the compat_{get,set}sockopt infrastructure in favor > of just using in_compat_syscall() in the few places that care. Series applied to

Re: [Bridge] [PATCH net-next v4 00/12] bridge: mrp: Add support for interconnect ring

2020-07-14 Thread David Miller
From: Horatiu Vultur Date: Tue, 14 Jul 2020 09:34:46 +0200 > This patch series extends existing MRP to add support for interconnect ring. ... Series applied, thank you.

Re: [Bridge] [PATCH net-next] net: bridge: notify on vlan tunnel changes done via the old api

2020-07-12 Thread David Miller
From: Nikolay Aleksandrov Date: Sat, 11 Jul 2020 18:05:04 +0300 > If someone uses the old vlan API to configure tunnel mappings we'll only > generate the old-style full port notification. That would be a problem > if we are monitoring the new vlan notifications for changes. The patch > resolves

Re: [Bridge] [PATCH net v2] bridge: mcast: Fix MLD2 Report IPv6 payload length check

2020-07-07 Thread David Miller
From: Linus Lüssing Date: Sun, 5 Jul 2020 21:10:17 +0200 > Commit e57f61858b7c ("net: bridge: mcast: fix stale nsrcs pointer in > igmp3/mld2 report handling") introduced a bug in the IPv6 header payload > length check which would potentially lead to rejecting a valid MLD2 Report: > > The check

Re: [Bridge] [PATCH net-next 02/12] bridge: uapi: mrp: Extend MRP attributes for MRP interconnect

2020-07-06 Thread David Miller
From: Horatiu Vultur Date: Mon, 6 Jul 2020 11:18:32 +0200 > +struct br_mrp_in_state { > + __u16 in_id; > + __u32 in_state; > +}; Put the __u32 first then the __u16. > +struct br_mrp_in_role { > + __u16 in_id; > + __u32 ring_id; > + __u32 in_role; > + __u32 i_ifindex; >

Re: [Bridge] [PATCH net-next 01/12] switchdev: mrp: Extend switchdev API for MRP Interconnect

2020-07-06 Thread David Miller
From: Horatiu Vultur Date: Mon, 6 Jul 2020 11:18:31 +0200 > +/* SWITCHDEV_OBJ_ID_IN_TEST_MRP */ > +struct switchdev_obj_in_test_mrp { > + struct switchdev_obj obj; > + /* The value is in us and a value of 0 represents to stop */ > + u32 interval; > + u8 max_miss; > + u32

Re: [Bridge] [PATCH net-next v3 0/3] bridge: mrp: Add support for getting the status

2020-07-02 Thread David Miller
From: Horatiu Vultur Date: Thu, 2 Jul 2020 10:13:04 +0200 > This patch series extends the MRP netlink interface to allow the userspace > daemon to get the status of the MRP instances in the kernel. > > v3: > - remove misleading comment > - fix to use correctly the RCU > > v2: > - fix

Re: [Bridge] [PATCH net] bridge: mrp: Fix endian conversion and some other warnings

2020-06-28 Thread David Miller
From: Horatiu Vultur Date: Sun, 28 Jun 2020 15:45:16 +0200 > The following sparse warnings are fixed: > net/bridge/br_mrp.c:106:18: warning: incorrect type in assignment (different > base types) > net/bridge/br_mrp.c:106:18:expected unsigned short [usertype] > net/bridge/br_mrp.c:106:18:

Re: [Bridge] [PATCH net-next v3 0/2] bridge: mrp: Extend MRP netlink interface with IFLA_BRIDGE_MRP_CLEAR

2020-06-26 Thread David Miller
From: Horatiu Vultur Date: Fri, 26 Jun 2020 09:33:47 +0200 > This patch series extends MRP netlink interface with IFLA_BRIDGE_MRP_CLEAR. > To allow the userspace to clear all MRP instances when is started. The > second patch in the series fix different sparse warnings. > > v3: > - add the

Re: [Bridge] [PATCH net-next 0/4] net: bridge: fdb activity tracking

2020-06-24 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 23 Jun 2020 23:47:14 +0300 > This set adds extensions needed for EVPN multi-homing proper and > efficient mac sync. User-space (e.g. FRR) needs to be able to track > non-dynamic entry activity on per-fdb basis depending if a tracked fdb is > currently peer

Re: [Bridge] [PATCH net v2 0/2] bridge: mrp: Update MRP_PORT_ROLE

2020-06-23 Thread David Miller
From: Horatiu Vultur Date: Tue, 23 Jun 2020 11:05:39 +0200 > This patch series does the following: > - fixes the enum br_mrp_port_role_type. It removes the port role none(0x2) > because this is in conflict with the standard. The standard defines the > interconnect port role as value 0x2. > -

Re: [Bridge] [PATCH net-next v2 0/3] bridge: mrp: Add support for MRA role

2020-06-01 Thread David Miller
From: Horatiu Vultur Date: Sat, 30 May 2020 18:09:45 + > This patch series extends the MRP with the MRA role. > A node that has the MRA role can behave as a MRM or as a MRC. In case there > are > multiple nodes in the topology that has the MRA role then only one node can > behave as MRM and

Re: [Bridge] [PATCH net 0/2] Fix infinite loop in bridge and vxlan modules

2020-06-01 Thread David Miller
From: Ido Schimmel Date: Mon, 1 Jun 2020 15:58:53 +0300 > From: Ido Schimmel > > When suppressing invalid IPv6 Neighbour Solicitation messages, it is > possible for the bridge and vxlan modules to get stuck in an infinite > loop. See the individual changelogs for detailed explanation of the >

Re: [Bridge] [PATCH] bridge: multicast: work around clang bug

2020-05-27 Thread David Miller
From: Arnd Bergmann Date: Wed, 27 May 2020 15:51:13 +0200 > Clang-10 and clang-11 run into a corner case of the register > allocator on 32-bit ARM, leading to excessive stack usage from > register spilling: > > net/bridge/br_multicast.c:2422:6: error: stack frame size of 1472 bytes in >

Re: [Bridge] [PATCH net-next v2] bridge: mrp: Rework the MRP netlink interface

2020-05-27 Thread David Miller
From: Horatiu Vultur Date: Wed, 27 May 2020 12:34:30 + > This patch reworks the MRP netlink interface. Before, each attribute > represented a binary structure which made it hard to be extended. > Therefore update the MRP netlink interface such that each existing > attribute to be a nested

Re: [Bridge] [PATCH] bridge: mrp: Fix out-of-bounds read in br_mrp_parse

2020-05-25 Thread David Miller
From: Horatiu Vultur Date: Mon, 25 May 2020 09:55:41 + > The issue was reported by syzbot. When the function br_mrp_parse was > called with a valid net_bridge_port, the net_bridge was an invalid > pointer. Therefore the check br->stp_enabled could pass/fail > depending where it was pointing

Re: [Bridge] [PATCH v2 0/3] bridge: mrp: Add br_mrp_unique_ifindex function

2020-05-22 Thread David Miller
From: Horatiu Vultur Date: Thu, 21 May 2020 23:19:04 + > This patch series adds small fixes to MRP implementation. > The following are fixed in this patch series: > - now is not allow to add the same port to multiple MRP rings > - remove unused variable > - restore the port state according

Re: [Bridge] [PATCH net-next] net: bridge: return false in br_mrp_enabled()

2020-05-06 Thread David Miller
From: Jason Yan Date: Wed, 6 May 2020 14:16:16 +0800 > Fix the following coccicheck warning: > > net/bridge/br_private.h:1334:8-9: WARNING: return of 0/1 in function > 'br_mrp_enabled' with return type bool > > Signed-off-by: Jason Yan Applied.

Re: [Bridge] [PATCH net] net: bridge: vlan: Add a schedule point during VLAN processing

2020-04-30 Thread David Miller
From: Ido Schimmel Date: Thu, 30 Apr 2020 22:38:45 +0300 > From: Ido Schimmel > > User space can request to delete a range of VLANs from a bridge slave in > one netlink request. For each deleted VLAN the FDB needs to be traversed > in order to flush all the affected entries. > > If a large

Re: [Bridge] [PATCH net-next v4 00/11] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)

2020-04-27 Thread David Miller
From: Horatiu Vultur Date: Sun, 26 Apr 2020 15:21:57 +0200 > Media Redundancy Protocol is a data network protocol standardized by > International Electrotechnical Commission as IEC 62439-2. It allows rings of > Ethernet switches to overcome any single failure with recovery time faster > than >

Re: [Bridge] [PATCH net-next 0/2] net: bridge: vlan options: nest the tunnel options

2020-03-20 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 20 Mar 2020 13:23:01 +0200 > After a discussion with Roopa about the new tunnel vlan option, she > suggested that we'll be adding more tunnel options and attributes, so > it'd be better to have them all grouped together under one main vlan > entry tunnel

Re: [Bridge] [PATCH net-next v2] net: bridge: vlan: include stats in dumps if requested

2020-03-19 Thread David Miller
From: Nikolay Aleksandrov Date: Thu, 19 Mar 2020 12:14:14 +0200 > This patch adds support for vlan stats to be included when dumping vlan > information. We have to dump them only when explicitly requested (thus the > flag below) because that disables the vlan range compression and will make >

Re: [Bridge] [PATCH net-next] net: bridge: vlan: include stats in dumps if requested

2020-03-18 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 18 Mar 2020 15:03:25 +0200 > @@ -170,11 +170,13 @@ struct bridge_stp_xstats { > /* Bridge vlan RTM header */ > struct br_vlan_msg { > __u8 family; > - __u8 reserved1; > + __u8 flags; > __u16 reserved2; > __u32 ifindex; > }; I

Re: [Bridge] [PATCH net-next 0/4] net: bridge: vlan options: add support for tunnel mapping

2020-03-18 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 17 Mar 2020 14:08:32 +0200 > In order to bring the new vlan API on par with the old one and be able > to completely migrate to the new one we need to support vlan tunnel mapping > and statistics. This patch-set takes care of the former by making it a > vlan

Re: [Bridge] [PATCH net v2] net: bridge: fix stale eth hdr pointer in br_dev_xmit

2020-02-24 Thread David Miller
From: Nikolay Aleksandrov Date: Mon, 24 Feb 2020 18:46:22 +0200 > In br_dev_xmit() we perform vlan filtering in br_allowed_ingress() but > if the packet has the vlan header inside (e.g. bridge with disabled > tx-vlan-offload) then the vlan filtering code will use skb_vlan_untag() > to extract

Re: [Bridge] [PATCH] bridge: br_stp: Use built-in RCU list checking

2020-02-19 Thread David Miller
From: madhuparnabhowmi...@gmail.com Date: Wed, 19 Feb 2020 20:47:46 +0530 > From: Madhuparna Bhowmik > > list_for_each_entry_rcu() has built-in RCU and lock checking. > > Pass cond argument to list_for_each_entry_rcu() to silence > false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled >

Re: [Bridge] [PATCH net-next v2 0/4] net: bridge: add per-vlan state option

2020-01-24 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 24 Jan 2020 13:40:18 +0200 > This set adds the first per-vlan option - state, which uses the new vlan > infrastructure that was recently added. It gives us forwarding control on > per-vlan basis. The first 3 patches prepare the vlan code to support option >

Re: [Bridge] [PATCH net-next v2 0/8] net: bridge: add vlan notifications and rtm support

2020-01-15 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 14 Jan 2020 19:56:06 +0200 > This patch-set is a prerequisite for adding per-vlan options support > because we need to be able to send vlan-only notifications and do larger > vlan netlink dumps. Per-vlan options are needed as we move the control > more to

Re: [Bridge] [RFC net-next Patch 0/3] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP)

2020-01-10 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 10 Jan 2020 16:13:36 +0200 > I agree with Stephen here, IMO you have to take note of how STP has progressed > and that bringing it in the kernel was a mistake, these days mstpd has an > active > community and much better support which is being extended. This

Re: [Bridge] [PATCH net-next v2] net: bridge: add STP xstats

2019-12-11 Thread David Miller
From: Vivien Didelot Date: Wed, 11 Dec 2019 16:47:54 -0500 > I thought the whole point of using enums was to avoid caring about fixed > numeric values, but well. I don't get where you got that idea from. Each and every netlink attribute value is like IPPROTO_TCP in an ipv4 header, the exact

Re: [Bridge] [PATCH net-next v2] net: bridge: add STP xstats

2019-12-11 Thread David Miller
From: Vivien Didelot Date: Wed, 11 Dec 2019 13:41:33 -0500 > Hi David, Nikolay, > > On Wed, 11 Dec 2019 17:42:33 +0200, Nikolay Aleksandrov > wrote: >> >> /* Bridge multicast database attributes >> >> * [MDBA_MDB] = { >> >> * [MDBA_MDB_ENTRY] = { >> >> @@ -261,6 +270,7 @@ enum { >>

Re: [Bridge] [PATCH net] net: bridge: deny dev_set_mac_address() when unregistering

2019-12-03 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 3 Dec 2019 16:48:06 +0200 > We have an interesting memory leak in the bridge when it is being > unregistered and is a slave to a master device which would change the > mac of its slaves on unregister (e.g. bond, team). This is a very > unusual setup but we

Re: [Bridge] [PATCH net-next] net: bridge: fdb: eliminate extra port state tests from fast-path

2019-11-04 Thread David Miller
From: Nikolay Aleksandrov Date: Mon, 4 Nov 2019 11:36:51 +0200 > When commit df1c0b8468b3 ("[BRIDGE]: Packets leaking out of > disabled/blocked ports.") introduced the port state tests in > br_fdb_update() it was to avoid learning/refreshing from STP BPDUs, it was > also used to avoid

Re: [Bridge] [PATCH net-next 0/7] net: bridge: convert fdbs to use bitops

2019-10-29 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 29 Oct 2019 13:45:52 +0200 > We'd like to have a well-defined behaviour when changing fdb flags. The > problem is that we've added new fields which are changed from all > contexts without any locking. We are aware of the bit test/change races > and these are

Re: [Bridge] [PATCH net v2] bridge/mdb: remove wrong use of NLM_F_MULTI

2019-09-10 Thread David Miller
From: Nicolas Dichtel Date: Fri, 6 Sep 2019 11:47:02 +0200 > NLM_F_MULTI must be used only when a NLMSG_DONE message is sent at the end. > In fact, NLMSG_DONE is sent only at the end of a dump. > > Libraries like libnl will wait forever for NLMSG_DONE. > > Fixes: 949f1e39a617 ("bridge: mdb:

Re: [Bridge] [PATCH v2 0/3] Add NETIF_F_HW_BR_CAP feature

2019-08-26 Thread David Miller
From: Andrew Lunn Date: Mon, 26 Aug 2019 14:38:11 +0200 > I'm still not convinced this is needed. The model is, the hardware is > there to accelerate what Linux can do in software. Any peculiarities > of the accelerator should be hidden in the driver. If the accelerator > can do its job without

Re: [PATCH 0/3] Add NETIF_F_HW_BRIDGE feature

2019-08-22 Thread David Miller
From: Horatiu Vultur Date: Thu, 22 Aug 2019 21:07:27 +0200 > Current implementation of the SW bridge is setting the interfaces in > promisc mode when they are added to bridge if learning of the frames is > enabled. > In case of Ocelot which has HW capabilities to switch frames, it is not >

Re: [Bridge] [PATCH net-next v3 0/4] net: bridge: mdb: allow dump/add/del of host-joined entries

2019-08-17 Thread David Miller
From: Nikolay Aleksandrov Date: Sat, 17 Aug 2019 14:22:09 +0300 > This set makes the bridge dump host-joined mdb entries, they should be > treated as normal entries since they take a slot and are aging out. > We already have notifications for them but we couldn't dump them until > now so they

Re: [PATCH net-next v2 0/4] net: bridge: mdb: allow dump/add/del of host-joined entries

2019-08-16 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 14 Aug 2019 20:04:57 +0300 > This set makes the bridge dump host-joined mdb entries, they should be > treated as normal entries since they take a slot and are aging out. ... Please respin with this warning fixed: net/bridge/br_mdb.c: In function

Re: [Bridge] [PATCH net v4] net: bridge: move default pvid init/deinit to NETDEV_REGISTER/UNREGISTER

2019-08-05 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 2 Aug 2019 13:57:36 +0300 > Most of the bridge device's vlan init bugs come from the fact that its > default pvid is created at the wrong time, way too early in ndo_init() > before the device is even assigned an ifindex. It introduces a bug when the >

Re: [PATCH net-next] net: bridge: mcast: add delete due to fast-leave mdb flag

2019-07-31 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 30 Jul 2019 15:20:41 +0300 > In user-space there's no way to distinguish why an mdb entry was deleted > and that is a problem for daemons which would like to keep the mdb in > sync with remote ends (e.g. mlag) but would also like to converge faster. > In

Re: [PATCH net] net: bridge: mcast: don't delete permanent entries when fast leave is enabled

2019-07-31 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 30 Jul 2019 14:21:00 +0300 > When permanent entries were introduced by the commit below, they were > exempt from timing out and thus igmp leave wouldn't affect them unless > fast leave was enabled on the port which was added before permanent > entries

Re: [PATCH net] net: bridge: mcast: don't delete permanent entries when fast leave is enabled

2019-07-30 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 30 Jul 2019 14:21:00 +0300 > diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c > index 3d8deac2353d..f8cac3702712 100644 > --- a/net/bridge/br_multicast.c > +++ b/net/bridge/br_multicast.c > @@ -1388,6 +1388,9 @@

Re: [PATCH net v2] net: bridge: delete local fdb on device init failure

2019-07-29 Thread David Miller
From: Nikolay Aleksandrov Date: Mon, 29 Jul 2019 12:28:41 +0300 > On initialization failure we have to delete the local fdb which was > inserted due to the default pvid creation. This problem has been present > since the inception of default_pvid. Note that currently there are 2 cases: > 1) in

Re: [PATCH net 0/4] net: bridge: fix possible stale skb pointers

2019-07-02 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 2 Jul 2019 15:00:17 +0300 > In the bridge driver we have a couple of places which call pskb_may_pull > but we've cached skb pointers before that and use them after which can > lead to out-of-bounds/stale pointer use. I've had these in my "to fix" > list for

Re: [Bridge] [PATCH v2] bridge: Fix error path for kobject_init_and_add()

2019-05-10 Thread David Miller
From: "Tobin C. Harding" Date: Fri, 10 May 2019 12:52:12 +1000 > Currently error return from kobject_init_and_add() is not followed by a > call to kobject_put(). This means there is a memory leak. We currently > set p to NULL so that kfree() may be called on it as a noop, the code is >

Re: [Bridge] [PATCH net] net: bridge: fix netlink export of vlan_stats_per_port option

2019-04-16 Thread David Miller
From: Nikolay Aleksandrov Date: Tue, 16 Apr 2019 16:15:56 +0300 > Since the introduction of the vlan_stats_per_port option the netlink > export of it has been broken since I made a typo and used the ifla > attribute instead of the bridge option to retrieve its state. > Sysfs export is fine, only

Re: [Bridge] [PATCH net] net: bridge: fix per-port af_packet sockets

2019-04-16 Thread David Miller
From: Nikolay Aleksandrov Date: Thu, 11 Apr 2019 13:56:39 +0300 > When the commit below was introduced it changed two visible things: > - the skb was no longer passed through the protocol handlers with the >original device > - the skb was passed up the stack with skb->dev = bridge > > The

Re: [Bridge] [PATCH net] net: bridge: multicast: use rcu to access port list from br_multicast_start_querier

2019-04-11 Thread David Miller
From: Nikolay Aleksandrov Date: Thu, 11 Apr 2019 15:08:25 +0300 > br_multicast_start_querier() walks over the port list but it can be > called from a timer with only multicast_lock held which doesn't protect > the port list, so use RCU to walk over it. > > Fixes: c83b8fab06fc ("bridge: Restart

Re: [Bridge] [PATCH net-next] net: bridge: mcast: remove unused br_ip_equal function

2019-04-04 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 3 Apr 2019 23:44:18 +0300 > Since the mcast conversion to rhashtable this function has been unused, so > remove it. > > Signed-off-by: Nikolay Aleksandrov Another reason to not use inline functions in foo.c files :-) Applied, thanks Nikolay.

Re: [Bridge] [PATCH net] net: bridge: always clear mcast matching struct on reports and leaves

2019-04-04 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 3 Apr 2019 23:27:24 +0300 > We need to be careful and always zero the whole br_ip struct when it is > used for matching since the rhashtable change. This patch fixes all the > places which didn't properly clear it which in turn might've caused > mismatches.

Re: [Bridge] [PATCH net-next] net: bridge: optimize backup_port fdb convergence

2019-04-04 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 3 Apr 2019 13:49:24 +0300 > We can optimize the fdb convergence when a backup_port is present by not > immediately flushing the entries of the stopped port since traffic for > those entries will flow towards the backup_port. > > There are 2 cases

Re: [Bridge] [PATCH net-next] net: bridge: update multicast stats from maybe_deliver()

2019-04-04 Thread David Miller
From: Pablo Neira Ayuso Date: Thu, 4 Apr 2019 13:56:38 +0200 > Simplify this code by updating bridge multicast stats from > maybe_deliver(). > > Note that commit 6db6f0eae605 ("bridge: multicast to unicast"), in case > the port flag BR_MULTICAST_TO_UNICAST is set, never updates the previous >

Re: [Bridge] [PATCH net-next] net: bridge: use eth_broadcast_addr() to assign broadcast address

2019-03-20 Thread David Miller
From: Mao Wenan Date: Wed, 20 Mar 2019 10:06:57 +0800 > This patch is to use eth_broadcast_addr() to assign broadcast address > insetad of memset(). > > Signed-off-by: Mao Wenan Applied.

Re: [Bridge] [PATCH net-next] switchdev: Remove unused transaction item queue

2019-03-01 Thread David Miller
From: Florian Fainelli Date: Wed, 27 Feb 2019 16:29:16 -0800 > There are no more in tree users of the > switchdev_trans_item_{dequeue,enqueue} or switchdev_trans_item structure > in the kernel since commit 00fc0c51e35b ("rocker: Change world_ops API > and implementation to be switchdev

Re: [Bridge] [PATCH net-next v3 0/8] net: Remove switchdev_ops

2019-02-27 Thread David Miller
From: Florian Fainelli Date: Wed, 27 Feb 2019 11:44:24 -0800 > This patch series completes the removal of the switchdev_ops by > converting switchdev_port_attr_set() to use either the blocking > (process) or non-blocking (atomic) notifier since we typically need to > deal with both depending on

Re: [Bridge] [PATCH net] Revert "bridge: do not add port to router list when receives query with source 0.0.0.0"

2019-02-23 Thread David Miller
From: Hangbin Liu Date: Fri, 22 Feb 2019 21:22:32 +0800 > This reverts commit 5a2de63fd1a5 ("bridge: do not add port to router list > when receives query with source 0.0.0.0") and commit 0fe5119e267f ("net: > bridge: remove ipv6 zero address check in mcast queries") > > The reason is RFC 4541

Re: [Bridge] [PATCH net-next v2 0/9] net: Get rid of switchdev_port_attr_get()

2019-02-15 Thread David Miller
From: Florian Fainelli Date: Fri, 15 Feb 2019 16:37:38 -0800 > David, please ignore this version, I will repost one that actually > builds, need to keep mangling with my kernel configuration and keep > those drivers enabled... Ok.

Re: [Bridge] [PATCH net-next 0/3] Remove getting SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS

2019-02-12 Thread David Miller
From: Florian Fainelli Date: Mon, 11 Feb 2019 13:17:46 -0800 > AFAICT there is no code that attempts to get the value of the attribute > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS while it is used with > switchdev_port_attr_set(). > > This is effectively no doing anything and it can slow down future

Re: [Bridge] [PATCH net-next v4 0/9] net: Remove switchdev_ops

2019-02-11 Thread David Miller
From: Florian Fainelli Date: Mon, 11 Feb 2019 11:09:52 -0800 > David, I would like to get Ido's feedback on this to make sure I did not > miss something, thank you! Ok, Ido please look at this when you can.

Re: [Bridge] [PATCH net-next v3 0/9] net: Remove switchdev_ops

2019-02-11 Thread David Miller
From: Florian Fainelli Date: Mon, 11 Feb 2019 09:31:42 -0800 > David, I will be reposting a v4 with Jiri's Acked-by as well as adding > fallthrough switch/case annotations so we don't regress on that front. > Thank you. Ok, thanks for letting me know.

Re: [Bridge] [PATCH net-next v2 00/16] net: Remove switchdev_ops

2019-02-10 Thread David Miller
From: Florian Fainelli Date: Sun, 10 Feb 2019 12:44:47 -0800 > I am going to submit a v3 which moves the port_attr_{get,set} to a > switchdev notifier, but does not yet get rid of > switchdev_port_attr_get() entirely since there is not a clear path yet > to split the setting between non-sleeping

Re: [Bridge] [PATCH net-next] bridge: use struct_size() helper

2019-02-08 Thread David Miller
From: "Gustavo A. R. Silva" Date: Thu, 7 Feb 2019 18:58:56 -0600 > One of the more common cases of allocation size calculations is finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: > > struct

Re: [Bridge] [PATCH net-next v4 00/12] net: Introduce ndo_get_port_parent_id()

2019-02-06 Thread David Miller
From: David Miller Date: Wed, 06 Feb 2019 13:50:50 -0800 (PST) > From: Florian Fainelli > Date: Wed, 6 Feb 2019 09:45:34 -0800 > >> Based on discussion with Ido and feedback from Jakub there are clearly >> two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARE

Re: [Bridge] [PATCH net-next v4 00/12] net: Introduce ndo_get_port_parent_id()

2019-02-06 Thread David Miller
From: Florian Fainelli Date: Wed, 6 Feb 2019 09:45:34 -0800 > Based on discussion with Ido and feedback from Jakub there are clearly > two classes of users that implement SWITCHDEV_ATTR_ID_PORT_PARENT_ID: > > - PF/VF drivers which typically only implement return the port's parent > ID, yet

Re: [Bridge] [PATCH net-next] net: Fix ip_mc_{dec, inc}_group allocation context

2019-02-03 Thread David Miller
From: Florian Fainelli Date: Fri, 1 Feb 2019 20:20:52 -0800 > After 4effd28c1245 ("bridge: join all-snoopers multicast address"), I > started seeing the following sleep in atomic warnings: ... > while toggling the bridge's multicast_snooping attribute dynamically. > > Pass a gfp_t down to

Re: [Bridge] [PATCH net-next] bridge: remove duplicated include from br_multicast.c

2019-01-24 Thread David Miller
From: YueHaibing Date: Fri, 25 Jan 2019 10:59:09 +0800 > Remove duplicated include. > > Signed-off-by: YueHaibing Applied.

Re: [Bridge] [PATCH net v4] net: bridge: Fix ethernet header pointer before check skb forwardable

2019-01-17 Thread David Miller
From: wangyunjian Date: Thu, 17 Jan 2019 09:46:41 +0800 > From: Yunjian Wang > > The skb header should be set to ethernet header before using > is_skb_forwardable. Because the ethernet header length has been > considered in is_skb_forwardable(including dev->hard_header_len > length). > > To

Re: [Bridge] [PATCH net] net: rtnetlink: address is mandatory for rtnl_fdb_get

2018-12-30 Thread David Miller
From: Nikolay Aleksandrov Date: Sun, 30 Dec 2018 14:33:20 +0200 > We must have an address to lookup otherwise we'll derefence a null > pointer in the ndo_fdb_get callbacks. > > CC: Roopa Prabhu > CC: David Ahern > Reported-by: syzbot+017b1f61c82a1c3e7...@syzkaller.appspotmail.com > Fixes:

Re: [Bridge] [PATCH net-next] net: bridge: remove unneeded variable 'err'

2018-12-18 Thread David Miller
From: YueHaibing Date: Mon, 17 Dec 2018 17:46:23 +0800 > function br_multicast_toggle now always return 0, > so the variable 'err' is unneeded. > Also cleanup dead branch in br_changelink. > > Signed-off-by: YueHaibing Applied.

Re: [Bridge] [PATCH net-next] Documentation: networking: Clarify switchdev devices behavior

2018-12-15 Thread David Miller
From: Florian Fainelli Date: Wed, 12 Dec 2018 15:09:43 -0800 > This patch provides details on the expected behavior of switchdev > enabled network devices when operating in a "stand alone" mode, as well > as when being bridge members. This clarifies a number of things that > recently came up

Re: [Bridge] [PATCH net-next v2 0/9] Pass extack to SWITCHDEV_PORT_OBJ_ADD

2018-12-12 Thread David Miller
From: Petr Machata Date: Wed, 12 Dec 2018 17:02:46 + > Drivers may need to do validation as a result of port object addition. > An example is mlxsw, which needs to check the configuration of a VXLAN > device attached to an offloaded bridge. Without a mapped VLAN, the > invalidity of the

Re: [Bridge] [PATCH net-next v2 00/12] mlxsw: Un/offload FDB on NVE detach/attach

2018-12-07 Thread David Miller
From: Ido Schimmel Date: Fri, 7 Dec 2018 19:55:01 + > Petr says: > > When a VXLAN device is attached to a bridge of a driver capable of > offloading such, or upped, the FDB entries already present at the device > need to be offloaded. Similarly when an offloaded VXLAN device ceases > being

Re: [Bridge] [PATCH net-next 01/12] vxlan: Add a function to init switchdev_notifier_vxlan_fdb_info

2018-12-05 Thread David Miller
From: Ido Schimmel Date: Wed, 5 Dec 2018 15:50:23 + > +static struct switchdev_notifier_vxlan_fdb_info > +vxlan_fdb_switchdev_notifier_info(const struct vxlan_dev *vxlan, > + const struct vxlan_fdb *fdb, > + const struct vxlan_rdst

Re: [Bridge] [PATCH net-next v3 0/4] net: bridge: convert multicast to generic rhashtable

2018-12-05 Thread David Miller
From: Nikolay Aleksandrov Date: Wed, 5 Dec 2018 15:14:23 +0200 > The current bridge multicast code uses a custom rhashtable > implementation which predates the generic rhashtable API. Patch 01 > converts it to use the generic kernel rhashtable which simplifies the > code a lot and removes

Re: [Bridge] [PATCH net-next v2 0/3] net: bridge: add an option to disabe linklocal learning

2018-11-27 Thread David Miller
From: Nikolay Aleksandrov Date: Sat, 24 Nov 2018 04:34:19 +0200 > This set adds a new bridge option which can control learning from > link-local packets, by default learning is on to be consistent and avoid > breaking users expectations. If the new no_linklocal_learn option is > enabled then the

Re: [Bridge] [PATCH][V2] net: bridge: remove redundant checks for null p->dev and p->br

2018-11-25 Thread David Miller
my reasoning as I might be missing something in > sysfs/kernfs call path." > > Thanks to Nikolay Aleksandrov's suggestion to remove the check and > David Miller for sanity checking this. > > Detected by CoverityScan, CID#751490 ("Dereference before null check") > > Fixes: a5f3ea54f3cc ("net: bridge: add support for raw sysfs port options") > Signed-off-by: Colin Ian King Applied.

Re: [Bridge] [PATCH] net: bridge: check for a null p->dev before dereferencing it

2018-11-24 Thread David Miller
From: Nikolay Aleksandrov Date: Sat, 24 Nov 2018 14:21:07 +0200 > I was contacted recently about this privately and this was my reply: > "Checking new_nbp() and del_nbp() it should not be possible to reach that code > with p->dev or p->br as NULL. The cap check code has always been there, I just

Re: [Bridge] [PATCH net-next 00/16] mlxsw: Add VxLAN learning support

2018-11-21 Thread David Miller
From: Ido Schimmel Date: Wed, 21 Nov 2018 08:02:32 + > This patchset adds VxLAN learning support in the mlxsw driver. Looks great, series applied, thanks Ido.

Re: [Bridge] [PATCH net v3] net: bridge: fix vlan stats use-after-free on destruction

2018-11-17 Thread David Miller
From: Nikolay Aleksandrov Date: Fri, 16 Nov 2018 18:50:01 +0200 > Syzbot reported a use-after-free of the global vlan context on port vlan > destruction. When I added per-port vlan stats I missed the fact that the > global vlan context can be freed before the per-port vlan rcu callback. >

  1   2   3   4   5   >