- 14 Dec, 2018 30 commits
-
-
Peter Oskolkov authored
A relatively common use case is to have several IPs configured on a host, and have different listeners for each of them. We would like to add a "catch all" listener on addr_any, to match incoming connections not served by any of the listeners bound to a specific address. However, port-only lookups can match addr_any sockets when sockets listening on specific addresses are present if so_reuseport flag is set. This patch eliminates lookups into port-only hashtable, as lookups by (addr,port) tuple are easily available. In addition, compute_score() is tweaked to _not_ match addr_any sockets to specific addresses, as hash collisions could result in the unwanted behavior described above. Tested: the patch compiles; full test in the last patch in this patchset. Existing reuseport_* selftests also pass. Suggested-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Peter Oskolkov <posk@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peter Oskolkov authored
A relatively common use case is to have several IPs configured on a host, and have different listeners for each of them. We would like to add a "catch all" listener on addr_any, to match incoming connections not served by any of the listeners bound to a specific address. However, port-only lookups can match addr_any sockets when sockets listening on specific addresses are present if so_reuseport flag is set. This patch eliminates lookups into port-only hashtable, as lookups by (addr,port) tuple are easily available. In addition, compute_score() is tweaked to _not_ match addr_any sockets to specific addresses, as hash collisions could result in the unwanted behavior described above. Tested: the patch compiles; full test in the last patch in this patchset. Existing reuseport_* selftests also pass. Suggested-by:
-
Peter Oskolkov authored
A relatively common use case is to have several IPs configured on a host, and have different listeners for each of them. We would like to add a "catch all" listener on addr_any, to match incoming connections not served by any of the listeners bound to a specific address. However, port-only lookups can match addr_any sockets when sockets listening on specific addresses are present if so_reuseport flag is set. This patch eliminates lookups into port-only hashtable, as lookups by (addr,port) tuple are easily available. In addition, compute_score() is tweaked to _not_ match addr_any sockets to specific addresses, as hash collisions could result in the unwanted behavior described above. Tested: the patch compiles; full test in the last patch in this patchset. Existing reuseport_* selftests also pass. Suggested-by:
-
Peter Oskolkov authored
A relatively common use case is to have several IPs configured on a host, and have different listeners for each of them. We would like to add a "catch all" listener on addr_any, to match incoming connections not served by any of the listeners bound to a specific address. However, port-only lookups can match addr_any sockets when sockets listening on specific addresses are present if so_reuseport flag is set. This patch eliminates lookups into port-only hashtable, as lookups by (addr,port) tuple are easily available. In addition, compute_score() is tweaked to _not_ match addr_any sockets to specific addresses, as hash collisions could result in the unwanted behavior described above. Tested: the patch compiles; full test in the last patch in this patchset. Existing reuseport_* selftests also pass. Suggested-by:
-
yupeng authored
Add explainations for some general IP counters, SACK and DSACK related counters Signed-off-by:
yupeng <yupeng0921@gmail.com> Signed-off-by:
-
David S. Miller authored
David Ahern says: ==================== neighbor: More gc_list changes More gc_list changes and cleanups. The first 2 patches are bug fixes from the first gc_list change. Specifically, fix the locking order to be consistent - table lock followed by neighbor lock, and then entries in the FAILED state should always be candidates for forced_gc without waiting for any time span (return to the eviction logic prior to the separate gc_list). Patch 3 removes 2 now unnecessary arguments to neigh_del. Patch 4 moves a helper from a header file to core code in preparation for Patch 5 which removes NTF_EXT_LEARNED entries from the gc_list. These entries are already exempt from forced_gc; patch 5 removes them from consideration and makes them on par with PERMANENT entries given that they are also managed by userspace. ==================== Signed-off-by: -
David Ahern authored
Externally learned entries are similar to PERMANENT entries in the sense they are managed by userspace and can not be garbage collected. As such remove them from the gc_list, remove the flags check from neigh_forced_gc and skip threshold checks in neigh_alloc. As with PERMANENT entries, this allows unlimited number of NTF_EXT_LEARNED entries. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David Ahern authored
neigh_update_ext_learned has one caller in neighbour.c so does not need to be defined in the header. Move it and in the process remove the intialization of ndm_flags and just set it based on the flags check. Signed-off-by:
-
David Ahern authored
neigh_del now only has 1 caller, and the state and flags arguments are both 0. Remove them and simplify neigh_del. Signed-off-by:
-
David Ahern authored
PERMANENT entries are not on the gc_list so the state check is now redundant. Also, the move to not purge entries until after 5 seconds should not apply to FAILED entries; those can be removed immediately to make way for newer ones. This restores the previous logic prior to the gc_list. Fixes: 58956317 ("neighbor: Improve garbage collection") Signed-off-by:
-
David Ahern authored
Lock checker noted an inverted lock order between neigh_change_state (neighbor lock then table lock) and neigh_periodic_work (table lock and then neighbor lock) resulting in: [ 121.057652] ====================================================== [ 121.058740] WARNING: possible circular locking dependency detected [ 121.059861] 4.20.0-rc6+ #43 Not tainted [ 121.060546] ------------------------------------------------------ [ 121.061630] kworker/0:2/65 is trying to acquire lock: [ 121.062519] (____ptrval____) (&n->lock){++--}, at: neigh_periodic_work+0x237/0x324 [ 121.063894] [ 121.063894] but task is already holding lock: [ 121.064920] (____ptrval____) (&tbl->lock){+.-.}, at: neigh_periodic_work+0x194/0x324 [ 121.066274] [ 121.066274] which lock already depends on the new lock. [ 121.066274] [ 121.067693] [ 121.067693] the existing dependency chain (in reverse order) is: ... Fix by renaming neigh_change_state to neigh_update_gc_list, changing it to only manage whether an entry should be on the gc_list and taking locks in the same order as neigh_periodic_work. Invoke at the end of neigh_update only if diff between old or new states has the PERMANENT flag set. Fixes: 8cc196d6 ("neighbor: gc_list changes should be protected by table lock") Signed-off-by: -
Cong Wang authored
After commit 69bd4840 ("net/sched: Remove egdev mechanism"), tc_setup_cb_call() is nearly identical to tcf_block_cb_call(), so we can just fold tcf_block_cb_call() into tc_setup_cb_call() and remove its unused parameter 'exts'. Fixes: 69bd4840 ("net/sched: Remove egdev mechanism") Cc: Oz Shlomo <ozsh@mellanox.com> Cc: Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
Oz Shlomo <ozsh@mellanox.com> Signed-off-by:
-
Wen Yang authored
The driver was checking for non-NULL address. - adapter->napi[i] This is pointless as these will be always non-NULL, since the 'dapter->napi' is allocated in init_napi(). It is safe to get rid of useless checks for addresses to fix the coccinelle warning: >>drivers/net/ethernet/ibm/ibmvnic.c: test of a variable/field address Since such statements always return true, they are redundant. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: Michael Ellerman <mpe@ellerman.id.au> CC: Thomas Falcon <tlfalcon@linux.ibm.com> CC: John Allen <jallen@linux.ibm.com> CC: "David S. Miller" <davem@davemloft.net> CC: linuxppc-dev@lists.ozlabs.org CC: netdev@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by:
-
Prashant Bhole authored
tun_xdp_one() runs with local bh disabled. So there is no need to disable preemption by calling get_cpu_ptr while updating stats. This patch replaces the use of get_cpu_ptr() with this_cpu_ptr() as a micro-optimization. Also removes related put_cpu_ptr call. Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
ppp and hamradio have copies of the same code that uses a semaphore in place of a completion for historic reasons. Make it use the proper interface instead in all copies. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
We now get a link failure when CONFIG_INET is disabled, since tcp_gro_complete is unavailable: drivers/net/ethernet/hisilicon/hns3/hns3_enet.o: In function `hns3_set_gro_param': hns3_enet.c:(.text+0x230c): undefined reference to `tcp_gro_complete' Add an explicit CONFIG_INET dependency here to avoid the broken configuration. Fixes: a6d53b97 ("net: hns3: Adds GRO params to SKB for the stack") Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== Introduce NETDEV_PRE_CHANGEADDR Spectrum devices have a limitation that all router interfaces need to have the same address prefix. In Spectrum-1, the requirement is for the initial 38 bits of all RIFs to be the same, in Spectrum-2 the limit is 36 bits. Currently violations of this requirement are not diagnosed. At the same time, if the condition is not upheld, the mismatched MAC address ends up overwriting the common prefix, and all RIF MAC addresses silently change to the new prefix. It is therefore desirable to be able at least to diagnose the issue, and better to reject attempts to change MAC addresses in ways that is incompatible with the device. Currently MAC address changes are notified through emission of NETDEV_CHANGEADDR, which is done after the change. Extending this message to allow vetoing is certainly possible, but several other notification types have instead adopted a simple two-stage approach: first a "pre" notification is sent to make sure all interested parties are OK with the change that's about to be done. Then the change is done, and afterwards a "post" notification is sent. This dual approach is easier to use: when the change is vetoed, nothing has changed yet, and it's therefore unnecessary to roll anything back. Therefore this patchset introduces it for NETDEV_CHANGEADDR as well. One prominent path to emitting NETDEV_CHANGEADDR is through dev_set_mac_address(). Therefore in patch #1, give this function an extack argument, so that a textual reason for rejection (or a warning) can be communicated back to the user. In patch #2, add the new notification type. In patch #3, have dev.c emit the notification for instances of dev_addr change, or addition of an address to dev_addrs list. In patches #4 and #5, extend the bridge driver to handle and emit the new notifier. In patch #6, change IPVLAN to emit the new notifier. Likewise for bonding driver in patches #7 and #8. Note that the team driver doesn't need this treatment, as it goes through dev_set_mac_address(). In patches #9, #10 and #11 adapt mlxsw to veto MAC addresses on router interfaces, if they violate the requirement that all RIF MAC addresses have the same prefix. Finally in patches #12 and #13, add a test for vetoing of a direct change of a port device MAC, and indirect change of a bridge MAC. ==================== Signed-off-by: -
Petr Machata authored
When a FID RIF is created for a bridge with IP address, its MAC address must obey the same requirements as other RIFs. Test that attempts to change the address incompatibly by attaching a device are vetoed with extack. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
Test that attempts to change address in a way that violates Spectrum requirements are vetoed with extack. Signed-off-by:
-
Petr Machata authored
On NETDEV_PRE_CHANGEADDR, if the change is related to a RIF interface, verify that it satisfies the criterion that all RIF interfaces have the same MAC address prefix, as indicated by mlxsw_sp.mac_mask. Additionally, besides explicit address changes, check that the address of an interface for which a RIF is about to be added matches the required pattern as well. Signed-off-by:
-
Petr Machata authored
The Spectrum hardware demands that all router interfaces in the system have the same first 38 resp. 36 bits of MAC address: the former limit holds on Spectrum, the latter on Spectrum-2. Add a field that refers to the required prefix mask and initialize in mlxsw_sp1_init() and mlxsw_sp2_init(). Signed-off-by:
-
Petr Machata authored
Prepare mlxsw_sp_netdevice_router_port_event() for handling of NETDEV_PRE_CHANGEADDR. Split out the part that deals with the actual changes and call it for the two events currently handled. Signed-off-by:
-
Petr Machata authored
Give interested parties an opportunity to veto an impending HW address change. Signed-off-by:
-
Petr Machata authored
Before NETDEV_CHANGEADDR, bond driver should emit NETDEV_PRE_CHANGEADDR, and allow consumers to veto the address change. To propagate further the return code from NETDEV_PRE_CHANGEADDR, give the function that implements address change a return value. Signed-off-by:
-
Petr Machata authored
A NETDEV_CHANGEADDR event implies a change of address of each of the IPVLANs of this IPVLAN device. Therefore propagate NETDEV_PRE_CHANGEADDR to all the IPVLANs. Signed-off-by:
-
Petr Machata authored
When a port device seeks approval of a potential new MAC address, make sure that should the bridge device end up using this address, all interested parties would agree with it. Signed-off-by:
-
Petr Machata authored
When a port is attached to a bridge, the address of the bridge in question may change as well. Even if it would not change at this point (because the current bridge address is lower), it might end up changing later as a result of detach of another port, which can't be vetoed. Therefore issue NETDEV_PRE_CHANGEADDR regardless of whether the address will be used at this point or not, and make sure all involved parties would agree with the change. Signed-off-by:
-
Petr Machata authored
When a device address is about to be changed, or an address added to the list of device HW addresses, it is necessary to ensure that all interested parties can support the address. Therefore, send the NETDEV_PRE_CHANGEADDR notification, and if anyone bails on it, do not change the address. Signed-off-by:
-
Petr Machata authored
The NETDEV_CHANGEADDR notification is emitted after a device address changes. Extending this message to allow vetoing is certainly possible, but several other notification types have instead adopted a simple two-stage approach: first a "pre" notification is sent to make sure all interested parties are OK with a change that's about to be done. Then the change is done, and afterwards a "post" notification is sent. This dual approach is easier to use: when the change is vetoed, nothing has changed yet, and it's therefore unnecessary to roll anything back. Therefore adopt it for NETDEV_CHANGEADDR as well. To that end, add NETDEV_PRE_CHANGEADDR and an info structure to go along with it. Signed-off-by:
-
Petr Machata authored
A follow-up patch will add a notifier type NETDEV_PRE_CHANGEADDR, which allows vetoing of MAC address changes. One prominent path to that notification is through dev_set_mac_address(). Therefore give this function an extack argument, so that it can be packed together with the notification. Thus a textual reason for rejection (or a warning) can be communicated back to the user. Signed-off-by:
-
- 13 Dec, 2018 10 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5e-updates-2018-12-11 From Eli Britstein, Patches 1-10 adds remote mirroring support. Patches 1-4 refactor encap related code as pre-steps for using per destination encapsulation properties. Patches 5-7 use extended destination feature for single/multi destination scenarios that have a single encap destination. Patches 8-10 enable multiple encap destinations for a TC flow. From, Daniel Jurgens, Patch 11, Use CQE padding for Ethernet CQs, PPC showed up to a 24% improvement in small packet throughput From Eyal Davidovich, patches 12-14, FW monitor counter support FW monitor counters feature came to solve the delayed reporting of FW stats in the atomic get_stats64 ndo, since we can't access the FW at that stage, this feature will enable immediate FW stats updates in the driver via fw events on specific stats updates. Patch 12, cleanup to avoid querying a FW counter when it is not supported Patch 13, Monitor counters FW commands support Patch 14, Use monitor counters in ethernet netdevice to update FW stats reported in the atomic get_stats64 ndo. ==================== Signed-off-by: -
Biao Huang authored
Add MODULE_LICENSE info to fix this: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.o Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_load': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1490:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_vport_rep_unload': drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:1557:21: warning: variable 'upriv' set but not used [-Wunused-but-set-variable] It not used any more since commit ef381359 ("net/mlx5e: Replace egdev with indirect block notifications"). Also remove unused variable 'uplink_rpriv' after this change. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@mellanox.com> Acked-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
David S. Miller authored
Petr Machata says: ==================== Pass extack to SWITCHDEV_PORT_OBJ_ADD 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 device is not important, but as soon as a pvid, untagged VLAN is configured for the device, it has to be validated and offloaded. Should the validation fail, there's currently no way to communicate details of the failure to the user, beyond an error number. Because currently, extack is not available at all in that area of code, this patch starts down at the RTNL level and progresses up towards the driver(s). In patch #1, ndo_bridge_setlink is updated to include extack, and callbacks of all clients are updated as well (ignoring the argument). In patch #2, the bridge driver is updated to propagate the extack through to the switchdev border, br_switchdev_port_vlan_add(). Patches #3, #4 and #5 then gradually extend switchdev to pass the extack argument through to the switchdev blocking notifier chain. Patches #6 and #7 then update mlxsw to pass the extack argument from VXLAN events resp. port events on to mlxsw_sp_bridge_8021q_vxlan_join(). Finally in patches #8 and #9, the code paths from the previous two patches are verified to yield an error message. v2: - Patch #1: - In ndo_bridge_setlink(), keep the whole extack declaration on the same line. ==================== Signed-off-by: -
Petr Machata authored
Test mapping a VLAN at a port device such that on the same VLAN, there already is an unoffloadable VXLAN device. Signed-off-by:
-
Petr Machata authored
Test mapping a VLAN at a VXLAN device that can't be offloaded. Signed-off-by:
-
Petr Machata authored
After switchdev_handle_port_obj_add() was extended in a preceding patch, mlxsw_sp_port_obj_add() now takes an extack argument. Propagate it further by extending a callee chain from mlxsw_sp_port_vlans_add(), via mlxsw_sp_bridge_port_vlan_add() via mlxsw_sp_port_vlan_bridge_join() via mlxsw_sp_port_vlan_fid_join() to mlxsw_sp_bridge_ops.fid_get, adding an extack argument for each of them. This code path is used when a VLAN is added to a port netdevice if there already is an unoffloadable VXLAN device with that VLAN mapped. mlxsw_sp_bridge_8021d_port_join() is updated to obey the new interfaces changed by the abovementioned code, propagating extack ultimately from NETDEV_CHANGEUPPER events. Signed-off-by:
-
Petr Machata authored
Now that VLAN port object addition notifications carry an extack, propagate it from mlxsw_sp_switchdev_vxlan_vlans_add() through mlxsw_sp_switchdev_vxlan_vlan_add() to mlxsw_sp_bridge_8021q_vxlan_join(). This code path is used when a VLAN is added to a VXLAN netdevice that cannot be offloaded. Signed-off-by:
-
Petr Machata authored
Drivers use switchdev_handle_port_obj_add() to handle recursive descent through lower devices. Change this function prototype to take add_cb that itself takes an extack argument. Decode extack from switchdev_notifier_port_obj_info and pass it to add_cb. Update mlxsw and ocelot drivers which use this helper. Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Reviewed-by:
-
Petr Machata authored
In order to pass extack to the drivers that need it, add an extack field to struct switchdev_notifier_info, and an extack argument to the function call_switchdev_blocking_notifiers(). Also add a helper function switchdev_notifier_info_to_extack(). Signed-off-by:
-
