- 23 Aug, 2019 5 commits
-
-
Xin Long authored
We need a similar fix for ipv6 as Commit 0761680d ("net: ipv4: fix listify ip_rcv_finish in case of forwarding") does for ipv4. This issue can be reprocuded by syzbot since Commit 323ebb61 ("net: use listified RX for handling GRO_NORMAL skbs") on net-next. The call trace was: kernel BUG at include/linux/skbuff.h:2225! RIP: 0010:__skb_pull include/linux/skbuff.h:2225 [inline] RIP: 0010:skb_pull+0xea/0x110 net/core/skbuff.c:1902 Call Trace: sctp_inq_pop+0x2f1/0xd80 net/sctp/inqueue.c:202 sctp_endpoint_bh_rcv+0x184/0x8d0 net/sctp/endpointola.c:385 sctp_inq_push+0x1e4/0x280 net/sctp/inqueue.c:80 sctp_rcv+0x2807/0x3590 net/sctp/input.c:256 sctp6_rcv+0x17/0x30 net/sctp/ipv6.c:1049 ip6_protocol_deliver_rcu+0x2fe/0x1660 net/ipv6/ip6_input.c:397 ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:438 NF_HOOK include/linux/netfilter.h:305 [inline] NF_HOOK include/linux/netfilter.h:299 [inline] ip6_input+0xe4/0x3f0 net/ipv6/ip6_input.c:447 dst_input include/net/dst.h:442 [inline] ip6_sublist_rcv_finish+0x98/0x1e0 net/ipv6/ip6_input.c:84 ip6_list_rcv_finish net/ipv6/ip6_input.c:118 [inline] ip6_sublist_rcv+0x80c/0xcf0 net/ipv6/ip6_input.c:282 ipv6_list_rcv+0x373/0x4b0 net/ipv6/ip6_input.c:316 __netif_receive_skb_list_ptype net/core/dev.c:5049 [inline] __netif_receive_skb_list_core+0x5fc/0x9d0 net/core/dev.c:5097 __netif_receive_skb_list net/core/dev.c:5149 [inline] netif_receive_skb_list_internal+0x7eb/0xe60 net/core/dev.c:5244 gro_normal_list.part.0+0x1e/0xb0 net/core/dev.c:5757 gro_normal_list net/core/dev.c:5755 [inline] gro_normal_one net/core/dev.c:5769 [inline] napi_frags_finish net/core/dev.c:5782 [inline] napi_gro_frags+0xa6a/0xea0 net/core/dev.c:5855 tun_get_user+0x2e98/0x3fa0 drivers/net/tun.c:1974 tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2020 Fixes: d8269e2c ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()") Fixes: 323ebb61 ("net: use listified RX for handling GRO_NORMAL skbs") Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Hayes Wang says: ==================== r8152: save EEE v4: For patch #2, remove redundant calling of "ocp_reg_write(tp, OCP_EEE_ADV, 0)". v3: For patch #2, fix the mistake caused by copying and pasting. v2: Adjust patch #1. The EEE has been disabled in the beginning of r8153_hw_phy_cfg() and r8153b_hw_phy_cfg(), so only check if it is necessary to enable EEE. Add the patch #2 for the helper function. v1: Saving the settings of EEE to avoid they become the default settings after reset_resume(). ==================== Signed-off-by: -
Hayes Wang authored
Add a helper function "rtl_eee_enable" for setting EEE. Besides, I move r8153_eee_en() and r8153b_eee_en(). And, I remove r8152b_enable_eee(), r8153_set_eee(), and r8153b_set_eee(). Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Signed-off-by:
-
Hayes Wang authored
Saving the settings of EEE to avoid they become the default settings after reset_resume(). Signed-off-by:
-
Ben Wei authored
Update response packet length for the following commands per NC-SI spec - Get Controller Packet Statistics - Get NC-SI Statistics - Get NC-SI Pass-through Statistics command Signed-off-by:
Ben Wei <benwei@fb.com> Reviewed-by:
Justin Lee <justin.lee1@dell.com> Signed-off-by:
-
- 22 Aug, 2019 32 commits
-
-
Markus Elfring authored
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Signed-off-by:
-
Markus Elfring authored
The dev_kfree_skb() function performs also input parameter validation. Thus the test around the shown calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Marco Hartmann authored
IEEE 802.3ae clause 45 defines a modified MDIO protocol that uses a two staged access model in order to increase the address space. This patch adds support for C45 MDIO read and write accesses, which are used whenever the MII_ADDR_C45 flag in the regnum argument is set. In case it is not set, C22 accesses are used as before. Signed-off-by:
Marco Hartmann <marco.hartmann@nxp.com> Acked-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
David S. Miller authored
Neil Armstrong says: ==================== dt-bindings: net: meson-dwmac: convert to yaml This patchsets converts the Amlogic Meson DWMAC glue bindings over to YAML schemas using the already converted dwmac bindings. The first patch is needed because the Amlogic glue needs a supplementary reg cell to access the DWMAC glue registers. Changes since v3: - Specified net-next target tree Changes since v2: - Added review tags - Updated allwinner,sun7i-a20-gmac.yaml reg maxItems ==================== Signed-off-by: -
Neil Armstrong authored
Now that we have the DT validation in place, let's convert the device tree bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas. Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Neil Armstrong authored
The Amlogic Meson DWMAC glue bindings needs a second reg cells for the glue registers, thus update the reg minItems/maxItems to allow more than a single reg cell. Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify maxItems to 1. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Reviewed-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2019-08-22 This series contains updates to i40e driver only. Arnd Bergmann reduces the stack usage which was causing warnings on 32-bit architectures due to large structure sizes for 2 functions getting inlined, so use noinline_for_stack to prevent the compilers from combining the 2 functions. Mauro S. M. Rodrigues fixes an issue when reading an EEPROM from SFP modules that comply with SFF-8472 but do not implement the Digital Diagnostic Monitoring (DDM) interface for i40e. Huhai found we were not checking the return value for configuring the transmit ring and continuing with XDP configuration of the transmit ring. Beilei fixes an issue of shifting signed 32-bit integers. Sylwia adds support for "packet drop mode" to the MAC configuration for admin queue command. This bit controls the behavior when a no-drop packet is blocking a TC queue. Adds support for persistent LLDP by checking the LLDP flag and reading the LLDP from the NVM when enabled. Adrian fixes the "recovery mode" check to take into account which device we are on, since x710 devices have 4 register values to check for status and x722 devices only have 2 register values to check. Piotr Azarewicz bumps the supported firmware API version to 1.9 which extends the PHY access admin queue command support. Jake makes sure the traffic class stats for a VEB are reset when the VEB stats are reset. Slawomir fixes a NULL pointer dereference where the VSI pointer was not updated before passing it to the i40e_set_vf_mac() when the VF is in a reset state, so wait for the reset to complete. Grzegorz removes the i40e_update_dcb_config() which was not using the correct NVM reads, so call i40e_init_dcb() in its place to correctly update the DCB configuration. Piotr Kwapulinski expands the scope of i40e_set_mac_type() since this is needed during probe to determine if we are in recovery mode. Fixed the driver reset path when in recovery mode. Marcin fixed an issue where we were breaking out of a loop too early when trying to get the PHY capabilities. v2: Combined patch 7 & 9 in the original series, since both patches bumped firmware API version. Also combined patches 12 & 13 in the original series, since one increased the scope of checking for MAC and the follow-on patch made use of function within the new scope. ==================== Signed-off-by: -
Marcin Formela authored
Fixed a bug where driver was breaking out of the loop and reporting an error without retrying first. Signed-off-by:
Marcin Formela <marcin.formela@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sylwia Wnuczko authored
This patch adds a function to read NVM module data and uses it to read current LLDP agent configuration from NVM API version 1.8. Signed-off-by:
Sylwia Wnuczko <sylwia.wnuczko@intel.com> Tested-by:
-
Piotr Kwapulinski authored
Driver waits after issuing a reset. When a reset takes too long a driver gives up. Implemented by invoking PF reset in a loop. After defined number of unsuccessful PF reset trials it returns error. Without this patch PF reset fails when NIC is in recovery mode. So make i40e_set_mac_type() public. i40e driver requires i40e_set_mac_type() to be public. It is required for recovery mode handling. Without this patch recovery mode could not be detected in i40e_probe(). Signed-off-by:
Piotr Kwapulinski <piotr.kwapulinski@intel.com> Tested-by:
-
Grzegorz Siwik authored
This patch removes function i40e_update_dcb_config(). Instead of i40e_update_dcb_config() we use i40e_init_dcb(), which implements the correct NVM read. Signed-off-by:
Grzegorz Siwik <grzegorz.siwik@intel.com> Tested-by:
-
Slawomir Laba authored
Add update to the VSI pointer passed to the i40e_set_vf_mac function. If VF is in reset state the driver waits in i40e_set_vf_mac function for the reset to be complete, yet after reset the vsi pointer that was passed into this function is no longer valid. The patch updates local VSI pointer directly from pf->vsi array, by using the id stored in VF pointer (lan_vsi_idx). Without this commit the driver might occasionally invoke general protection fault in kernel and disable the OS entirely. Signed-off-by:
Slawomir Laba <slawomirx.laba@intel.com> Tested-by:
-
Jacob Keller authored
The stats structure for the VEB switch statistics is reset periodically, but the tc_stats are not reset at the same time. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
-
Piotr Azarewicz authored
Upcoming FW increment API version to 1.9 due to Extend PHY access AQ command support. SW is ready for that support as well. Signed-off-by:
Piotr Azarewicz <piotr.azarewicz@intel.com> Tested-by:
-
Adrian Podlawski authored
Function check_recovery_mode had wrong if statement. Now we check proper FWS1B register values, which are responsible for the recovery mode. Recovery mode has 4 values for x710 and 2 for x722. That's why we need 6 different flags which are defined in the code. Now in the if statement, we recognize type of mac address and register value. Without those changes driver could show wrong state. Signed-off-by:
Adrian Podlawski <adrian.podlawski@intel.com> Tested-by:
-
Sylwia Wnuczko authored
This patch adds "drop mode" parameter to set mac config AQ command. This bit controls the behavior when a no-drop packet is blocking a TC queue. 0 – The PF driver is notified. 1 – The blocking packet is dropped and then the PF driver is notified. Signed-off-by:
-
Beilei Xing authored
This patch fixes following error reported by cppcheck: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour Signed-off-by:
Beilei Xing <beilei.xing@intel.com> Signed-off-by:
Ferruh Yigit <ferruh.yigit@intel.com> Tested-by:
-
huhai authored
When i40e_configure_tx_ring(vsi->tx_rings[i]) returns an error, we should exit from i40e_vsi_configure_tx and return the error, instead of continuing to check whether xdp is enable, and configure the xdp transmit ring. Signed-off-by:
huhai <huhai@kylinos.cn> Tested-by:
-
Mauro S. M. Rodrigues authored
Similar to the ixgbe issue fixed in: 655c9141 ("ixgbe: Check DDM existence in transceiver before access) i40e has the same issue when reading eeprom from SFP's module that comply with SFF-8472 but not implement the Digital Diagnostic Monitoring (DDM) interface described in it. The existence of such area is specified by bit 6 of byte 92, set to 1 if implemented. Without this patch, due to not checking this bit i40e fails to read SFP module's eeprom with the follow message: ethtool -m enP51p1s0f0 Cannot get Module EEPROM data: Input/output error Because it fails to read the additional 256 bytes in which it was assumed to exist the DDM data. Signed-off-by:
"Mauro S. M. Rodrigues" <maurosr@linux.vnet.ibm.com> Tested-by:
-
Arnd Bergmann authored
The functions i40e_aq_get_phy_abilities_resp() and i40e_set_fc() both have giant structure on the stack, which makes each one use stack frames larger than 500 bytes. As clang decides one function into the other, we get a warning for exceeding the frame size limit on 32-bit architectures: drivers/net/ethernet/intel/i40e/i40e_common.c:1654:23: error: stack frame size of 1116 bytes in function 'i40e_set_fc' [-Werror,-Wframe-larger-than=] When building with gcc, the inlining does not happen, but i40e_set_fc() calls i40e_aq_get_phy_abilities_resp() anyway, so they add up on the kernel stack just as much. The parts that actually use large stacks don't overlap, so make sure each one is a separate function, and mark them as noinline_for_stack to prevent the compilers from combining them again. Fixes: 0a862b43 ("i40e/i40evf: Add module_types and update_link_info") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
-
Colin Ian King authored
Variable err is initialized to a value that is never read and it is re-assigned later. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused Value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David S. Miller authored
Haiyang Zhang says: ==================== Add software backchannel and mlx5e HV VHCA stats This patch set adds paravirtual backchannel in software in pci_hyperv, which is required by the mlx5e driver HV VHCA stats agent. The stats agent is responsible on running a periodic rx/tx packets/bytes stats update. ==================== Signed-off-by: -
Eran Ben Elisha authored
HV VHCA stats agent is responsible on running a preiodic rx/tx packets/bytes stats update. Currently the supported format is version MLX5_HV_VHCA_STATS_VERSION. Block ID 1 is dedicated for statistics data transfer from the VF to the PF. The reporter fetch the statistics data from all opened channels, fill it in a buffer and send it to mlx5_hv_vhca_write_agent. As the stats layer should include some metadata per block (sequence and offset), the HV VHCA layer shall modify the buffer before actually send it over block 1. Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Eran Ben Elisha authored
Control agent is responsible over of the control block (ID 0). It should update the PF via this block about every capability change. In addition, upon block 0 invalidate, it should activate all other supported agents with data requests from the PF. Upon agent create/destroy, the invalidate callback of the control agent is being called in order to update the PF driver about this change. The control agent is an integral part of HV VHCA and will be created and destroy as part of the HV VHCA init/cleanup flow. Signed-off-by:
-
Eran Ben Elisha authored
HV VHCA is a layer which provides PF to VF communication channel based on HyperV PCI config channel. It implements Mellanox's Inter VHCA control communication protocol. The protocol contains control block in order to pass messages between the PF and VF drivers, and data blocks in order to pass actual data. The infrastructure is agent based. Each agent will be responsible of contiguous buffer blocks in the VHCA config space. This infrastructure will bind agents to their blocks, and those agents can only access read/write the buffer blocks assigned to them. Each agent will provide three callbacks (control, invalidate, cleanup). Control will be invoked when block-0 is invalidated with a command that concerns this agent. Invalidate callback will be invoked if one of the blocks assigned to this agent was invalidated. Cleanup will be invoked before the agent is being freed in order to clean all of its open resources or deferred works. Block-0 serves as the control block. All execution commands from the PF will be written by the PF over this block. VF will ack on those by writing on block-0 as well. Its format is described by struct mlx5_hv_vhca_control_block layout. Signed-off-by:
-
Eran Ben Elisha authored
Add wrapper functions for HyperV PCIe read / write / block_invalidate_register operations. This will be used as an infrastructure in the downstream patch for software communication. This will be enabled by default if CONFIG_PCI_HYPERV_INTERFACE is set. Signed-off-by:
-
Haiyang Zhang authored
This interface driver is a helper driver allows other drivers to have a common interface with the Hyper-V PCI frontend driver. Signed-off-by:
-
Dexuan Cui authored
Windows SR-IOV provides a backchannel mechanism in software for communication between a VF driver and a PF driver. These "configuration blocks" are similar in concept to PCI configuration space, but instead of doing reads and writes in 32-bit chunks through a very slow path, packets of up to 128 bytes can be sent or received asynchronously. Nearly every SR-IOV device contains just such a communications channel in hardware, so using this one in software is usually optional. Using the software channel, however, allows driver implementers to leverage software tools that fuzz the communications channel looking for vulnerabilities. The usage model for these packets puts the responsibility for reading or writing on the VF driver. The VF driver sends a read or a write packet, indicating which "block" is being referred to by number. If the PF driver wishes to initiate communication, it can "invalidate" one or more of the first 64 blocks. This invalidation is delivered via a callback supplied by the VF driver by this driver. No protocol is implied, except that supplied by the PF and VF drivers. Signed-off-by:
Jake Oshins <jakeo@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5 tc flow handling for concurrent execution (Part 3) This series includes updates to mlx5 ethernet and core driver: Vlad submits part 3 of 3 part series to allow TC flow handling for concurrent execution. Vlad says: ========== Structure mlx5e_neigh_hash_entry code that uses it are refactored in following ways: - Extend neigh_hash_entry with rcu and modify its users to always take reference to the structure when using it (neigh_hash_entry has already had atomic reference counter which was only used when scheduling neigh update on workqueue from atomic context of neigh update netevent). - Always use mlx5e_neigh_update_table->encap_lock when modifying neigh update hash table and list. Originally, this lock was only used to synchronize with netevent handler function, which is called from bh context and cannot use rtnl lock for synchronization. Use rcu read lock instead of encap_lock to lookup nhe in atomic context of netevent even handler function. Convert encap_lock to mutex to allow creating new neigh hash entries while holding it, which is safe to do because the lock is no longer used in atomic context. - Rcu-ify mlx5e_neigh_hash_entry->encap_list by changing operations on encap list to their rcu counterparts and extending encap structure with rcu_head to free the encap instances after rcu grace period. This allows fast traversal of list of encaps attached to nhe under rcu read lock protection. - Take encap_table_lock when accessing encap entries in neigh update and neigh stats update code to protect from concurrent encap entry insertion or removal. This approach leads to potential race condition when neigh update and neigh stats update code can access encap and flow entries that are not fully initialized or are being destroyed, or neigh can change state without updating encaps that are created concurrently. Prevent these issues by following changes in flow and encap initialization: - Extend mlx5e_tc_flow with 'init_done' completion. Modify neigh update to wait for both encap and flow completions to prevent concurrent access to a structure that is being initialized by tc. - Skip structures that failed during initialization: encaps with encap_id<0 and flows that don't have OFFLOADED flag set. - To ensure that no new flows are added to encap when it is being accessed by neigh update or neigh stats update, take encap_table_lock mutex. - To prevent concurrent deletion by tc, ensure that neigh update and neigh stats update hold references to encap and flow instances while using them. With changes presented in this patch set it is now safe to execute tc concurrently with neigh update and neigh stats update. However, these two workqueue tasks modify same flow "tmp_list" field to store flows with reference taken in temporary list to release the references after update operation finishes and should not be executed concurrently with each other. Last 3 patches of this series provide 3 new mlx5 trace points to track mlx5 tc requests and mlx5 neigh updates. ==================== Signed-off-by:
-
- 21 Aug, 2019 3 commits
-
-
Vlad Buslov authored
Allow tracing neigh state during neigh update task that is executed on workqueue and is scheduled by neigh state change event. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_rep_neigh_update >> set_event ># cat trace ... kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by:Vlad Buslov <vladbu@mellanox.com> Reviewed-by:
Dmytro Linkin <dmitrolin@mellanox.com> Signed-off-by:
-
Vlad Buslov authored
Allow tracing result of neigh used value update task that is executed periodically on workqueue. Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_tc_update_neigh_used_value >> set_event ># cat trace ... kworker/u48:4-8806 [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1 Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by: -
Dmytro Linkin authored
Implemented following tracepoints: 1. Configure flower (mlx5e_configure_flower) 2. Delete flower (mlx5e_delete_flower) 3. Stats flower (mlx5e_stats_flower) Usage example: ># cd /sys/kernel/debug/tracing ># echo mlx5:mlx5e_configure_flower >> set_event ># cat trace ... tc-6535 [019] ...1 2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT Added corresponding documentation in Documentation/networking/device-driver/mellanox/mlx5.rst Signed-off-by:
-
