- 06 Apr, 2017 40 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 100GbE Intel Wired LAN Driver Updates 2017-04-05 This series contains updates to fm10k only. Phil Turnbull from Oracle fixes an issue where the argument provided to FM10K_REMOVED macro was not what was expecting. Jake modifies the driver to replace the bitwise operators and defines with a BITMAP and enumeration values to avoid race conditions. Also future proof the driver so that developers do not have to remember to re-size the bitmaps when adding new values. Fixed the wording of a code comment to avoid stating that we return a value for a void function. Ngai-Mint makes sure that when configuring the receive ring, we make sure the receive queue is disabled. Fixed an issue where interfaces were resetting because the transmit mailbox FIFO was becoming full since the host was not ready, so ensure the host is ready before queueing up mailbox messages. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
R. Parameswaran says: ==================== L2TP:Adjust intf MTU, add underlay L3, L2 hdrs. Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to unwanted IP fragmentation. When L2TP is used without a control plane (userspace daemon), we would prefer that the kernel does a better job of choosing a default pseudowire MTU, taking account of all tunnel header overheads, including IP header options, if any. This patch addresses this. Change-set is organized as a two part patch series, with one patch introducing a new kernel function to compute the IP overhead on a socket, and the other patch using this new kernel function to compute the default L2TP MTU for an Ethernet pseudowire. Existing code also seems to assume an Ethernet (non-jumbo) underlay. The change proposed here uses the PMTU mechanism and the dst entry in the L2TP tunnel socket to directly pull up the underlay MTU (as the baseline number on top of which the encapsulation headers are factored in). An default MTU value of 1500 bytes is assumed as a fallback only if this fails. Fixed the kbuild test robot error in the previous posting. ==================== Signed-off-by: -
R. Parameswaran authored
Existing L2TP kernel code does not derive the optimal MTU for Ethernet pseudowires and instead leaves this to a userspace L2TP daemon or operator. If an MTU is not specified, the existing kernel code chooses an MTU that does not take account of all tunnel header overheads, which can lead to unwanted IP fragmentation. When L2TP is used without a control plane (userspace daemon), we would prefer that the kernel does a better job of choosing a default pseudowire MTU, taking account of all tunnel header overheads, including IP header options, if any. This patch addresses this. Change-set here uses the new kernel function, kernel_sock_ip_overhead(), to factor the outer IP overhead on the L2TP tunnel socket (including IP Options, if any) when calculating the default MTU for an Ethernet pseudowire, along with consideration of the inner Ethernet header. Signed-off-by:
R. Parameswaran <rparames@brocade.com> Signed-off-by:
-
R. Parameswaran authored
A new function, kernel_sock_ip_overhead(), is provided to calculate the cumulative overhead imposed by the IP Header and IP options, if any, on a socket's payload. The new function returns an overhead of zero for sockets that do not belong to the IPv4 or IPv6 address families. This is used in the L2TP code path to compute the total outer IP overhead on the L2TP tunnel socket when calculating the default MTU for Ethernet pseudowires. Signed-off-by:
-
Kees Cook authored
While unlikely, this makes sure any format strings in the device name can't exposure information via the resulting workqueue name. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
While unlikely, this makes sure the workqueue name won't be processed as a format string. Signed-off-by:
-
Mintz, Yuval authored
When qedr is enabled, qed would try dividing the msi-x vectors between L2 and RoCE, starting with L2 and providing it with sufficient vectors for its queues. Problem is qed would also do that for storage partitions, and as those don't need queues it would lead qed to award those partitions with 0 msi-x vectors, causing them to believe theye're using INTa and preventing them from operating. Fixes: 51ff1725 ("qed: Add support for RoCE hw init") Signed-off-by:
Yuval Mintz <Yuval.Mintz@cavium.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: Mock-up driver couple fixes Thanks to Dan's static checker, a bunch of small issues were found in the code. ==================== Signed-off-by: -
Florian Fainelli authored
Dan's static checker reported the following: drivers/net/dsa/dsa_loop.c:223 dsa_loop_port_vlan_dump() error: uninitialized symbol 'err'. which could happen if we do hit the continue statement for each iteration of the loop. Initialize err to 0 here. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: 98cd1552 ("net: dsa: Mock-up driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Dan's static analyzer reported the following: drivers/net/dsa/dsa_loop.c:181 dsa_loop_port_vlan_del() error: XXX uninitialized symbol 'pvid'. we were missing the assignment of pvid to ps->vid, so add that. Reported-by:
-
Or Gerlitz authored
Commit c7e2b968 "sched: introduce vlan action" added both the UAPI values for the vlan actions (TCA_VLAN_ACT_) and these two in-kernel ones which are not used, remove them. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Reviewed-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Eric Dumazet authored
mlx4 is the only driver in the tree making a point to recompute shinfo->gso_segs. Lets remove superfluous code. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Tariq Toukan <tariqt@mellanox.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Reviewed-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Colin Ian King authored
There seems to be a missing break on the OOO_LB_TC case, pq_id is being assigned and then re-assigned on the fall through default case and that seems suspect. Detected by CoverityScan, CID#1424402 ("Missing break in switch") Fixes: b5a9ee7c ("qed: Revise QM cofiguration") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
-
Tobias Regnery authored
Commit 9008ae07 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") copied the calls to netif_set_real_num_{tx,rx}_queues from mlx5e_open_locked to mlx5e_activate_priv_channels and wraps them in an if condition to test for netdev->real_num_{tx,rx}_queues. But netdev->real_num_rx_queues is conditionally compiled in if CONFIG_SYSFS is set. Without CONFIG_SYSFS the build fails: drivers/net/ethernet/mellanox/mlx5/core/en_main.c: In function 'mlx5e_activate_priv_channels': drivers/net/ethernet/mellanox/mlx5/core/en_main.c:2515:12: error: 'struct net_device' has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'? Fix this by unconditionally call netif_set_real_num{tx,rx}_queues like before commit 9008ae07. Fixes: 9008ae07 ("net/mlx5e: Minimize mlx5e_{open/close}_locked") Signed-off-by:
Tobias Regnery <tobias.regnery@gmail.com> Acked-by:
-
Kees Cook authored
Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, and the initializer fixes were extracted from grsecurity. In this case, NULL initialize with { } instead of undesignated NULLs. Signed-off-by: -
David S. Miller authored
Benjamin Herrenschmidt says: ==================== ftgmac100: Rework batch 1 - Link & Interrupts This is version 2 of the first batch of updates to the ftgmac100 driver. Essentially: - A few misc cleanups - Fixing link speed & duplex handling (including dealing with an Aspeed requirement to double reset the controller when the speed changes) - And addition of a reset task workqueue which will be used for delaying the re-initialization of the controller - Fixing a number of issues with how interrupts and NAPI are dealt with. Subsequent batches will rework and improve the rx path, the tx path, and add a bunch of features and fixes. Version 2 addresses some review comments to patches 5 and 10 (see version history in the respective emails). ==================== Reviewed-by:
-
Benjamin Herrenschmidt authored
First, don't look at the interrupt status in the poll loop to decide what to poll. It's wrong. If we have run out of budget, we may still have RX packets to unqueue but no more RX interrupt pending. So instead move the code looking at the interrupt status into the interrupt handler where it belongs. That avoids a slow MMIO read in the NAPI fast path. We keep the abnormal interrupts enabled while NAPI is scheduled. While at it, actually do something useful in the "error" cases: On AHB bus error, trigger the new reset task, that's about all we can do. On RX packet fifo or descriptor overflows, we need to restart the MAC after having freed things up. So set a flag that NAPI will see and use to perform that restart after harvesting the RX ring. Finally, we shouldn't complete NAPI if there are still outgoing packets that will need harvesting. Waiting for more interrupts is less efficient than letting NAPI run a while longer while the queue drains. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
The interrupt is neither enabled nor registered when the interface isn't running (regardless of whether we use nc-si or not) so the test isn't useful. Signed-off-by:
-
Benjamin Herrenschmidt authored
The HW requires a full MAC reset when changing the speed. Additionally the Aspeed documentation spells out that the MAC needs to be reset twice with a 10us interval. We thus move the speed setting and top level reset code into a new ftgmac100_reset_and_config_mac() function which handles both. Move the ring pointers initialization there too in order to reflect the HW change. Also reduce the timeout for the MAC reset as it shouldn't take more than 300 clock cycles according to the doc. Signed-off-by:
-
Benjamin Herrenschmidt authored
Link speed changes require a full HW reset. This isn't done properly at the moment. It will involve delays and thus isn't suitable to do from the link poll callback. So let's create a reset_task that we can queue up when the link changes. It will be useful for various cases of error handling as well. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Benjamin Herrenschmidt authored
The link monitoring and error handling code will have to redo the ring inits and HW setup so move the code out of ftgmac100_open() into a dedicated function. This forces a bit of re-ordering of ftgmac100_open() but nothing dramatic. Signed-off-by:
-
Benjamin Herrenschmidt authored
The interrupt isn't shared, so this will keep it masked until we have the HW in a known sane state. Signed-off-by:
-
Benjamin Herrenschmidt authored
Rather than probe/remove Signed-off-by:
-
Benjamin Herrenschmidt authored
Currently, a single function is used to allocate the rings themselves, initialize them, populate the rx ring, and allocate the rx buffers. The same happens on free. This splits them into separate functions. This will be useful when properly implementing re-initialization on link changes and error handling when the rings will be repopulated but not freed. Signed-off-by:
-
Benjamin Herrenschmidt authored
Keep track of both the current speed and duplex settings instead of only speed and properly apply the duplex setting to the HW. This reworks the adjust_link() function to also avoid trying to reconfigure the HW when there is no link and to display the link state to the user. Signed-off-by:
-
Benjamin Herrenschmidt authored
It's not used in any meaningful way Signed-off-by:
-
Benjamin Herrenschmidt authored
Reorder the fields in struct ftgmac in slightly more logical groups. Will make more sense as I add/remove some. No code change. Signed-off-by:
-
Benjamin Herrenschmidt authored
The divisions they represent are not particularily meaningful and things are going to be moving around with upcoming changes making these comments more a burden than anything else. Signed-off-by:
-
Benjamin Herrenschmidt authored
There's a placeholder already for the irq, use it Signed-off-by:
-
Felix Manlunas authored
Detection of watchdog timeout of Octeon cores is flawed and susceptible to false alarms. Refactor by removing the detection code, and in its place, leverage existing code that monitors for an indication from the NIC firmware that an Octeon core crashed; expand the meaning of the indication to "an Octeon core crashed or its watchdog timer expired". Detection of watchdog timeout is now delegated to an exception handler in the NIC firmware; this is free of false alarms. Also if there's an Octeon core crash or watchdog timeout: (1) Disable VF Ethernet links. (2) Decrement the module refcount by an amount equal to the number of active VFs of the NIC whose Octeon core crashed or had a watchdog timeout. The refcount will continue to reflect the active VFs of other liquidio NIC(s) (if present) whose Octeon cores are faultless. Item (2) is needed to avoid the case of not being able to unload the driver because the module refcount is stuck at some non-zero number. There is code that, in normal cases, decrements the refcount upon receiving a message from the firmware that a VF driver was unloaded. But in exceptional cases like an Octeon core crash or watchdog timeout, arrival of that particular message from the firmware might be unreliable. That normal case code is changed to not touch the refcount in the exceptional case to avoid contention (over the refcount) with the liquidio_watchdog kernel thread who will carry out item (2). Signed-off-by:Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
Derek Chickles <derek.chickles@cavium.com> Signed-off-by:
-
Florian Fainelli authored
With GCC 6.3, we can get the following warning: drivers/net/usb/usbnet.c:85:19: warning: 'driver_name' defined but not used [-Wunused-const-variable=] static const char driver_name [] = "usbnet"; ^~~~~~~~~~~ Signed-off-by: -
Alexei Starovoitov authored
fix artifact of merge resolution Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Mostly simple cases of overlapping changes (adding code nearby, a function whose name changes, for example). Signed-off-by: -
Ngai-Mint Kwan authored
Interfaces will reset whenever the TX mailbox FIFO has become full. This occurs more frequently whenever the IES API application is not running to process and clear the messages in the FIFO. Thus, this could lead to situations where the interface would enter an infinite reset loop. That is: if the interface is trying to synchronize a huge number of unicast and multicast entries with the IES API application, the TX mailbox FIFO will become full and the interface resets. Once the interface exits reset, it'll try to synchronize the unicast and multicast entries again. Ergo, this creates an infinite loop. Other actions such as multiple mulitcast mode or up/down transitions will fill the TX mailbox FIFO and induce the interface to reset. To correct these situations, check if the interface's "host_ready" flag is enabled before enqueuing any messages to the TX mailbox FIFO. This check will be conducted by a function call. Lastly, this issue mainly affects the PF and, thus, the VF is exempt. Signed-off-by:
Ngai-Mint Kwan <ngai-mint.kwan@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Ngai-Mint Kwan authored
Write to RXQCTL register to disable the receive queue when configuring the RX ring. Signed-off-by:
-
Jacob Keller authored
Re-word the comment to avoid stating that we return a value for this void function. Additionally, there is no need to mention older kernels, since this is the upstream kernel. Signed-off-by:
-
Jacob Keller authored
If some code path executes fm10k_service_event_schedule(), it is guaranteed that we only queue the service task once, since we use __FM10K_SERVICE_SCHED flag. Unfortunately this has a side effect that if a service request occurs while we are currently running the watchdog, it is possible that we will fail to notice the request and ignore it until the next time the request occurs. This can cause problems with pf/vf mailbox communication and other service event tasks. To avoid this, introduce a FM10K_SERVICE_REQUEST bit. When we successfully schedule (and set the _SCHED bit) the service task, we will clear this bit. However, if we are unable to currently schedule the service event, we just set the new SERVICE_REQUEST bit. Finally, after the service event completes, we will re-schedule if the request bit has been set. This should ensure that we do not miss any service event schedules, since we will re-schedule it once the currently running task finishes. This means that for each request, we will always schedule the service task to run at least once in full after the request came in. This will avoid timing issues that can occur with the service event scheduling. We do pay a cost in re-running many tasks, but all the service event tasks use either flags to avoid duplicate work, or are tolerant of being run multiple times. Signed-off-by:
-
Jacob Keller authored
This ensures that future programmers do not have to remember to re-size the bitmaps due to adding new values. Although this is unlikely for this driver, it may happen and it's best to prevent it from ever being an issue. Signed-off-by:
-
Jacob Keller authored
Replace bitwise operators and #defines with a BITMAP and enumeration values. This is similar to how we handle the "state" values as well. This has two distinct advantages over the old method. First, we ensure correctness of operations which are currently problematic due to race conditions. Suppose that two kernel threads are running, such as the watchdog and an ethtool ioctl, and both modify flags. We'll say that the watchdog is CPU A, and the ethtool ioctl is CPU B. CPU A sets FLAG_1, which can be seen as CPU A read FLAGS CPU A write FLAGS | FLAG_1 CPU B sets FLAG_2, which can be seen as CPU B read FLAGS CPU A write FLAGS | FLAG_2 However, "|=" and "&=" operators are not actually atomic. So this could be ordered like the following: CPU A read FLAGS -> variable CPU B read FLAGS -> variable CPU A write FLAGS (variable | FLAG_1) CPU B write FLAGS (variable | FLAG_2) Notice how the 2nd write from CPU B could actually undo the write from CPU A because it isn't guaranteed that the |= operation is atomic. In practice the race windows for most flag writes is incredibly narrow so it is not easy to isolate issues. However, the more flags we have, the more likely they will cause problems. Additionally, if such a problem were to arise, it would be incredibly difficult to track down. Second, there is an additional advantage beyond code correctness. We can now automatically size the BITMAP if more flags were added, so that we do not need to remember that flags is u32 and thus if we added too many flags we would over-run the variable. This is not a likely occurrence for fm10k driver, but this patch can serve as an example for other drivers which have many more flags. This particular change does have a bit of trouble converting some of the idioms previously used with the #defines for flags. Specifically, when converting FM10K_FLAG_RSS_FIELD_IPV[46]_UDP flags. This whole operation was actually quite problematic, because we actually stored flags separately. This could more easily show the problem of the above re-ordering issue. This is really difficult to test whether atomics make a difference in practical scenarios, but you can ensure that basic functionality remains the same. This patch has a lot of code coverage, but most of it is relatively simple. While we are modifying these files, update their copyright year. Signed-off-by:
-
Phil Turnbull authored
FM10K_REMOVED expects a hardware address, not a 'struct fm10k_hw'. Fixes: 5cb8db4a ("fm10k: Add support for VF") Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Tested-by:
-
