pm24.git/net/bridge, branch v5.7

bridge: multicast: work around clang bug

2020-05-27T18:34:48Z

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 function 'br_multicast_get_stats' [-Werror,-Wframe-larger-than=] Work around this by marking one of the internal functions as noinline_for_stack. Link: https://bugs.llvm.org/show_bug.cgi?id=45802#c9 Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller

netfilter: nft_reject_bridge: enable reject with bridge vlan

2020-05-25T18:39:05Z

Currently, using the bridge reject target with tagged packets results in untagged packets being sent back. Fix this by mirroring the vlan id as well. Fixes: 85f5b3086a04 ("netfilter: bridge: add reject support") Signed-off-by: Michael Braun Signed-off-by: Pablo Neira Ayuso

net: bridge: vlan: Add a schedule point during VLAN processing

2020-05-01T00:45:41Z

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 range of VLANs is deleted and the number of FDB entries is large or the FDB lock is contented, it is possible for the kernel to loop through the deleted VLANs for a long time. In case preemption is disabled, this can result in a soft lockup. Fix this by adding a schedule point after each VLAN is deleted to yield the CPU, if needed. This is safe because the VLANs are traversed in process context. Fixes: bdced7ef7838 ("bridge: support for multiple vlans and vlan ranges in setlink and dellink requests") Signed-off-by: Ido Schimmel Reported-by: Stefan Priebe - Profihost AG Tested-by: Stefan Priebe - Profihost AG Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

net: bridge: vlan options: move the tunnel command to the nested attribute

2020-03-20T15:52:20Z

Now that we have a nested tunnel info attribute we can add a separate one for the tunnel command and require it explicitly from user-space. It must be one of RTM_SETLINK/DELLINK. Only RTM_SETLINK requires a valid tunnel id, DELLINK just removes it if it was set before. This allows us to have all tunnel attributes and control in one place, thus removing the need for an outside vlan info flag. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

net: bridge: vlan options: nest the tunnel id into a tunnel info attribute

2020-03-20T15:52:20Z

While discussing the new API, Roopa mentioned that we'll be adding more tunnel attributes and options in the future, so it's better to make it a nested attribute, since this is still in net-next we can easily change it and nest the tunnel id attribute under BRIDGE_VLANDB_ENTRY_TUNNEL_INFO. The new format is: [BRIDGE_VLANDB_ENTRY] [BRIDGE_VLANDB_ENTRY_TUNNEL_INFO] [BRIDGE_VLANDB_TINFO_ID] Any new tunnel attributes can be nested under BRIDGE_VLANDB_ENTRY_TUNNEL_INFO. Suggested-by: Roopa Prabhu Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

net: bridge: vlan: include stats in dumps if requested

2020-03-20T03:21:47Z

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 the dump significantly larger. In order to request the stats to be included we add a new dump attribute called BRIDGE_VLANDB_DUMP_FLAGS which can affect dumps with the following first flag: - BRIDGE_VLANDB_DUMPF_STATS The stats are intentionally nested and put into separate attributes to make it easier for extending later since we plan to add per-vlan mcast stats, drop stats and possibly STP stats. This is the last missing piece from the new vlan API which makes the dumped vlan information complete. A dump request which should include stats looks like: [BRIDGE_VLANDB_DUMP_FLAGS] |= BRIDGE_VLANDB_DUMPF_STATS A vlandb entry attribute with stats looks like: [BRIDGE_VLANDB_ENTRY] = { [BRIDGE_VLANDB_ENTRY_STATS] = { [BRIDGE_VLANDB_STATS_RX_BYTES] [BRIDGE_VLANDB_STATS_RX_PACKETS] ... } } Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next

2020-03-18T06:51:31Z

Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Use nf_flow_offload_tuple() to fetch flow stats, from Paul Blakey. 2) Add new xt_IDLETIMER hard mode, from Manoj Basapathi. Follow up patch to clean up this new mode, from Dan Carpenter. 3) Add support for geneve tunnel options, from Xin Long. 4) Make sets built-in and remove modular infrastructure for sets, from Florian Westphal. 5) Remove unused TEMPLATE_NULLS_VAL, from Li RongQing. 6) Statify nft_pipapo_get, from Chen Wandun. 7) Use C99 flexible-array member, from Gustavo A. R. Silva. 8) More descriptive variable names for bitwise, from Jeremy Sowden. 9) Four patches to add tunnel device hardware offload to the flowtable infrastructure, from wenxu. 10) pipapo set supports for 8-bit grouping, from Stefano Brivio. 11) pipapo can switch between nibble and byte grouping, also from Stefano. 12) Add AVX2 vectorized version of pipapo, from Stefano Brivio. 13) Update pipapo to be use it for single ranges, from Stefano. 14) Add stateful expression support to elements via control plane, eg. counter per element. 15) Re-visit sysctls in unprivileged namespaces, from Florian Westphal. 15) Add new egress hook, from Lukas Wunner. ==================== Signed-off-by: David S. Miller

net: bridge: vlan options: add support for tunnel mapping set/del

2020-03-18T05:47:12Z

This patch adds support for manipulating vlan/tunnel mappings. The tunnel ids are globally unique and are one per-vlan. There were two trickier issues - first in order to support vlan ranges we have to compute the current tunnel id in the following way: - base tunnel id (attr) + current vlan id - starting vlan id This is in line how the old API does vlan/tunnel mapping with ranges. We already have the vlan range present, so it's redundant to add another attribute for the tunnel range end. It's simply base tunnel id + vlan range. And second to support removing mappings we need an out-of-band way to tell the option manipulating function because there are no special/reserved tunnel id values, so we use a vlan flag to denote the operation is tunnel mapping removal. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

net: bridge: vlan options: add support for tunnel id dumping

2020-03-18T05:47:12Z

Add a new option - BRIDGE_VLANDB_ENTRY_TUNNEL_ID which is used to dump the tunnel id mapping. Since they're unique per vlan they can enter a vlan range if they're consecutive, thus we can calculate the tunnel id range map simply as: vlan range end id - vlan range start id. The starting point is the tunnel id in BRIDGE_VLANDB_ENTRY_TUNNEL_ID. This is similar to how the tunnel entries can be created in a range via the old API (a vlan range maps to a tunnel range). Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

net: bridge: vlan tunnel: constify bridge and port arguments

2020-03-18T05:47:12Z

The vlan tunnel code changes vlan options, it shouldn't touch port or bridge options so we can constify the port argument. This would later help us to re-use these functions from the vlan options code. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller