- 13 Feb, 2018 40 commits
-
-
Jacob Keller authored
Similar to changes done to the PF driver in commit 6622f5cd ("i40e: make use of __dev_uc_sync and __dev_mc_sync"), replace our home-rolled method for updating the internal status of MAC filters with __dev_uc_sync and __dev_mc_sync. These new functions use internal state within the netdev struct in order to efficiently break the question of "which filters in this list need to be added or removed" into singular "add this filter" and "delete this filter" requests. This vastly improves our handling of .set_rx_mode especially with large number of MAC filters being added to the device, and even results in a simpler .set_rx_mode handler. Under some circumstances, such as when attached to a bridge, we may receive a request to delete our own permanent address. Prevent deletion of this address during i40evf_addr_unsync so that we don't accidentally stop receiving traffic. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Dave Ertman authored
The MAC, FW Version and NPAR check used to determine if shutting off the FW LLDP engine is supported is not using the usual feature check mechanism. This patch fixes the problem by moving the feature check to i40e_sw_init in order to set a flag in pf->hw_features that ethtool will use for priv_flags disable operation. Signed-off-by:
Dave Ertman <david.m.ertman@intel.com> Tested-by:
-
Alan Brady authored
Broadcast filters can now cause overflow promiscuous to trigger when adding "too many" VLANs to all the ports of a device and the driver needs a way to exit overflow promiscuous once triggered. Currently the driver looks to see if there are "too many" filters and/or we have any failed filters to determine when it is safe to exit overflow promiscuous. If we trigger overflow promiscuous with broadcast filters, any new filters added will be "auto-failed" until we exit overflow promiscuous. Since the user can't manually remove the failed broadcast filters for VLANs (nor should we expect the user to do such), there is no way to exit overflow promiscuous without reloading the driver. The easiest way to do this is to remove the shortcut to "auto-fail" filters in overflow promiscuous. If the user removes the VLANs, the failed filters will be removed and since we're no longer "auto-failing" new filters, we'll eventually get a good set of filters and exit overflow promiscuous. This has the side benefit of making filter state more explicit in that if a filter says it's failed we know for a fact it failed and not just assuming it will if we're in overflow promiscuous. This is nice because if the user removes some filters and then adds some, even if we're in overflow promiscuous, the filter might succeed; we were just assuming it won't because the user hasn't rectified other existing failed filters. Signed-off-by:
Alan Brady <alan.brady@intel.com> Tested-by:
-
Alan Brady authored
This code here is quite complex and easy to screw up. Let's see if we can't improve the readability and maintainability a bit. This refactors out promisc_changed into two variables 'old_overflow' and 'new_overflow' which makes it a bit clearer when we're concerned about when and how overflow promiscuous is changed. This also makes so that we no longer need to pass a boolean pointer to i40e_aqc_add_filters. Instead we can simply check if we changed the overflow promiscuous flag since the function start. Signed-off-by:
-
Harshitha Ramamurthy authored
When iterating through the linked list of VLAN filters, make the iterator the same type as that of the linked list. Signed-off-by:
Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by:
-
Alan Brady authored
When adding a bunch of VLANs to all the ports on a device, it's possible to run out of space for broadcast filters. The driver should trigger overflow promiscuous in this circumstance to prevent traffic from being unexpectedly dropped. Signed-off-by:
-
Mitch Williams authored
Could a Bad Person do Bad Things to a server if they found these addresses printed in the log? Who knows? But let's not take that risk. Remove pointers from a bunch of printks. In some cases, I was able to adjust the message to indicate whether or not the value was null. In others, I just removed the entire message as there was really no hope of saving it. Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Wei Yongjun authored
A spin lock is taken here so we should use GFP_ATOMIC. Fixes: 504398f0 ("i40evf: use spinlock to protect (mac|vlan)_filter_list") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/net/ethernet/intel/i40e/i40e_main.c:5440:5: warning: symbol 'i40e_get_link_speed' was not declared. Should it be static? Signed-off-by:
-
David Ahern authored
Do not export fib_multipath_hash or fib_select_path; both are only used by core ipv4 code. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David Ahern authored
If flow oif is set and it is not an l3mdev, then fib_select_path can jump to the source address check. Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: rename sctp diag file and add file comments for it This patchset is to remove the sctp_ prefix for sctp diag file, and also to add the missing file comments for it. v1->v2: split them into two patches as Marcelo suggested. ==================== Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
-
Xin Long authored
This patch is to add the missing file comments for sctp diag file. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
Remove 'sctp_' prefix for diag file, to keep consistent with other files' names. Signed-off-by:
-
Arkadi Sharshevsky authored
Use NL_SET_ERR_MSG_MOD helper which adds the module name instead of specifying the prefix each time. Signed-off-by:
Arkadi Sharshevsky <arkadis@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: SPAN cleanups In patch one of this short series, a misplaced pointer star is moved to the correct place. In the second patch, we observe that if SPAN entries carry their reference count anyway, it's redundant to also carry a "used" flag. In the third patch, SPAN support code is moved to a separate module. ==================== Signed-off-by: -
Petr Machata authored
For the upcoming work on SPAN, it makes sense to move the current code to a module of its own. It already has a well-defined API boundary to the mirror management (which is used from matchall and ACL code). A couple more functions need to be exported for the functions that spectrum.c needs to use for MTU handling and subsystem init/fini. Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Petr Machata authored
The member ref_count already determines whether a given SPAN entry is used, and is as easy to use as a dedicated boolean. Signed-off-by:
-
Petr Machata authored
Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: IPIP cleanups In the first patch, a forgotten #include is added. Even though the code compiles as-is, the include is necessary for modules that should include spectrum_ipip.h. The second patch corrects an assumption that IPv6 tunnels use struct ip_tunnel_parm to store tunnel parameters. ==================== Signed-off-by: -
Petr Machata authored
struct ip_tunnel_parm, where GRE and several other tunnel types hold information, is IPv4-specific. The current router / ipip code in mlxsw however uses it as if it were generic. Make it clear that it's not. Rename many functions from _params_ to _params4_. mlxsw_sp_ipip_parms_saddr() and _daddr() take a proto argument to dispatch on it. Move the dispatch logic to mlxsw_sp_ipip_netdev_saddr() and _daddr(), and replace with single-protocol functions. In struct mlxsw_sp_ipip_entry, move the "parms" field to a (for the time being, singleton) union. Update users throughout. Signed-off-by:
-
Petr Machata authored
struct ip_tunnel_parm, which is used in spectrum_ipip.h, is defined in if_tunnel.h. However, the former neglects to include the latter. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jake Moroni authored
The comment stated that a thread was started, but that is not the case. Signed-off-by:
Jake Moroni <mail@jakemoroni.com> Signed-off-by:
-
David S. Miller authored
Kirill Tkhai says: ==================== Replacing net_mutex with rw_semaphore this is the third version of the patchset introducing net_sem instead of net_mutex. The patchset adds net_sem in addition to net_mutex and allows pernet_operations to be "async". This flag means, the pernet_operations methods are safe to be executed with any other pernet_operations (un)initializing another net. If there are only async pernet_operations in the system, net_mutex is not used either for setup_net() or for cleanup_net(). The pernet_operations converted in this patchset allow to create minimal .config to have network working, and the changes improve the performance like you may see below: %for i in {1..10000}; do unshare -n bash -c exit; done *before* real 1m40,377s user 0m9,672s sys 0m19,928s *after* real 0m17,007s user 0m5,311s sys 0m11,779 (5.8 times faster) In the future, when all pernet_operations become async, we'll just remove this "async" field tree-wide. All the new logic is concentrated in patches [1-5/32]. The rest of patches converts specific operations: review, rationale of they can be converted, and setting of async flag. Kirill v3: Improved patches descriptions. Added comment into [5/32]. Added [32/32] converting netlink_tap_net_ops (new pernet operations introduced in 2018). v2: Single patch -> patchset with rationale of every conversion ==================== Signed-off-by: -
Kirill Tkhai authored
These pernet_operations init just allocated net memory, and they obviously can be executed in parallel in any others. v3: New Signed-off-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Acked-by:
Andrei Vagin <avagin@virtuozzo.com> Signed-off-by:
-
Kirill Tkhai authored
These pernet operations just create and destroy netlink socket. The socket is pernet and else operations don't touch it. Signed-off-by:
-
Kirill Tkhai authored
These pernet operations consist of exit() and exit_batch() methods. default_device_exit() moves not-local and virtual devices to init_net. There is nothing exciting, because this may happen in any time on a working system, and rtnl_lock() and synchronize_net() protect us from all cases of external dereference. The same for default_device_exit_batch(). Similar unregisteration may happen in any time on a system. Here several lists (like todo_list), which are accessed under rtnl_lock(). After rtnl_unlock() and netdev_run_todo() all the devices are flushed. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations have only init() method. It allocates memory for net_device, calls register_netdev() and assigns net::loopback_dev. register_netdev() is allowed be used without additional locks, as it's synchronized on rtnl_lock(). There are many examples of using this functon directly from ioctl(). The only difference, compared to ioctl(), is that net is not completely alive at this moment. But it looks like, there is no way for parallel pernet_operations to dereference the net_device, as the most of struct net_device lists, where it's linked, are related to net, and the net is not liked. The exceptions are net_device::unreg_list, close_list, todo_list, used for unregistration, and ::link_watch_list, where net_device may be linked to global lists. Unregistration of loopback_dev obviously can't happen, when loopback_net_init() is executing, as the net as alive. It occurs in default_device_ops, which currently requires net_mutex, and it behaves as a barrier at the moment. It will be considered in next patch. Speaking about link_watch_list, it seems, there is no way for loopback_dev at time of registration to be linked in lweventlist and be available for another pernet_operations. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations (un)register sysctl, which are not touched by anybody else. So, it's safe to make them async. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations create and destroy sysctl, which are not touched by anybody else. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations just create and destroy /proc entry, and another operations do not touch it. Also, nobody else are interested in foreign net::packet::sklist. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations are just create and destroy /proc and sysctl entries, and are not touched by foreign pernet_operations. So, we are able to make them async. Signed-off-by:
-
Kirill Tkhai authored
arp_net_ops just addr/removes /proc entry. devinet_ops allocates and frees duplicate of init_net tables and (un)registers sysctl entries. fib_net_ops allocates and frees pernet tables, creates/destroys netlink socket and (un)initializes /proc entries. Foreign pernet_operations do not touch them. ip_rt_proc_ops only modifies pernet /proc entries. xfrm_net_ops creates/destroys /proc entries, allocates/frees pernet statistics, hashes and tables, and (un)initializes sysctl files. These are not touched by foreigh pernet_operations xfrm4_net_ops allocates/frees private pernet memory, and configures sysctls. sysctl_route_ops creates/destroys sysctls. rt_genid_ops only initializes fields of just allocated net. ipv4_inetpeer_ops allocated/frees net private memory. igmp_net_ops just creates/destroys /proc files and socket, noone else interested in. tcp_sk_ops seems to be safe, because tcp_sk_init() does not depend on any other pernet_operations modifications. Iteration over hash table in inet_twsk_purge() is made under RCU lock, and it's safe to iterate the table this way. Removing from the table happen from inet_twsk_deschedule_put(), but this function is safe without any extern locks, as it's synchronized inside itself. There are many examples, it's used in different context. So, it's safe to leave tcp_sk_exit_batch() unlocked. tcp_net_metrics_ops is synchronized on tcp_metrics_lock and safe. udplite4_net_ops only creates/destroys pernet /proc file. icmp_sk_ops creates percpu sockets, not touched by foreign pernet_operations. ipmr_net_ops creates/destroys pernet fib tables, (un)registers fib rules and /proc files. This seem to be safe to execute in parallel with foreign pernet_operations. af_inet_ops just sets up default parameters of newly created net. ipv4_mib_ops creates and destroys pernet percpu statistics. raw_net_ops, tcp4_net_ops, udp4_net_ops, ping_v4_net_ops and ip_proc_ops only create/destroy pernet /proc files. ip4_frags_ops creates and destroys sysctl file. So, it's safe to make the pernet_operations async. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations register and destroy sysctl directory, and it's not interesting for foreign pernet_operations. Signed-off-by:
-
Kirill Tkhai authored
These pernet_operations initialize and purge net::wext_nlevents queue, and are not touched by foreign pernet_operations. Mark them async. Signed-off-by:
-
Kirill Tkhai authored
This pernet_operations create and destroy net::genl_sock. Foreign pernet_operations don't touch it. Signed-off-by:
-
Kirill Tkhai authored
psched_net_ops only creates and destroyes /proc entry, and safe to be executed in parallel with any foreigh pernet_operations. tcf_action_net_ops initializes and destructs tcf_action_net::egdev_ht, which is not touched by foreign pernet_operations. So, make them async. Signed-off-by:
-
Kirill Tkhai authored
Both of them create and initialize lists, which are not touched by another foreing pernet_operations. Signed-off-by:
-
Kirill Tkhai authored
There are: 1)dev_proc_ops and dev_mc_net_ops, which create and destroy pernet proc file and not interesting for another net namespaces; 2)netdev_net_ops, which creates pernet hashes, which are not touched by another pernet_operations. So, make them async. Signed-off-by:
-
Kirill Tkhai authored
This patch starts to convert pernet_subsys, registered from subsys initcalls. It seems safe to be executed in parallel with others, as it's only creates/destoyes proc entry, which nobody else is not interested in. Signed-off-by:
-
