- 07 Dec, 2016 28 commits
-
-
Jacob Keller authored
The current flow for adding or updating the PVID for a VF uses i40e_vsi_add_vlan and i40e_vsi_kill_vlan which each take, then release the hash lock. In addition the two functions also must take special care that they do not perform VLAN mode changes as this will make the code in i40e_ndo_set_vf_port_vlan behave incorrectly. Fix these issues by using the new helper functions i40e_add_vlan_all_mac and i40e_rm_vlan_all_mac which expect the hash lock to already be taken. Additionally these functions do not perform any state updates in regards to VLAN mode, so they are safe to use in the PVID update flow. It should be noted that we don't need the VLAN mode update code here, because there are only a few flows here. (a) we're adding a new PVID In this case, if we already had VLAN filters the VSI is knocked offline so we don't need to worry about pre-existing VLAN filters (b) we're replacing an existing PVID In this case, we can't have any VLAN filters except those with the old PVID which we already take care of manually. (c) we're removing an existing PVID Similarly to above, we can't have any existing VLAN filters except those with the old PVID which we already take care of correctly. Because of this, we do not need (or even want) the special accounting done in i40e_vsi_add_vlan, so use of the helpers is a saner alternative. It also opens the door for a future patch which will refactor the flow of i40e_vsi_add_vlan now that it is not needed in this function. Change-ID: Ia841f63da94e12b106f41cf7d28ce8ce92f2ad99 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>
-
Jacob Keller authored
A future refactor of how the PF assigns a PVID to a VF will want to be able to add and remove a block of filters by VLAN without worrying about accidentally triggering the accounting for I40E_VLAN_ANY. Additionally the PVID assignment would like to be able to batch several changes under one use of the mac_filter_hash_lock. Factor out the addition and deletion of a VLAN on all MACs into their own function which i40e_vsi_(add|kill)_vlan can use. These new functions expect the caller to take the hash lock, as well as perform any necessary accounting for updating I40E_VLAN_ANY filters if we are now operating under VLAN mode. Change-ID: If79e5b60b770433275350a74b3f1880333a185d5 Signed-off-by:
-
Jacob Keller authored
Fix a subtle issue with the code for converting VID=-1 filters into VID=0 filters when adding a new VLAN. Previously the code deleted the VID=-1 filter, and then added a new VID=0 filter. In the rare case that the addition fails due to -ENOMEM, we end up completely deleting the filter which prevents recovery if memory pressure subsides. While it is not strictly an issue because it is likely that memory issues would result in many other problems, we shouldn't delete the filter until after the addition succeeds. Change-ID: Icba07ddd04ecc6a3b27c2e29f2c1c8673d266826 Signed-off-by:
-
Jacob Keller authored
The current caller of i40e_update_filter_state incorrectly passes aq_ret, an i40e_status variable, instead of the expected aq_err. This happens to work because i40e_status is actually just a typedef integer, and 0 is still the successful return. However i40e_update_filter_state has special handling for ENOSPC which is currently being ignored. Also notice that firmware does not update the per-filter response for many types of errors, such as EINVAL. Thus, modify the filter setup so that the firmware response memory is pre-set with I40E_AQC_MM_ERR_NO_RES. This enables us to refactor i40e_update_filter_state, removing the need to pass aq_err and avoiding a need for having 3 different flows for checking the filter state. The resulting code for i40e_update_filter_state is much simpler, only a single loop and we always check each filter response value every time. Since we pre-set the response value to match our expected error this correctly works for all success and error flows. Change-ID: Ie292c9511f34ee18c6ef40f955ad13e28b7aea7d Signed-off-by:
-
Jacob Keller authored
Previous code refactors have accidentally caused issues with the counting of active_filters. Avoid similar issues in the future by simply re-counting the active filters every time after we handle add and delete of all the filters. Additionally this allows us to simplify the check for when we exit promiscuous mode since we can combine the check for failed filters at the same time. Additionally since we recount filters at the end we need to set vsi->promisc_threshold as well. The resulting code takes a bit longer since we do have to loop over filters again. However, the result is more readable and less likely to become incorrect due to failed accounting of filters in the future. Finally, this ensures that it is not possible for vsi->active_filters to ever underflow since we never decrement it. Change-ID: Ib4f3a377e60eb1fa6c91ea86cc02238c08edd102 Signed-off-by:
-
Jacob Keller authored
A product decision has been made to defeature detection of PTP frames over L4 (UDP) on the XL710 MAC. Do not advertise support for L4 timestamping. Change-ID: I41fbb0f84ebb27c43e23098c08156f2625c6ee06 Signed-off-by:
-
Mitch Williams authored
The service task lock was being set in the scheduling function, not the actual service task. This would potentially leave the bit set for a long time before the task actually ran. Furthermore, if the service task takes too long, it calls the schedule function to reschedule itself - which would fail to take the lock and do nothing. Instead, set and clear the lock bit in the service task itself. In the process, get rid of the i40e_service_event_complete() function, which is really just two lines of code that can be put right in the service task itself. Change-ID: I83155e682b686121e2897f4429eb7d3f7c669168 Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Michal Kosiarz authored
Depending on external PHY type, register access method should be different. Clause22 or Clause45 can be chosen for different PHYs. Implemented functions apply correct access method for used device. Change-ID: If39d5f0da9c0b905a8cbdc1ab89885535e7d0426 Signed-off-by:
Michal Kosiarz <michal.kosiarz@intel.com> Tested-by:
-
Carolyn Wyborny authored
This patch adds adminq support for Forward Error Correction ("FEC")for 25g products. Change-ID: Iaff4910737c239d2c730e5c22a313ce9c37d3964 Signed-off-by:Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by:
Jacek Naczyk <jacek.naczyk@intel.com> Tested-by:
-
Carolyn Wyborny authored
Add support for 25G devices - defines and data structures. One tricky part here is that the firmware support for these Devices introduces a mismatch between the PHY type enum and the bitfields for the phy types. This change creates a macro and uses it to increment the 25G PHY values when creating 25G bitfields. Change-ID: I69b24d837d44cf9220bf5cb8dd46c5be89ce490b Signed-off-by:
-
Jacob Keller authored
Replace the %d specifier used for printing vsi->active_filters and vsi->promisc_threshold with an unsigned %u format specifier. While it is unlikely in practice that these values will ever reach such a large number they are unsigned values and thus should not be interpreted as negative numbers. Change-ID: Iff050fad5a1c8537c4c57fcd527441cd95cfc0d4 Signed-off-by:
-
Bimmy Pujari authored
Signed-off-by:
Bimmy Pujari <bimmy.pujari@intel.com> Tested-by:
-
Henry Tieman authored
Before this patch "ethtool -p" was not blinking the LEDs on boards with 1G BaseT PHYs. This commit identifies 1G BaseT boards as having the LEDs connected to the MAC. Also, renamed the flag to be more descriptive of usage. The flag is now I40E_FLAG_PHY_CONTROLS_LEDS. Change-ID: I4eb741da9780da7849ddf2dc4c0cb27ffa42a801 Signed-off-by:
Henry Tieman <henry.w.tieman@intel.com> Signed-off-by:
Harshitha Ramamurthy <harshitha.ramamurthy@intel.com> Tested-by:
-
Jacob Keller authored
The netdev->dev_addr MAC filter already exists in the MAC/VLAN hash table, as it is added when we configure the netdev in i40e_configure_netdev. Because we already know that this address will be updated in the hash_for_each loops, we do not need to handle it specially. This removes duplicate code and simplifies the i40e_vsi_add_vlan and i40e_vsi_kill_vlan functions. Because we know these filters must be part of the MAC/VLAN hash table, this should not have any functional impact on what filters are included and is merely a code simplification. Change-ID: I5e648302dbdd7cc29efc6d203b7019c11f0b5705 Signed-off-by:
-
Alexander Duyck authored
Currently the function i40e_napi-poll() returns 0 when it clean completely the Rx rings, but this foul budget accounting in core code. Fix this by returning the actual work done, capped to budget - 1, since the core doesn't allow to return the full budget when the driver modifies the NAPI status This is based on a similar change that was made for the ixgbe driver by Paolo Abeni. Change-ID: Ic3d93ad2fa2fc8ce3164bc461e69367da0f9173b Signed-off-by:
Alexander Duyck <alexander.h.duyck@intel.com> Tested-by:
-
Jacob Keller authored
A previous commit 53cb6e9e ("i40e: Removal of workaround for simple MAC address filter deletion") removed a workaround for some firmware versions which was reported to not be necessary in production NICs. Unfortunately this workaround is necessary in some configurations, specifically the Ethernet Controller XL710 for 40GbE QSFP+ (8086:1583). Without this patch, the mentioned NICs with current firmware exhibit issues when adding VLANs, as outlined by the following reproduction: $modprobe i40e $ip link set <device> up $ip link add link <device> vlan100 type vlan id 100 $dmesg | tail <snip> kernel: i40e 0000:82:00.0: Error I40E_AQ_RC_EINVAL adding RX filters on PF, promiscuous mode forced on This results in filters being marked as FAILED and setting the device in promiscuous mode. The root cause of receiving the -EINVAL error response appears to be due to a conflict with the default MAC filter which still exists on the default firmware for this device. Attempting to add a new VLAN filter on the default MAC address conflicts with the IGNORE_VLAN setting on the default rule. Change-ID: I4d8f6d48ac5f60cfe981b3baad30eb4d7c170d61 Signed-off-by:
-
Mitch Williams authored
The i40e_txd_use_count function was fast but confusing. In the comments, it even admits that it's ugly. So replace it with a new function that is (very) slightly faster and has extensive commenting to help the thicker among us (including the author, who will forget in a week) understand how it works. Change-ID: Ifb533f13786a0bf39cb29f77969a5be2c83d9a87 Signed-off-by:
-
Filip Sadowski authored
This patch makes the driver log link speed change. Before applying the patch link messages were printed only on state change. Now message is printed when link is brought up or down and when speed changes. Change-ID: Ifbee14b4b16c24967450b3cecac6e8351dcc8f74 Signed-off-by:
Filip Sadowski <filip.sadowski@intel.com> Tested-by:
-
Andrey Konovalov authored
This patch changes tun.c to call netif_receive_skb instead of netif_rx when a packet is received (if CONFIG_4KSTACKS is not enabled to avoid stack exhaustion). The difference between the two is that netif_rx queues the packet into the backlog, and netif_receive_skb proccesses the packet in the current context. This patch is required for syzkaller [1] to collect coverage from packet receive paths, when a packet being received through tun (syzkaller collects coverage per process in the process context). As mentioned by Eric this change also speeds up tun/tap. As measured by Peter it speeds up his closed-loop single-stream tap/OVS benchmark by about 23%, from 700k packets/second to 867k packets/second. A similar patch was introduced back in 2010 [2, 3], but the author found out that the patch doesn't help with the task he had in mind (for cgroups to shape network traffic based on the original process) and decided not to go further with it. The main concern back then was about possible stack exhaustion with 4K stacks. [1] https://github.com/google/syzkaller [2] https://www.spinics.net/lists/netdev/thrd440.html#130570 [3] https://www.spinics.net/lists/netdev/msg130570.htmlSigned-off-by:
Andrey Konovalov <andreyknvl@google.com> Acked-by:
Jason Wang <jasowang@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Joe Perches says: ==================== irda: w83977af_ir: Neatening Originally on top of Arnd's overly long udelay patches because I noticed a misindented block. That's now already fixed along with some other whitespace problems. These patches are the remainder style issues from my original series. Even though I haven't turned on the netwinder in a box in the garage in who knows how long, if this device is still used somewhere, might as well neaten the code too. ==================== Signed-off-by: -
Joe Perches authored
Use more common logging style, standardize function output logging use. Miscellanea: o Add and use pr_fmt o Convert printks to pr_<level> Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Neaten function declaration and definition arguments. Signed-off-by:
-
Joe Perches authored
Add braces where appropriate and remove an unnecessary else. Signed-off-by:
-
Joe Perches authored
Convert pointer comparisons to NULL. Signed-off-by:
-
Joe Perches authored
Use a more typical vertical spacing style. Signed-off-by:
-
Joe Perches authored
Add spaces around operators. git diff -w shows no differences. Signed-off-by:
-
Joe Perches authored
Remove leading and trailing whitespace. git diff -w shows no differences. Signed-off-by:
-
-
- 06 Dec, 2016 12 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
Pull sparc fix from David Miller: "A use-before-NULL-check from Dan Carpenter" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: dbri: move dereference after check for NULL
-
Dan Carpenter authored
We accidentally introduced a dereference before the NULL check in xmit_descs() as part of silencing a GCC warning. Fixes: 16f46050 ("dbri: Fix compiler warning") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) When dcbnl_cee_fill() fails to be able to push a new netlink attribute, it return 0 instead of an error code. From Pan Bian. 2) Two suffix handling fixes to FIB trie code, from Alexander Duyck. 3) bnxt_hwrm_stat_ctx_alloc() goes through all the trouble of setting and maintaining a return code 'rc' but fails to actually return it. Also from Pan Bian. 4) ping socket ICMP handler needs to validate ICMP header length, from Kees Cook. 5) caif_sktinit_module() has this interesting logic: int err = sock_register(...); if (!err) return err; return 0; Just return sock_register()'s return value directly which is the only possible correct thing to do. 6) Two bnx2x driver fixes from Yuval Mintz, return a reasonable estimate from get_ringparam() ethtool op when interface is down and avoid trying to use UDP port based tunneling on 577xx chips. 7) Fix ep93xx_eth crash on module unload from Florian Fainelli. 8) Missing uapi exports, from Stephen Hemminger. 9) Don't schedule work from sk_destruct(), because the socket will be freed upon return from that function. From Herbert Xu. 10) Buggy drivers, of which we know there is at least one, can send a huge packet into the TCP stack but forget to set the gso_size in the SKB, which causes all kinds of problems. Correct this when it happens, and emit a one-time warning with the device name included so that it can be diagnosed more easily. From Marcelo Ricardo Leitner. 11) virtio-net does DMA off the stack causes hiccups with VMAP_STACK, fix from Andy Lutomirski. 12) Fix fec driver compilation with CONFIG_M5272, from Nikita Yushchenko. 13) mlx5 fixes from Kamal Heib, Saeed Mahameed, and Mohamad Haj Yahia. (erroneously flushing queues on error, module parameter validation, etc) * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (34 commits) net/mlx5e: Change the SQ/RQ operational state to positive logic net/mlx5e: Don't flush SQ on error net/mlx5e: Don't notify HW when filling the edge of ICO SQ net/mlx5: Fix query ISSI flow net/mlx5: Remove duplicate pci dev name print net/mlx5: Verify module parameters net: fec: fix compile with CONFIG_M5272 be2net: Add DEVSEC privilege to SET_HSW_CONFIG command. virtio-net: Fix DMA-from-the-stack in virtnet_set_mac_address() tcp: warn on bogus MSS and try to amend it uapi glibc compat: fix outer guard of net device flags enum net: stmmac: clear reset value of snps, wr_osr_lmt/snps, rd_osr_lmt before writing netlink: Do not schedule work from sk_destruct uapi: export nf_log.h uapi: export tc_skbmod.h net: ep93xx_eth: Do not crash unloading module bnx2x: Prevent tunnel config for 577xx bnx2x: Correct ringparam estimate when DOWN isdn: hisax: set error code on failure net: bnx2x: fix improper return value ... -
Linus Torvalds authored
The shmem hole punching with fallocate(FALLOC_FL_PUNCH_HOLE) does not want to race with generating new pages by faulting them in. However, the wait-queue used to delay the page faulting has a serious problem: the wait queue head (in shmem_fallocate()) is allocated on the stack, and the code expects that "wake_up_all()" will make sure that all the queue entries are gone before the stack frame is de-allocated. And that is not at all necessarily the case. Yes, a normal wake-up sequence will remove the wait-queue entry that caused the wakeup (see "autoremove_wake_function()"), but the key wording there is "that caused the wakeup". When there are multiple possible wakeup sources, the wait queue entry may well stay around. And _particularly_ in a page fault path, we may be faulting in new pages from user space while we also have other things going on, and there may well be other pending wakeups. So despite the "wake_up_all()", it's not at all guaranteed that all list entries are removed from the wait queue head on the stack. Fix this by introducing a new wakeup function that removes the list entry unconditionally, even if the target process had already woken up for other reasons. Use that "synchronous" function to set up the waiters in shmem_fault(). This problem has never been seen in the wild afaik, but Dave Jones has reported it on and off while running trinity. We thought we fixed the stack corruption with the blk-mq rq_list locking fix (commit 7fe31130: "blk-mq: update hardware and software queues for sleeping alloc"), but it turns out there was _another_ stack corruptor hiding in the trinity runs. Vegard Nossum (also running trinity) was able to trigger this one fairly consistently, and made us look once again at the shmem code due to the faults often being in that area. Reported-and-tested-by: Vegard Nossum <vegard.nossum@oracle.com>. Reported-by:
Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
David S. Miller authored
Saeed Mahameed says: ==================== Mellanox 100G mlx5 fixes 2016-12-04 Some bug fixes for mlx5 core and mlx5e driver. v1->v2: - replace "uint" with "unsigned int" ==================== Signed-off-by: -
Mohamad Haj Yahia authored
When using the negative logic (i.e. FLUSH state), after the RQ/SQ reopen we will have a time interval that the RQ/SQ is not really ready and the state indicates that its not in FLUSH state because the initial SQ/RQ struct memory starts as zeros. Now we changed the state to indicate if the SQ/RQ is opened and we will set the READY state after finishing preparing all the SQ/RQ resources. Fixes: 6e8dd6d6 ("net/mlx5e: Don't wait for SQ completions on close") Fixes: f2fde18c ("net/mlx5e: Don't wait for RQ completions on close") Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
We are doing SQ descriptors cleanup in driver. Fixes: 6e8dd6d6 ("net/mlx5e: Don't wait for SQ completions on close") Signed-off-by:
-
Saeed Mahameed authored
We are going to do this a couple of steps ahead anyway. Fixes: d3c9bc27 ("net/mlx5e: Added ICO SQs") Signed-off-by:
-
Kamal Heib authored
In old FWs query ISSI command is not supported and for some of those FWs it might fail with status other than "MLX5_CMD_STAT_BAD_OP_ERR". In such case instead of failing the driver load, we will treat any FW status other than 0 for Query ISSI FW command as ISSI not supported and assume ISSI=0 (most basic driver/FW interface). In case of driver syndrom (query ISSI failure by driver) we will fail driver load. Fixes: f62b8bb8 ('net/mlx5: Extend mlx5_core to support ConnectX-4 Ethernet functionality') Signed-off-by:
Kamal Heib <kamalh@mellanox.com> Signed-off-by:
-
Kamal Heib authored
Remove duplicate pci dev name printing from mlx5_core_warn/dbg. Fixes: 5a788398 ('net/mlx5_core: Improve mlx5 messages') Signed-off-by:
-
Kamal Heib authored
Verify the mlx5_core module parameters by making sure that they are in the expected range and if they aren't restore them to their default values. Fixes: 9603b61d ('mlx5: Move pci device handling from mlx5_ib to mlx5_core') Signed-off-by:
-
Salil authored
This patch introduces the RX checksum function to check the status of the hardware calculated checksum and its error and appropriately convey status to the upper stack in skb->ip_summed field. In hardware, we only support checksum for the following protocols: 1) IPv4, 2) TCP(over IPv4 or IPv6), 3) UDP(over IPv4 or IPv6), 4) SCTP(over IPv4 or IPv6) but we support many L3(IPv4, IPv6, MPLS, PPPoE etc) and L4(TCP, UDP, GRE, SCTP, IGMP, ICMP etc.) protocols. Hardware limitation: Our present hardware RX Descriptor lacks L3/L4 checksum "Status & Error" bit (which usually can be used to indicate whether checksum was calculated by the hardware and if there was any error encountered during checksum calculation). Software workaround: We do get info within the RX descriptor about the kind of L3/L4 protocol coming in the packet and the error status. These errors might not just be checksum errors but could be related to version, length of IPv4, UDP, TCP etc. Because there is no-way of knowing if it is a L3/L4 error due to bad checksum or any other L3/L4 error, we will not (cannot) convey hardware checksum status(CHECKSUM_UNNECESSARY) for such cases to upper stack and will not maintain the RX L3/L4 checksum counters as well. Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
