- 12 Apr, 2021 1 commit
-
-
Colin Ian King authored
The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 12b276fb ("cxgb4: add support to create hash filters") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 11 Apr, 2021 20 commits
-
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: support two more platforms This series adds IPA support for two more Qualcomm SoCs. The first patch updates the DT binding to add compatible strings. The second temporarily disables checksum offload support for IPA version 4.5 and above. Changes are required to the RMNet driver to support the "inline" checksum offload used for IPA v4.5+, and once those are present this capability will be enabled for IPA. The third and fourth patches add configuration data for IPA versions 4.5 (used for the SDX55 SoC) and 4.11 (used for the SD7280 SoC). ==================== Signed-off-by: -
Alex Elder authored
Add support for the SC7280 SoC, which includes IPA version 4.11. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Add support for the SDX55 SoC, which includes IPA version 4.5. Starting with IPA v4.5, a few of the memory regions have a different number of "canary" values; update comments in the where the region identifers are defined to accurately reflect that. I'll note three differences in SDX55 versus the other two existing platforms (SDM845 and SC7180): - SDX55 uses a 32-bit Linux kernel - SDX55 has four interconnects rather than three - SDX55 uses IPA v4.5, which uses inline checksum offload Signed-off-by:
-
Alex Elder authored
Checksum offload for IPA v4.5+ is implemented differently, using "inline" offload (which uses a common header format for both upload and download offload). The IPA hardware must be programmed to enable MAP checksum offload, but the RMNet driver is responsible for interpreting checksum metadata supplied with messages. Currently, the RMNet driver does not support inline checksum offload. This support is imminent, but until it is available, do not allow newer versions of IPA to specify checksum offload for endpoints. Signed-off-by:
-
Alex Elder authored
Add existing supported platform "qcom,sc7180-ipa" to the set of IPA compatible strings. Also add newly-supported "qcom,sdx55-ipa", "qcom,sc7280-ipa". Signed-off-by:
-
Qiheng Lin authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Qiheng Lin <linqiheng@huawei.com> Signed-off-by:
-
David S. Miller authored
Paolo Abeni says: ==================== veth: allow GRO even without XDP This series allows the user-space to enable GRO/NAPI on a veth device even without attaching an XDP program. It does not change the default veth behavior (no NAPI, no GRO), except that the GRO feature bit on top of this series will be effectively off by default on veth devices. Note that currently the GRO bit is on by default, but GRO never takes place in absence of XDP. On top of this series, setting the GRO feature bit enables NAPI and allows the GRO to take place. The TSO features on the peer device are preserved. The main goal is improving UDP forwarding performances for containers in a typical virtual network setup: (container) veth -> veth peer -> bridge/ovs -> vxlan -> NIC Enabling the NAPI threaded mode, GRO the NETIF_F_GRO_UDP_FWD feature on the veth peer improves the UDP stream performance with not void netfilter configuration by 2x factor with no measurable overhead for TCP traffic: some heuristic ensures that TCP will not go through the additional NAPI/GRO layer. Some self-tests are added to check the expected behavior in the default configuration, with XDP and with plain GRO enabled. ==================== Signed-off-by: -
Paolo Abeni authored
Add some basic veth tests, that verify the expected flags and aggregation with different setups (default, xdp, etc...) Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
After the previous patch, when enabling GRO, locally generated TCP traffic experiences some measurable overhead, as it traverses the GRO engine without any chance of aggregation. This change refine the NAPI receive path admission test, to avoid unnecessary GRO overhead in most scenarios, when GRO is enabled on a veth peer. Only skbs that are eligible for aggregation enter the GRO layer, the others will go through the traditional receive path. Signed-off-by:
-
Paolo Abeni authored
Currently the veth device has the GRO feature bit set, even if no GRO aggregation is possible with the default configuration, as the veth device does not hook into the GRO engine. Flipping the GRO feature bit from user-space is a no-op, unless XDP is enabled. In such scenario GRO could actually take place, but TSO is forced to off on the peer device. This change allow user-space to really control the GRO feature, with no need for an XDP program. The GRO feature bit is now cleared by default - so that there are no user-visible behavior changes with the default configuration. When the GRO bit is set, the per-queue NAPI instances are initialized and registered. On xmit, when napi instances are available, we try to use them. Some additional checks are in place to ensure we initialize/delete NAPIs only when needed in case of overlapping XDP and GRO configuration changes. Signed-off-by:
-
Paolo Abeni authored
As described by commit 9c4c3252 ("skbuff: preserve sock reference when scrubbing the skb."), orphaning a skb in the TX path will cause OoO. Let's use skb_orphan_partial() instead of skb_orphan(), so that we keep the sk around for queue's selection sake and we still avoid the problem fixed with commit 4bf9ffa0 ("veth: Orphan skb before GRO") Signed-off-by:
-
David S. Miller authored
Moshe Shemesh says: ==================== ethtool: Extend module EEPROM dump API Ethtool supports module EEPROM dumps via the `ethtool -m <dev>` command. But in current state its functionality is limited - offset and length parameters, which are used to specify a linear desired region of EEPROM data to dump, is not enough, considering emergence of complex module EEPROM layouts such as CMIS 4.0. Moreover, CMIS 4.0 extends the amount of pages that may be accessible by introducing another parameter for page addressing - banks. Besides, currently module EEPROM is represented as a chunk of concatenated pages, where lower 128 bytes of all pages, except page 00h, are omitted. Offset and length are used to address parts of this fake linear memory. But in practice drivers, which implement get_module_info() and get_module_eeprom() ethtool ops still calculate page number and set I2C address on their own. This series tackles these issues by adding ethtool op, which allows to pass page number, bank number and I2C address in addition to offset and length parameters to the driver, adds corresponding netlink infrastructure and implements the new interface in mlx5 driver. This allows to extend userspace 'ethtool -m' CLI by adding new parameters - page, bank and i2c. New command line format: ethtool -m <dev> [hex on|off] [raw on|off] [offset N] [length N] [page N] [bank N] [i2c N] The consequence of this series is a possibility to dump arbitrary EEPROM page at a time, in contrast to dumps of concatenated pages. Therefore, offset and length change their semantics and may be used only to specify a part of data within half page boundary, which size is currently limited to 128 bytes. As for drivers that support legacy get_module_info() and get_module_eeprom() pair, the series addresses it by implementing a fallback mechanism. As mentioned earlier, such drivers derive a page number from 'global' offset, so this can be done vice versa without their involvement thanks to standardization. If kernel netlink handler of 'ethtool -m' command detects that new ethtool op is not supported by the driver, it calculates offset from given page number and page offset and calls old ndos, if they are available. ==================== \Signed-off-by: David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
If the device has a sfp bus attached, call its sfp_get_module_eeprom_by_page() function, otherwise use the ethtool op for the device. This follows how the IOCTL works. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Andrew Lunn authored
The new netlink API for reading SFP data requires a new op to be implemented. The idea of the new netlink SFP code is that userspace is responsible to parsing the EEPROM data and requesting pages, rather than have the kernel decide what pages are interesting and returning them. This allows greater flexibility for newer formats. Currently the generic SFP code only supports simple SFPs. Allow i2c address 0x50 and 0x51 to be accessed with page and bank must always be 0. This interface will later be extended when for example QSFP support is added. Signed-off-by:
Vladyslav Tarasiuk <vladyslavt@nvidia.com> Signed-off-by:
-
Vladyslav Tarasiuk authored
In case netlink get_module_eeprom_by_page() callback is not implemented by the driver, try to call old get_module_info() and get_module_eeprom() pair. Recalculate parameters to get_module_eeprom() offset and len using page number and their sizes. Return error if this can't be done. Signed-off-by:
-
Andrew Lunn authored
There are two ways to retrieve information from SFP EEPROMs. Many devices make use of the common code, and assign the sfp_bus pointer in the netdev to point to the bus holding the SFP device. Some MAC drivers directly implement ops in there ethool structure. Export within net/ethtool the two helpers used to call these methods, so that they can also be used in the new netlink code. Signed-off-by:
-
Vladyslav Tarasiuk authored
Allow the driver to recognise DSFP transceiver module ID and therefore allow its EEPROM dumps using ethtool. Signed-off-by:
-
Vladyslav Tarasiuk authored
Implement ethtool_ops::get_module_eeprom_by_page() to enable support of new SFP standards. Signed-off-by:
-
Vladyslav Tarasiuk authored
Prepare for ethtool_ops::get_module_eeprom_data() implementation by extracting common part of mlx5_query_module_eeprom() into a separate function. Signed-off-by:
-
Vladyslav Tarasiuk authored
Define get_module_eeprom_by_page() ethtool callback and implement netlink infrastructure. get_module_eeprom_by_page() allows network drivers to dump a part of module's EEPROM specified by page and bank numbers along with offset and length. It is effectively a netlink replacement for get_module_info() and get_module_eeprom() pair, which is needed due to emergence of complex non-linear EEPROM layouts. Signed-off-by:
-
- 10 Apr, 2021 12 commits
-
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: a few small fixes This series implements some minor bug fixes or improvements. The first patch removes an apparently unnecessary restriction, which results in an error on a 32-bit ARM build. The second makes a definition used for SDM845 match what is used in the downstream code. The third just ensures two netdev pointers are only non-null when valid. The fourth simplifies a little code, knowing that a called function never returns an error. The fifth and sixth just remove some empty/place holder functions. And the last patch fixes a comment, makes a function private, and removes an unnecessary double-negation of a Boolean variable. This patch produces a warning from checkpatch, indicating that a pair of parentheses is unnecessary. I agree with that advice, but it conflicts with a suggestion from the compiler. I left the "problem" in place to avoid the compiler warning. ==================== Link: https://lore.kernel.org/r/20210409180722.1176868-1-elder@linaro.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
Some time ago changes were made to stop referring to clearing the hardware pipeline as a "tag process." Fix a comment to use the newer terminology. Get rid of a pointless double-negation of the Boolean toward_ipa flag in ipa_endpoint_config(). make ipa_endpoint_exit_one() private; it's only referenced inside "ipa_endpoint.c". Signed-off-by:
-
Alex Elder authored
There are place holder functions in the GSI code that do nothing. Remove these, knowing we can add something back in their place if they're really needed someday. Some of these are inverse functions (such as teardown to match setup). Explicitly comment that there is no inverse in these cases. Signed-off-by:
-
Alex Elder authored
There are place holder functions in the IPA code that do nothing. For the most part these are inverse functions, for example, once the routing or filter tables are set up there is no need to perform any matching teardown activity at shutdown, or in the case of an error. These can be safely removed, resulting in some code simplification. Add comments in these spots making it explicit that there is no inverse. Signed-off-by:
-
Alex Elder authored
In ipa_modem_stop(), if the modem netdev pointer is non-null we call ipa_stop(). We check for an error and if one is returned we handle it. But ipa_stop() never returns an error, so this extra handling is unnecessary. Simplify the code in ipa_modem_stop() based on the knowledge no error handling is needed at this spot. Signed-off-by:
-
Alex Elder authored
In ipa_modem_start(), we set endpoint netdev pointers before the network device is registered. If registration fails, we don't undo those assignments. Instead, wait to assign the netdev pointer until after registration succeeds. Set these endpoint netdev pointers to NULL in ipa_modem_stop() before unregistering the network device. Signed-off-by:
-
Alex Elder authored
On IPA v3.5.1, the sequencer type for the modem TX endpoint does not define the replication portion in the same way the downstream code does. This difference doesn't affect the behavior of the upstream code, but I'd prefer the two code bases use the same configuration value here. Signed-off-by:
-
Alex Elder authored
I no longer know why a validation check ensured the size of an entry passed to gsi_trans_pool_init() was restricted to be a multiple of 8. For 32-bit builds, this condition doesn't always hold, and for DMA pools, the size is rounded up to a power of 2 anyway. Remove this restriction. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
Conflicts: MAINTAINERS - keep Chandrasekar drivers/net/ethernet/mellanox/mlx5/core/en_main.c - simple fix + trust the code re-added to param.c in -next is fine include/linux/bpf.h - trivial include/linux/ethtool.h - trivial, fix kdoc while at it include/linux/skmsg.h - move to relevant place in tcp.c, comment re-wrapped net/core/skmsg.c - add the sk = sk // sk = NULL around calls net/tipc/crypto.c - trivial Signed-off-by: -
Claudiu Manoil authored
Even if the current mapping is correct for the 1 CPU and 2 CPU cases (currently enetc is included in SoCs with up to 2 CPUs only), better use a generic rule for the mapping to cover all possible cases. The number of CPUs is the same as the number of interrupt vectors: Per device Tx rings - device_tx_ring[idx], where idx = 0..n_rings_total-1 Per interrupt vector Tx rings - int_vector[i].ring[j], where i = 0..n_int_vects-1 j = 0..n_rings_per_v-1 Mapping rule - n_rings_per_v = n_rings_total / n_int_vects for i = 0..n_int_vects - 1: for j = 0..n_rings_per_v - 1: idx = n_int_vects * j + i int_vector[i].ring[j] <- device_tx_ring[idx] Signed-off-by:
Claudiu Manoil <claudiu.manoil@nxp.com> Tested-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210409071613.28912-1-claudiu.manoil@nxp.comSigned-off-by:
-
Vladimir Oltean authored
The blamed commit introduced a bit in the TX software buffer descriptor structure for determining whether a BD is final or not; we rearm the TX interrupt vector for every frame (hence final BD) transmitted. But there is a problem with the patch: it replaced a condition whose expression is a bool which was evaluated at the beginning of the "while" loop with a bool expression that is evaluated on the spot: tx_swbd->is_eof. The problem with the latter expression is that the tx_swbd has already been incremented at that stage, so the tx_swbd->is_eof check is in fact with the _next_ software BD. Which is _not_ final. The effect is that the CPU is in 100% load with ksoftirqd because it does not acknowledge the TX interrupt, so the handler keeps getting called again and again. The fix is to restore the code structure, and keep the local bool is_eof variable, just to assign it the tx_swbd->is_eof value instead of !!tx_swbd->skb. Fixes: d504498d ("net: enetc: add a dedicated is_eof bit in the TX software BD") Reported-by:
Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-next 2021-04-09 This pr contains changes from mlx5-next branch, already reviewed on netdev and rdma mailing lists, links below. 1) From Leon, Dynamically assign MSI-X vectors count Already Acked by Bjorn Helgaas. https://patchwork.kernel.org/project/netdevbpf/cover/20210314124256.70253-1-leon@kernel.org/ 2) Cleanup series: https://patchwork.kernel.org/project/netdevbpf/cover/20210311070915.321814-1-saeed@kernel.org/ From Mark, E-Switch cleanups and refactoring, and the addition of single FDB mode needed HW bits. From Mikhael, Remove unused struct field From Saeed, Cleanup W=1 prototype warning From Zheng, Esw related cleanup From Tariq, User order-0 page allocation for EQs * 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Implement sriov_get_vf_total_msix/count() callbacks net/mlx5: Dynamically assign MSI-X vectors count net/mlx5: Add dynamic MSI-X capabilities bits PCI/IOV: Add sysfs MSI-X vector assignment interface net/mlx5: Use order-0 allocations for EQs net/mlx5: Add IFC bits needed for single FDB mode net/mlx5: E-Switch, Refactor send to vport to be more generic RDMA/mlx5: Use representor E-Switch when getting netdev and metadata net/mlx5: E-Switch, Add eswitch pointer to each representor net/mlx5: E-Switch, Add match on vhca id to default send rules net/mlx5: Remove unused mlx5_core_health member recover_work net/mlx5: simplify the return expression of mlx5_esw_offloads_pair() net/mlx5: Cleanup prototype warning ==================== Link: https://lore.kernel.org/r/20210409200704.10886-1-saeed@kernel.orgSigned-off-by:
-
- 09 Apr, 2021 7 commits
-
-
Dan Carpenter authored
This loop will try to unmap enetc_unmap_tx_buff[-1] and crash. Fixes: 9d2b68cc ("net: enetc: add support for XDP_REDIRECT") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Qiheng Lin authored
Eliminate the following coccicheck warning: drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c:529:3-9: WARNING: NULL check before some freeing functions is not needed. drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c:533:2-8: WARNING: NULL check before some freeing functions is not needed. drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c:161:2-7: WARNING: NULL check before some freeing functions is not needed. drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c:327:3-9: WARNING: NULL check before some freeing functions is not needed. Signed-off-by:
-
Jakub Kicinski authored
Heiner Kallweit says: ==================== net: make PHY PM ops a no-op if MAC driver manages PHY PM Resume callback of the PHY driver is called after the one for the MAC driver. The PHY driver resume callback calls phy_init_hw(), and this is potentially problematic if the MAC driver calls phy_start() in its resume callback. One issue was reported with the fec driver and a KSZ8081 PHY which seems to become unstable if a soft reset is triggered during aneg. The new flag allows MAC drivers to indicate that they take care of suspending/resuming the PHY. Then the MAC PM callbacks can handle any dependency between MAC and PHY PM. ==================== Link: https://lore.kernel.org/r/9e695411-ab1d-34fe-8b90-3e8192ab84f6@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Use the new mac_managed_pm flag to indicate that the driver takes care of PHY power management. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Use the new mac_managed_pm flag to work around an issue with KSZ8081 PHY that becomes unstable when a soft reset is triggered during aneg. Reported-by:
Joakim Zhang <qiangqing.zhang@nxp.com> Tested-by:
-
Heiner Kallweit authored
Resume callback of the PHY driver is called after the one for the MAC driver. The PHY driver resume callback calls phy_init_hw(), and this is potentially problematic if the MAC driver calls phy_start() in its resume callback. One issue was reported with the fec driver and a KSZ8081 PHY which seems to become unstable if a soft reset is triggered during aneg. The new flag allows MAC drivers to indicate that they take care of suspending/resuming the PHY. Then the MAC PM callbacks can handle any dependency between MAC and PHY PM. Signed-off-by:
-
Eric Dumazet authored
This reverts commit e880f8b3. 1) Patch has not been properly tested, and is wrong [1] 2) Patch submission did not include TCP maintainer (this is me) [1] divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 8426 Comm: syz-executor478 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__tcp_select_window+0x56d/0xad0 net/ipv4/tcp_output.c:3015 Code: 44 89 ff e8 d5 cd f0 f9 45 39 e7 0f 8d 20 ff ff ff e8 f7 c7 f0 f9 44 89 e3 e9 13 ff ff ff e8 ea c7 f0 f9 44 89 e0 44 89 e3 99 <f7> 7c 24 04 29 d3 e9 fc fe ff ff e8 d3 c7 f0 f9 41 f7 dc bf 1f 00 RSP: 0018:ffffc9000184fac0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff87832e76 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff87832e14 R11: 0000000000000000 R12: 0000000000000000 R13: 1ffff92000309f5c R14: 0000000000000000 R15: 0000000000000000 FS: 00000000023eb300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc2b5f426c0 CR3: 000000001c5cf000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcp_select_window net/ipv4/tcp_output.c:264 [inline] __tcp_transmit_skb+0xa82/0x38f0 net/ipv4/tcp_output.c:1351 tcp_transmit_skb net/ipv4/tcp_output.c:1423 [inline] tcp_send_active_reset+0x475/0x8e0 net/ipv4/tcp_output.c:3449 tcp_disconnect+0x15a9/0x1e60 net/ipv4/tcp.c:2955 inet_shutdown+0x260/0x430 net/ipv4/af_inet.c:905 __sys_shutdown_sock net/socket.c:2189 [inline] __sys_shutdown_sock net/socket.c:2183 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2201 __do_sys_shutdown net/socket.c:2209 [inline] __se_sys_shutdown net/socket.c:2207 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2207 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: e880f8b3 ("tcp: Reset tcp connections in SYN-SENT state") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Cc: Manoj Basapathi <manojbm@codeaurora.org> Cc: Sauvik Saha <ssaha@codeaurora.org> Link: https://lore.kernel.org/r/20210409170237.274904-1-eric.dumazet@gmail.comSigned-off-by:
-
