- 29 Nov, 2023 2 commits
-
-
Dan Carpenter authored
Set the "err" variable on this error path. Fixes: fff292b4 ("ice: add VF representors one by one") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Wojciech Drewek <wojciech.drewek@intel.com> Link: https://lore.kernel.org/r/e0349ee5-76e6-4ff4-812f-4aa0d3f76ae7@moroto.mountainSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yu Xiao authored
Add support for ethtool -A tx on/off and rx on/off. Signed-off-by:
Yu Xiao <yu.xiao@corigine.com> Signed-off-by:
Louis Peens <louis.peens@corigine.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231127055116.6668-1-louis.peens@corigine.comSigned-off-by:
-
- 28 Nov, 2023 32 commits
-
-
Paolo Abeni authored
Jakub Kicinski says: ==================== net: page_pool: add netlink-based introspection We recently started to deploy newer kernels / drivers at Meta, making significant use of page pools for the first time. We immediately run into page pool leaks both real and false positive warnings. As Eric pointed out/predicted there's no guarantee that applications will read / close their sockets so a page pool page may be stuck in a socket (but not leaked) forever. This happens a lot in our fleet. Most of these are obviously due to application bugs but we should not be printing kernel warnings due to minor application resource leaks. Conversely the page pool memory may get leaked at runtime, and we have no way to detect / track that, unless someone reconfigures the NIC and destroys the page pools which leaked the pages. The solution presented here is to expose the memory use of page pools via netlink. This allows for continuous monitoring of memory used by page pools, regardless if they were destroyed or not. Sample in patch 15 can print the memory use and recycling efficiency: $ ./page-pool eth0[2] page pools: 10 (zombies: 0) refs: 41984 bytes: 171966464 (refs: 0 bytes: 0) recycling: 90.3% (alloc: 656:397681 recycle: 89652:270201) v4: - use dev_net(netdev)->loopback_dev - extend inflight doc v3: https://lore.kernel.org/all/20231122034420.1158898-1-kuba@kernel.org/ - ID is still here, can't decide if it matters - rename destroyed -> detach-time, good enough? - fix build for netsec v2: https://lore.kernel.org/r/20231121000048.789613-1-kuba@kernel.org - hopefully fix build with PAGE_POOL=n v1: https://lore.kernel.org/all/20231024160220.3973311-1-kuba@kernel.org/ - The main change compared to the RFC is that the API now exposes outstanding references and byte counts even for "live" page pools. The warning is no longer printed if page pool is accessible via netlink. RFC: https://lore.kernel.org/all/20230816234303.3786178-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20231126230740.2148636-1-kuba@kernel.orgSigned-off-by:Paolo Abeni <pabeni@redhat.com>
-
Jakub Kicinski authored
Regenerate the tools/ code after netdev spec changes. Add sample to query page-pool info in a concise fashion: $ ./page-pool eth0[2] page pools: 10 (zombies: 0) refs: 41984 bytes: 171966464 (refs: 0 bytes: 0) recycling: 90.3% (alloc: 656:397681 recycle: 89652:270201) Acked-by:Jesper Dangaard Brouer <hawk@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
Mute the periodic "stalled pool shutdown" warning if the page pool is visible to user space. Rolling out a driver using page pools to just a few hundred hosts at Meta surfaces applications which fail to reap their broken sockets. Obviously it's best if the applications are fixed, but we don't generally print warnings for application resource leaks. Admins can now depend on the netlink interface for getting page pool info to detect buggy apps. While at it throw in the ID of the pool into the message, in rare cases (pools from destroyed netns) this will make finding the pool with a debugger easier. Reviewed-by:
Eric Dumazet <edumazet@google.com> Acked-by:
-
Jakub Kicinski authored
Dump the stats into netlink. More clever approaches like dumping the stats per-CPU for each CPU individually to see where the packets get consumed can be implemented in the future. A trimmed example from a real (but recently booted system): $ ./cli.py --no-schema --spec netlink/specs/netdev.yaml \ --dump page-pool-stats-get [{'info': {'id': 19, 'ifindex': 2}, 'alloc-empty': 48, 'alloc-fast': 3024, 'alloc-refill': 0, 'alloc-slow': 48, 'alloc-slow-high-order': 0, 'alloc-waive': 0, 'recycle-cache-full': 0, 'recycle-cached': 0, 'recycle-released-refcnt': 0, 'recycle-ring': 0, 'recycle-ring-full': 0}, {'info': {'id': 18, 'ifindex': 2}, 'alloc-empty': 66, 'alloc-fast': 11811, 'alloc-refill': 35, 'alloc-slow': 66, 'alloc-slow-high-order': 0, 'alloc-waive': 0, 'recycle-cache-full': 1145, 'recycle-cached': 6541, 'recycle-released-refcnt': 0, 'recycle-ring': 1275, 'recycle-ring-full': 0}, {'info': {'id': 17, 'ifindex': 2}, 'alloc-empty': 73, 'alloc-fast': 62099, 'alloc-refill': 413, ... Acked-by: -
Jakub Kicinski authored
Report when page pool was destroyed. Together with the inflight / memory use reporting this can serve as a replacement for the warning about leaked page pools we currently print to dmesg. Example output for a fake leaked page pool using some hacks in netdevsim (one "live" pool, and one "leaked" on the same dev): $ ./cli.py --no-schema --spec netlink/specs/netdev.yaml \ --dump page-pool-get [{'id': 2, 'ifindex': 3}, {'id': 1, 'ifindex': 3, 'destroyed': 133, 'inflight': 1}] Tested-by:Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by:
-
Jakub Kicinski authored
Advanced deployments need the ability to check memory use of various system components. It makes it possible to make informed decisions about memory allocation and to find regressions and leaks. Report memory use of page pools. Report both number of references and bytes held. Acked-by:
-
Jakub Kicinski authored
Generate netlink notifications about page pool state changes. Reviewed-by:
-
Jakub Kicinski authored
Expose the very basic page pool information via netlink. Example using ynl-py for a system with 9 queues: $ ./cli.py --no-schema --spec netlink/specs/netdev.yaml \ --dump page-pool-get [{'id': 19, 'ifindex': 2, 'napi-id': 147}, {'id': 18, 'ifindex': 2, 'napi-id': 146}, {'id': 17, 'ifindex': 2, 'napi-id': 145}, {'id': 16, 'ifindex': 2, 'napi-id': 144}, {'id': 15, 'ifindex': 2, 'napi-id': 143}, {'id': 14, 'ifindex': 2, 'napi-id': 142}, {'id': 13, 'ifindex': 2, 'napi-id': 141}, {'id': 12, 'ifindex': 2, 'napi-id': 140}, {'id': 11, 'ifindex': 2, 'napi-id': 139}, {'id': 10, 'ifindex': 2, 'napi-id': 138}] Reviewed-by: -
Jakub Kicinski authored
Add a Netlink spec in YAML for getting very basic information about page pools. Reviewed-by:
-
Jakub Kicinski authored
Link page pool instances to netdev for the drivers which already link to NAPI. Unless the driver is doing something very weird per-NAPI should imply per-netdev. Add netsec as well, Ilias indicates that it fits the mold. Reviewed-by:
-
Jakub Kicinski authored
To avoid any issues with race conditions on accessing napi and having to think about the lifetime of NAPI objects in netlink GET - stash the napi_id to which page pool was linked at creation time. Reviewed-by:
-
Jakub Kicinski authored
Link the page pools with netdevs. This needs to be netns compatible so we have two options. Either we record the pools per netns and have to worry about moving them as the netdev gets moved. Or we record them directly on the netdev so they move with the netdev without any extra work. Implement the latter option. Since pools may outlast netdev we need a place to store orphans. In time honored tradition use loopback for this purpose. Reviewed-by:
Mina Almasry <almasrymina@google.com> Reviewed-by:
-
Jakub Kicinski authored
To give ourselves the flexibility of creating netlink commands and ability to refer to page pool instances in uAPIs create IDs for page pools. Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Signed-off-by:
-
Jakub Kicinski authored
We'll soon (next change in the series) need a fuller unwind path in page_pool_create() so create the inverse of page_pool_init(). Reviewed-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-11-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.8 The first features pull request for v6.8. Not so big in number of commits but we removed quite a few ancient drivers: libertas 16-bit PCMCIA support, atmel, hostap, zd1201, orinoco, ray_cs, wl3501 and rndis_wlan. Major changes: cfg80211/mac80211 - extend support for scanning while Multi-Link Operation (MLO) connected * tag 'wireless-next-2023-11-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (68 commits) wifi: nl80211: Documentation update for NL80211_CMD_PORT_AUTHORIZED event wifi: mac80211: Extend support for scanning while MLO connected wifi: cfg80211: Extend support for scanning while MLO connected wifi: ieee80211: fix PV1 frame control field name rfkill: return ENOTTY on invalid ioctl MAINTAINERS: update iwlwifi maintainers wifi: rtw89: 8922a: read efuse content from physical map wifi: rtw89: 8922a: read efuse content via efuse map struct from logic map wifi: rtw89: 8852c: read RX gain offset from efuse for 6GHz channels wifi: rtw89: mac: add to access efuse for WiFi 7 chips wifi: rtw89: mac: use mac_gen pointer to access about efuse wifi: rtw89: 8922a: add 8922A basic chip info wifi: rtlwifi: drop unused const_amdpci_aspm wifi: mwifiex: mwifiex_process_sleep_confirm_resp(): remove unused priv variable wifi: rtw89: regd: update regulatory map to R65-R44 wifi: rtw89: regd: handle policy of 6 GHz according to BIOS wifi: rtw89: acpi: process 6 GHz band policy from DSM wifi: rtlwifi: simplify rtl_action_proc() and rtl_tx_agg_start() wifi: rtw89: pci: update interrupt mitigation register for 8922AE wifi: rtw89: pci: correct interrupt mitigation register for 8852CE ... ==================== Link: https://lore.kernel.org/r/20231127180056.0B48DC433C8@smtp.kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Pedro Tammela says: ==================== selftests: tc-testing: updates and cleanups for tdc Address the recommendations from the previous series and cleanup some leftovers. ==================== Link: https://lore.kernel.org/r/20231124154248.315470-1-pctammela@mojatatu.comSigned-off-by:
-
Pedro Tammela authored
Remove this leftover from the times we pre-allocated everything Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Link: https://lore.kernel.org/r/20231124154248.315470-6-pctammela@mojatatu.comSigned-off-by:
-
Pedro Tammela authored
Cleanup net namespaces and other resources if we get a SIGINT (Ctrl-C). As user visible resources are allocated on a per test basis, it's only required to catch this condition when (possibly) running tests. So far calling post_suite is enough to free up anything that might linger. A missing keyword replacement for nsPlugin is also included. Signed-off-by:
-
Pedro Tammela authored
As suggested by Simon, prefix the functions that operate on iproute2 commands in contrast with the "nl" netlink prefix. Cc: Simon Horman <horms@kernel.org> Signed-off-by:
-
Pedro Tammela authored
This operation is redundant and it's not stabilizing nor waiting for anything. Signed-off-by:
-
Pedro Tammela authored
As tdc only tests loading/deleting and anything more complicated is better left to the ebpf test suite, provide a pre-compiled version of 'action.c' and don't bother compiling it in kselftests or on the fly at all. Cc: Davide Caratti <dcaratti@redhat.com> Signed-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== net: phylink: improve PHY validation One of the issues which has concerned me about the rate matching implenentation that we have is that phy_get_rate_matching() returns whether rate matching will be used for a particular interface, and we enquire only for one interface. Aquantia PHYs can be programmed with the rate matching and interface mode settings on a per-media speed basis using the per-speed vendor 1 global configuration registers. Thus, it is possible for the PHY to be configured to use rate matching for 10G, 5G, 2.5G with 10GBASE-R, and then SGMII for the remaining speeds. Therefore, it clearly doesn't make sense to enquire about rate matching for just one interface mode. Also, PHYs that change their interfaces are handled sub-optimally, in that we validate all the interface modes that the host supports, rather than the interface modes that the PHY will use. This patch series changes the way we validate PHYs, but in order to do so, we need to know exactly which interface modes will be used by the PHY. So that phylib can convey this information, we add "possible_interfaces" to struct phy_device. possible_interfaces is to be filled in by a phylib driver once the PHY is configured (in other words in the PHYs .config_init method) with the interface modes that it will switch between. This then allows users of phylib to know which interface modes will be used by the PHY. This allows us to solve both these issues: where possible_interfaces is provided, we can validate which ethtool link modes can be supported by looking at which interface modes that both the PHY and host support, and request rate matching information for each mode. This should improve the accuracy of the validation. Sending this out again without RFC as Jie Luo will need it for the QCA8084 changes. No changes except to add the attributations already received. Thanks! ==================== Link: https://lore.kernel.org/r/ZWCWn+uNkVLPaQhn@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Some PHYs such as Aquantia, Broadcom 84881, and Marvell 88X33x0 can switch between a set of interface types depending on the negotiated media speed, or can use rate adaption for some or all of these interface types. We currently assume that these are Clause 45 PHYs that are configured not to use a specific set of interface modes, which has worked so far, but is just a work-around. In this workaround, we validate using all interfaces that the MAC supports, which can lead to extra modes being advertised that can not be supported. To properly address this, switch to using the newly introduced PHY possible_interfaces bitmap which indicates which interface modes will be used by the PHY as configured. We calculate the union of the PHY's possible interfaces and MACs supported interfaces, checking that is non-empty. If the PHY is on a SFP, we further reduce the set by those which can be used on a SFP module, again checking that is non-empty. Finally, we validate the subset of interfaces, taking account of whether rate matching will be used for each individual interface mode. This becomes independent of whether the PHY is clause 22 or clause 45. It is encouraged that all PHYs that switch interface modes or use rate matching should populate phydev->possible_interfaces. Tested-by:
Luo Jie <quic_luoj@quicinc.com> Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1r6VIV-00DDMF-Pi@rmk-PC.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
When bringing up a PHY, we need to work out which ethtool link modes it should support and advertise. Clause 22 PHYs operate in a single interface mode, which can be easily dealt with. However, clause 45 PHYs tend to switch interface mode depending on the media. We need more flexible validation at this point, so this patch splits out that code in preparation to changing it. Tested-by:
-
Russell King (Oracle) authored
Pass the phy (if any) into phylink_validate_mask() so that we can validate each interface with its rate matching setting. Tested-by:
-
Russell King (Oracle) authored
Pass the phy (if any) into phylink_validate_one() so that we can validate each interface with its rate matching setting. Tested-by:
-
Russell King (Oracle) authored
Split out the internals of phylink_validate_mask() to make the code easier to read. Tested-by:
-
Russell King (Oracle) authored
Fill in the possible_interfaces bitmap for AQR113C so phylink knows which interface modes will be used by the PHY. Signed-off-by:
-
Russell King (Oracle) authored
Fill in the possible_interfaces member. This PHY driver only supports a single configuration found on SFPs. Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by:
-
Russell King (Oracle) authored
Fill in the possible_interfaces member according to the selected mactype mode. Signed-off-by:
-
Russell King (Oracle) authored
Replace the code-based mactype decode with a table driven approach. This will allow us to fill in the possible_interfaces cleanly. Signed-off-by:
-
Russell King (Oracle) authored
Add a possible_interfaces member to struct phy_device to indicate which interfaces a clause 45 PHY may switch between depending on the media. This must be populated by the PHY driver by the time the .config_init() method completes according to the PHYs host-side configuration. For example, the Marvell 88x3310 PHY can switch between 10GBASE-R, 5GBASE-R, 2500BASE-X, and SGMII on the host side depending on the media side speed, so all these interface modes are set in the possible_interfaces member. This allows phylib users (such as phylink) to know in advance which interface modes to expect, which allows them to appropriately restrict the advertised link modes according to the capabilities of other parts of the link. Tested-by:
-
- 27 Nov, 2023 1 commit
-
-
Shradha Gupta authored
Extend performance counter stats in 'ethtool -S <interface>' for MANA VF to include all GDMA stat counter. Tested-on: Ubuntu22 Testcases: 1. LISA testcase: PERF-NETWORK-TCP-THROUGHPUT-MULTICONNECTION-NTTTCP-Synthetic 2. LISA testcase: PERF-NETWORK-TCP-THROUGHPUT-MULTICONNECTION-NTTTCP-SRIOV Signed-off-by:
Shradha Gupta <shradhagupta@linux.microsoft.com> Link: https://lore.kernel.org/r/1700830950-803-1-git-send-email-shradhagupta@linux.microsoft.comSigned-off-by:
-
- 26 Nov, 2023 1 commit
-
-
Jesper Dangaard Brouer authored
Pages belonging to a page_pool (PP) instance must be freed through the PP APIs in-order to correctly release any DMA mappings and release refcnt on the DMA device when freeing PP instance. When PP release a page (page_pool_release_page) the page->pp_magic value is cleared. This patch detect a leaked PP page in free_page_is_bad() via unexpected state of page->pp_magic value being PP_SIGNATURE. We choose to report and treat it as a bad page. It would be possible to release the page via returning it to the PP instance as the page->pp pointer is likely still valid. Notice this code is only activated when either compiled with CONFIG_DEBUG_VM or boot cmdline debug_pagealloc=on, and CONFIG_PAGE_POOL. Reduced example output of leak with PP_SIGNATURE = dead000000000040: BUG: Bad page state in process swapper/4 pfn:141fa6 page:000000006dbf8062 refcount:0 mapcount:0 mapping:0000000000000000 index:0x141fa6000 pfn:0x141fa6 flags: 0x2fffff80000000(node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 002fffff80000000 dead000000000040 ffff88814888a000 0000000000000000 raw: 0000000141fa6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak [...] Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x263/0x430 free_unref_page+0x34/0x130 mlx5e_free_rx_mpwqe+0x190/0x1c0 [mlx5_core] mlx5e_post_rx_mpwqes+0x1ac/0x280 [mlx5_core] mlx5e_napi_poll+0x12b/0x710 [mlx5_core] ? skb_free_head+0x4f/0x90 __napi_poll+0x2b/0x1c0 net_rx_action+0x27b/0x360 The advantage is the Call Trace directly points to the function leaking the PP page, which in this case is an on purpose bug introduced into the mlx5 driver to test this code change. Currently PP will periodically in page_pool_release_retry() printk warning "stalled pool shutdown" which cannot be directly corrolated to leaking and might as well be a false positive due to SKBs being stuck on a socket for an extended period. After this patch we should be able to remove this printk. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 25 Nov, 2023 4 commits
-
-
Ido Schimmel authored
I accidentally removed the error checking after issuing the reset. Restore it. Fixes: f257c73e ("mlxsw: pci: Add support for new reset flow") Reported-by:
Coverity Scan <scan-admin@coverity.com> Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
-
Marek Behún authored
RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
-
Jakub Kicinski authored
Kory says: ==================== This patch was initially submitted as part of a net patch series. Conor expressed interest in using it in a different subsystem. https://lore.kernel.org/netdev/20231116-feature_poe-v1-7-be48044bf249@bootlin.com/ Consequently, I extracted it from the series and submitted it separately. I first tried to send it to driver-core but it seems also not the best choice: https://lore.kernel.org/lkml/2023111720-slicer-exes-7d9f@gregkh/ ==================== Signed-off-by:
-
Kory Maincent authored
No error code are available to signal an invalid firmware content. Drivers that can check the firmware content validity can not return this specific failure to the user-space Expand the firmware error code with an additional code: - "firmware invalid" code which can be used when the provided firmware is invalid Sync lib/test_firmware.c file accordingly. Acked-by:
Luis Chamberlain <mcgrof@kernel.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Kory Maincent <kory.maincent@bootlin.com> Reviewed-by:
-
