- 10 Oct, 2017 40 commits
-
-
Eric Garver authored
This adds a ct_clear action for clearing conntrack state. ct_clear is currently implemented in OVS userspace, but is not backed by an action in the kernel datapath. This is useful for flows that may modify a packet tuple after a ct lookup has already occurred. Signed-off-by:
Eric Garver <e@erig.me> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
If CONFIG_DST_CACHE is not selected cpu variable will be unused and we will see a compilation warning. Move it under the ifdef. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: d66f2b91 ("bpf: don't rely on the verifier lock for metadata_dst allocation") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2017-10-10 This series contains updates to e1000e and igb. Benjamin Poirier provides several fixes for e1000e, starting with a correction to the return status which was always returning success even if it was not successful. Fixed code comments to reflect the actual code behavior. Fixed the conditional test for the correct return value. Fixed a potential race condition reported by Lennart Sorensen, where the single flag get_link_status is used to signal two different states. Sasha fixes a buffer overrun for i219 devices, where the chipset had reduced the round-trip latency for the LAN controller DMA accesses which in some high performance cases caused a buffer overrun while processing the DMA transactions. Willem de Bruijn changes the default behavior of e1000e to use the burst mode settings by default unless the user specifies the receive interrupt delay (RxIntDelay). Florian Fainelli updates the driver to differentiate between when e1000e_put_txbuf() is called from normal reclamation or when a DMA mapping failure to make the driver more "drop monitor friendly". Christophe JAILLET fixes a potential NULL pointer dereference by properly returning -ENOMEM on memory allocation failures. ==================== Signed-off-by: -
Florian Westphal authored
We can now piggyback error strings to userspace via extended acks rather than using printk. Before: bridge fdb add 01:02:03:04:05:06 dev br0 vlan 4095 RTNETLINK answers: Invalid argument After: bridge fdb add 01:02:03:04:05:06 dev br0 vlan 4095 Error: invalid vlan id. v3: drop 'RTM_' prefixes, suggested by David Ahern, they are not useful, the add/del in bridge command line is enough. Also reword error in response to malformed/bad vlan id attribute size. Cc: David Ahern <dsahern@gmail.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Florian Westphal authored
exercise RTM_GETNETCONF call path for unspec, inet and inet6 families, they are DOIT_UNLOCKED candidates. Signed-off-by:
-
David S. Miller authored
Tariq Toukan says: ==================== mlx4_en num of rings This patchset from Inbar contains changes to rings control to the mlx4 Eth driver. Patches 1 and 2 limit the number of rings to the number of CPUs. Patch 3 removes a limitation in logic of default number of RX rings. Series generated against net-next commit: 812b5ca7 Add a driver for Renesas uPD60620 and uPD60620A PHYs ==================== Signed-off-by:
-
Inbar Karmy authored
Remove limitation of netif_get_num_default_rss_queues() from logic of RX rings default number. Signed-off-by:
Inbar Karmy <inbark@mellanox.com> Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Inbar Karmy authored
Limit the number of RX rings by the number of cores in the system. Signed-off-by:
-
Inbar Karmy authored
Limit the number of TX rings per UP by the number of cores in the system. Signed-off-by:
-
David S. Miller authored
Lipeng says: ==================== Support set_ringparam and {set|get}_rxnfc ethtool commands 1, Patch [1/5,2/5] add support for ethtool ops set_ringparam (ethtool -G) and fix related bug. 2, Patch [3/5,4/5, 5/5] add support for ethtool ops set_rxnfc/get_rxnfc (-n/-N) and fix related bug. ==================== Signed-off-by: -
Lipeng authored
This patch fix the ring count for ETHTOOL_GRXRINGS. Ring count not TC size should be return for command "ethtool -n ethx". Signed-off-by:
Lipeng <lipeng321@huawei.com> Signed-off-by:
-
Lipeng authored
This patch add support for ethtool's ETHTOOL_GRXFH in hns3_get_rxnfc(). Signed-off-by:
-
Lipeng authored
This patch supports the ethtool's set_rxnfc(). Signed-off-by:
-
Lipeng authored
This patch supports the ethtool's set_ringparam(). Signed-off-by:
-
Lipeng authored
This patch fixes the ring index in hns3_fini_ring. Signed-off-by:
-
Ganesh Goudar authored
Add 0x50aa and 0x50ab T5 device id's. Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Ganesh Goudar authored
Add support for new flash parts identification, and also cleanup the flash Part identifying and decoding code. Based on the original work of Casey Leedom <leedom@chelsio.com> Signed-off-by:
-
Tim Hansen authored
Fix BUG() calls to use BUG_ON(conditional) macros. This was found using make coccicheck M=net/core on linux next tag next-2017092 Signed-off-by:
Tim Hansen <devtimhansen@gmail.com> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== bpf: get rid of global verifier state and reuse instruction printer This set started off as simple extraction of eBPF verifier's instruction printer into a separate file but evolved into removal of global state. The purpose of moving instruction printing code is to be able to reuse it from the bpftool. As far as the global verifier lock goes, this set removes the global variables relating to the log buffer, makes the one-time init done by bpf_get_skb_set_tunnel_proto() not depend on any external locking, and performs verifier log writeback as data is produced removing the need for allocating a potentially large temporary buffer. The final step of actually removing the verifier lock is left to someone more competent and self-confident :) Note that struct bpf_verifier_env is just 40B under two pages now, we should probably switch to vzalloc() when it's expanded again... v2: - add a selftest; - use env buffer and flush on every print (Alexei); - handle kernel log allocation failures (Daniel); - put the env log members into a struct (Daniel). ==================== Signed-off-by: -
Jakub Kicinski authored
Verifier log buffer can be quite large (up to 16MB currently). As Eric Dumazet points out if we allow multiple verification requests to proceed simultaneously, malicious user may use the verifier as a way of allocating large amounts of unswappable memory to OOM the host. Switch to a strategy of allocating a smaller buffer (1024B) and writing it out into the user buffer after every print. While at it remove the old BUG_ON(). This is in preparation of the global verifier lock removal. Signed-off-by:
Simon Horman <simon.horman@netronome.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Jakub Kicinski authored
bpf_skb_set_tunnel_*() functions require allocation of per-cpu metadata_dst. The allocation happens upon verification of the first program using those helpers. In preparation for removing the verifier lock, use cmpxchg() to make sure we only allocate the metadata_dsts once. Signed-off-by:
-
Jakub Kicinski authored
Compile the instruction printer from kernel/bpf and use it for disassembling "translated" eBPF code. Signed-off-by:
-
Jakub Kicinski authored
Separate the instruction printing into a standalone source file. This way sneaky code from tools/ can compile it in directly. Signed-off-by:
-
Jakub Kicinski authored
The biggest piece of global state protected by the verifier lock is the verifier_log. Move that log to struct bpf_verifier_env. struct bpf_verifier_env has to be passed now to all invocations of verbose(). Signed-off-by:
-
Jakub Kicinski authored
Put the loose log_* variables into a structure. This will make it simpler to remove the global verifier state in following patches. Signed-off-by:
-
Jakub Kicinski authored
Add a test for verifier log handling. Check bad attr combinations but focus on cases when log is truncated. Signed-off-by:
-
Colin Ian King authored
The use of the | operator always leads to true which looks rather suspect to me. Fix this by using & instead to just check the RTF_CACHE entry bit. Detected by CoverityScan, CID#1457734, #1457747 ("Wrong operator used") Fixes: 35732d01 ("ipv6: introduce a hash table to store dst cache") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
Wei Wang <weiwan@google.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Signed-off-by:
-
Colin Ian King authored
Currently rt6_ex is being dereferenced before it is null checked hence there is a possible null dereference bug. Fix this by only dereferencing rt6_ex after it has been null checked. Detected by CoverityScan, CID#1457749 ("Dereference before null check") Fixes: 81eb8447 ("ipv6: take care of rt6_stats") Signed-off-by:Eric Dumazet <edumazet@google.com> Acked-by:
-
Christophe JAILLET authored
Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Tested-by: Aaron Brown <aaron.f.brown@intel.com Acked-by:
PJ Waskiewicz <peter.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Florian Fainelli authored
e1000e_put_txbuf() can be called from normal reclamation path as well as when a DMA mapping failure, so we need to differentiate these two cases when freeing SKBs to be drop monitor friendly. e1000e_tx_hwtstamp_work() and e1000_remove() are processing TX timestamped SKBs and those should not be accounted as drops either. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
-
Willem de Bruijn authored
Devices that support FLAG2_DMA_BURST have different default values for RDTR and RADV. Apply burst mode default settings only when no explicit value was passed at module load. The RDTR default is zero. If the module is loaded for low latency operation with RxIntDelay=0, do not override this value with a burst default of 32. Move the decision to apply burst values earlier, where explicitly initialized module variables can be distinguished from defaults. Signed-off-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
-
Sasha Neftin authored
Intel
® 100/200 Series Chipset platforms reduced the round-trip latency for the LAN Controller DMA accesses, causing in some high performance cases a buffer overrun while the I219 LAN Connected Device is processing the DMA transactions. I219LM and I219V devices can fall into unrecovered Tx hang under very stressfully UDP traffic and multiple reconnection of Ethernet cable. This Tx hang of the LAN Controller is only recovered if the system is rebooted. Slightly slow down DMA access by reducing the number of outstanding requests. This workaround could have an impact on TCP traffic performance on the platform. Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance. Please, refer to I218/I219 specification update: https://www.intel.com/content/www/us/en/embedded/products/networking/ ethernet-connection-i218-family-documentation.html Signed-off-by:Sasha Neftin <sasha.neftin@intel.com> Reviewed-by:
Dima Ruinskiy <dima.ruinskiy@intel.com> Reviewed-by:
Raanan Avargil <raanan.avargil@intel.com> Tested-by:
-
Benjamin Poirier authored
When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status Change and 2) if the condition persists, the interrupt is repeatedly raised again in quick succession. Ideally we would configure the Other interrupt to not be raised in case of receiver overrun but this doesn't seem possible on this adapter. Instead, we handle the first part of the problem by reverting to the practice of reading ICR in the other interrupt handler, like before commit 16ecba59 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac ("e1000e: Fix msi-x interrupt automask") which cleared IAME from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts anymore. We handle the second part of the problem by not re-enabling the Other interrupt right away when there is overrun. Instead, we wait until traffic subsides, napi polling mode is exited and interrupts are re-enabled. Reported-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Fixes: 16ecba59 ("e1000e: Do not read ICR in Other interrupt") Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Tested-by:
-
Benjamin Poirier authored
Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by: -
Benjamin Poirier authored
All the helpers return -E1000_ERR_PHY. Signed-off-by:
-
Benjamin Poirier authored
Reading e1000e_check_for_copper_link() shows that get_link_status is set to false after link has been detected. Therefore, it stays TRUE until then. Signed-off-by:
-
Benjamin Poirier authored
In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously. Signed-off-by:
-
Bernd Edlinger authored
Signed-off-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Signed-off-by:
-
Willem de Bruijn authored
Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy-based transmission. Tested by sending two udp flows from guest to host, one with payload of VHOST_GOODCOPY_LEN, the other too small for zerocopy (1B). The large flow is redirected to a netem instance with 1MBps rate limit and deep 1000 entry queue. modprobe ifb ip link set dev ifb0 up tc qdisc add dev ifb0 root netem limit 1000 rate 1MBit tc qdisc add dev tap0 ingress tc filter add dev tap0 parent ffff: protocol ip \ u32 match ip dport 8000 0xffff \ action mirred egress redirect dev ifb0 Before the delay, both flows process around 80K pps. With the delay, before this patch, both process around 400. After this patch, the large flow is still rate limited, while the small reverts to its original rate. See also discussion in the first link, below. Without rate limiting, {1, 10, 100}x TCP_STREAM tests continued to send at 100% zerocopy. The limit in vhost_exceeds_maxpend must be carefully chosen. With vq->num >> 1, the flows remain correlated. This value happens to correspond to VHOST_MAX_PENDING for vq->num == 256. Allow smaller fractions and ensure correctness also for much smaller values of vq->num, by testing the min() of both explicitly. See also the discussion in the second link below. Changes v1 -> v2 - replaced min with typed min_t - avoid unnecessary whitespace change Link:http://lkml.kernel.org/r/CAF=yD-+Wk9sc9dXMUq1+x_hh=3ThTXa6BnZkygP3tgVpjbp93g@mail.gmail.com Link:http://lkml.kernel.org/r/20170819064129.27272-1-den@klaipeden.comSigned-off-by: -
William Tu authored
Add erspan netlink interface for OVS. Signed-off-by:
William Tu <u9012063@gmail.com> Cc: Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
