- 28 Feb, 2024 18 commits
-
-
Jason Xing authored
It's time to let it work right now. We've already prepared for this:) Signed-off-by:
Jason Xing <kernelxing@tencent.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jason Xing authored
Update three callers including both ipv4 and ipv6 and let the dropreason mechanism work in reality. Signed-off-by:
-
Jason Xing authored
In this patch, I equipped this function with more dropreasons, but it still doesn't work yet, which I will do later. Signed-off-by:
-
Jason Xing authored
This patch does two things: 1) add two more new reasons 2) only change the return value(1) to various drop reason values for the future use For now, we still cannot trace those two reasons. We'll implement the full function in the subsequent patch in this series. Signed-off-by:
-
Jason Xing authored
Soon later patches can use these relatively more accurate reasons to recognise and find out the cause. Signed-off-by:
-
Jason Xing authored
Like what I did to ipv4 mode, refine this part: adding more drop reasons for better tracing. Signed-off-by:
-
Jason Xing authored
Like previous patch does, only moving skb drop logical code to cookie_v6_check() for later refinement. Signed-off-by:
-
Jason Xing authored
Now it's time to use the prepared definitions to refine this part. Four reasons used might enough for now, I think. Signed-off-by:
-
Jason Xing authored
Only move the skb drop from tcp_v4_do_rcv() to cookie_v4_check() itself, no other changes made. It can help us refine the specific drop reasons later. Signed-off-by:
-
Jason Xing authored
Adding one drop reason to detect the condition of skb dropped because of hook points in cookie check and extending NO_SOCKET to consider another two cases can be used later. Signed-off-by:
-
Adam Li authored
This patch adds /proc/sys/net/core/mem_pcpu_rsv sysctl file, to make SK_MEMORY_PCPU_RESERV tunable. Commit 3cd3399d ("net: implement per-cpu reserves for memory_allocated") introduced per-cpu forward alloc cache: "Implement a per-cpu cache of +1/-1 MB, to reduce number of changes to sk->sk_prot->memory_allocated, which would otherwise be cause of false sharing." sk_prot->memory_allocated points to global atomic variable: atomic_long_t tcp_memory_allocated ____cacheline_aligned_in_smp; If increasing the per-cpu cache size from 1MB to e.g. 16MB, changes to sk->sk_prot->memory_allocated can be further reduced. Performance may be improved on system with many cores. Signed-off-by:
Adam Li <adamli@os.amperecomputing.com> Reviewed-by:
Christoph Lameter (Ampere) <cl@linux.com> Signed-off-by:
-
David S. Miller authored
Luiz Angelo Daros de Luca says: ==================== net: dsa: realtek: support reset controller and update docs The driver previously supported reset pins using GPIO, but it lacked support for reset controllers. Although a reset method is generally not required, the driver fails to detect the switch if the reset was kept asserted by a previous driver. This series adds support to reset a Realtek switch using a reset controller. It also updates the binding documentation to remove the requirement of a reset method and to add the new reset controller property. It was tested on a TL-WR1043ND v1 router (rtl8366rb via SMI). Signed-off-by:
Luiz Angelo Daros de Luca <luizluca@gmail.com> --- Changes in v5: - Fixed error checking logic when reset controller (de)assert fails - Link to v4: https://lore.kernel.org/r/20240219-realtek-reset-v4-0-858b82a29503@gmail.com Changes in v4: - do not test for priv->reset,priv->reset_ctl - updated commit message - Link to v3: https://lore.kernel.org/r/20240213-realtek-reset-v3-0-37837e574713@gmail.com Changes in v3: - Rebased on the Realtek DSA driver refactoring (08f62716) - Dropped the reset controller example in bindings - Used %pe in error printing - Linked to v2: https://lore.kernel.org/r/20231027190910.27044-1-luizluca@gmail.com/ Changes in v2: - Introduced a dedicated commit for removing the reset-gpios requirement - Placed binding patches before code changes - Removed the 'reset-names' property - Moved the example from the commit message to realtek.yaml - Split the reset function into _assert/_deassert variants - Modified reset functions to return a warning instead of a value - Utilized devm_reset_control_get_optional to prevent failure when the reset control is missing - Used 'true' and 'false' for boolean values - Removed the CONFIG_RESET_CONTROLLER check as stub methods are sufficient when undefined - Linked to v1: https://lore.kernel.org/r/20231024205805.19314-1-luizluca@gmail.com/ ==================== Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Add support for resetting the device using a reset controller, complementing the existing GPIO reset functionality (reset-gpios). Although the reset is optional and the driver performs a soft reset during setup, if the initial reset pin state was asserted, the driver will not detect the device until the reset is deasserted. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by:
-
Luiz Angelo Daros de Luca authored
Realtek switches can use a reset controller instead of reset-gpios. Signed-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Luiz Angelo Daros de Luca authored
The 'reset-gpios' should not be mandatory. although they might be required for some devices if the switch reset was left asserted by a previous driver, such as the bootloader. Signed-off-by:
-
Jones Syue 薛懷宗 authored
Replace macro MAC_ADDRESS_EQUAL() for null_mac_addr checking with inline function__agg_has_partner(). When MAC_ADDRESS_EQUAL() is verifiying aggregator's partner mac addr with null_mac_addr, means that seeing if aggregator has a valid partner or not. Using __agg_has_partner() makes it more clear to understand. In ad_port_selection_logic(), since aggregator->partner_system and port->partner_oper.system has been compared first as a prerequisite, it is safe to replace the upcoming MAC_ADDRESS_EQUAL() for null_mac_addr checking with __agg_has_partner(). Delete null_mac_addr, which is not required anymore in bond_3ad.c, since all references to it are gone. Signed-off-by:
Jones Syue <jonessyue@qnap.com> Reviewed-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://lore.kernel.org/r/SI2PR04MB5097BCA8FF2A2F03D9A5A3EEDC5A2@SI2PR04MB5097.apcprd04.prod.outlook.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "port_prox" variable is a pointer to "struct port_proxy" and this structure ends in a flexible array: struct port_proxy { [...] struct t7xx_port ports[]; }; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the argument "size + size * count" in the devm_kzalloc() function. This way, the code is more readable and safer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:Erick Archer <erick.archer@gmx.com> Reviewed-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Link: https://lore.kernel.org/r/20240224181932.2720-1-erick.archer@gmx.comSigned-off-by:
-
Zhengchao Shao authored
The input parameter 'opt' in rawv6_err() is not used. Therefore, remove it. Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
-
- 27 Feb, 2024 22 commits
-
-
Eric Dumazet authored
This is a followup of commit 234ec0b6 ("netlink: fix potential sleeping issue in mqueue_flush_file"), because vfree_atomic() overhead is unfortunate for medium sized allocations. 1) If the allocation is smaller than PAGE_SIZE, do not bother with vmalloc() at all. Some arches have 64KB PAGE_SIZE, while NLMSG_GOODSIZE is smaller than 8KB. 2) Use kvmalloc(), which might allocate one high order page instead of vmalloc if memory is not too fragmented. Signed-off-by:
-
Alexander Lobakin authored
bnxt_alloc_mem() dereferences ::vnic_info in the variable declaration block, but allocates it much later. As a result, the following crash happens on my setup: BUG: kernel NULL pointer dereference, address: 0000000000000090 fbcon: Taking over console #PF: supervisor write access in kernel mode #PF: error_code (0x0002) - not-present page PGD 12f382067 P4D 0 Oops: 8002 [#1] PREEMPT SMP NOPTI CPU: 47 PID: 2516 Comm: NetworkManager Not tainted 6.8.0-rc5-libeth+ #49 Hardware name: Intel Corporation M50CYP2SBSTD/M58CYP2SBSTD, BIOS SE5C620.86B.01.01.0088.2305172341 05/17/2023 RIP: 0010:bnxt_alloc_mem+0x1609/0x1910 [bnxt_en] Code: 81 c8 48 83 c8 08 31 c9 e9 d7 fe ff ff c7 44 24 Oc 00 00 00 00 49 89 d5 e9 2d fe ff ff 41 89 c6 e9 88 00 00 00 48 8b 44 24 50 <80> 88 90 00 00 00 Od 8b 43 74 a8 02 75 1e f6 83 14 02 00 00 80 74 RSP: 0018:ff3f25580f3432c8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ff15a5cfc45249e0 RCX: 0000002079777000 RDX: ff15a5dfb9767000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ff15a5dfb9777000 R11: ffffff8000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000020 R15: ff15a5cfce34f540 FS: 000007fb9a160500(0000) GS:ff15a5dfbefc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CRO: 0000000080050033 CR2: 0000000000000090 CR3: 0000000109efc00Z CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DRZ: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? page_fault_oops+0x3a6/0x400 ? exc_page_fault+0x7a/0x1b0 ? asm_exc_page_fault+0x26/8x30 ? bnxt_alloc_mem+0x1609/0x1910 [bnxt_en] ? bnxt_alloc_mem+0x1389/8x1918 [bnxt_en] _bnxt_open_nic+0x198/0xa50 [bnxt_en] ? bnxt_hurm_if_change+0x287/0x3d0 [bnxt_en] bnxt_open+0xeb/0x1b0 [bnxt_en] _dev_open+0x12e/0x1f0 _dev_change_flags+0xb0/0x200 dev_change_flags+0x25/0x60 do_setlink+0x463/0x1260 ? sock_def_readable+0x14/0xc0 ? rtnl_getlink+0x4b9/0x590 ? _nla_validate_parse+0x91/0xfa0 rtnl_newlink+0xbac/0xe40 <...> Don't create a variable and dereference the first array member directly since it's used only once in the code. Fixes: ef4ee64e ("bnxt_en: Define BNXT_VNIC_DEFAULT for the default vnic index") Signed-off-by:
Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20240226144911.1297336-1-aleksander.lobakin@intel.comSigned-off-by:
-
Jakub Kicinski authored
Commit 6151ff9c ("selftests: netdevsim: use suitable existing dummy file for flash test") introduced a nice trick to the devlink flashing test. Instead of user having to create a file under /lib/firmware we just pick the first one that already exists. Sadly, in AWS Linux there are no files directly under /lib/firmware, only in subdirectories. Don't limit the search to -maxdepth 1. We can use the %P print format to get the correct path for files inside subdirectories: $ find /lib/firmware -type f -printf '%P\n' | head -1 intel-ucode/06-1a-05 The full path is /lib/firmware/intel-ucode/06-1a-05 This works in GNU find, busybox doesn't have printf at all, so we're not making it worse. Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Jesper Nilsson authored
The MMC IPC interrupt status and interrupt mask registers are of little use as Ethernet statistics, but incrementing counters based on the current interrupt and interrupt mask registers makes them actively misleading. For example, if the interrupt mask is set to 0x08420842, the current code will increment by that amount each iteration, leading to the following sequence of nonsense: mmc_rx_ipc_intr_mask: 969816526 mmc_rx_ipc_intr_mask: 1108361744 These registers have been included in the Ethernet statistics since the first version of MMC back in 2011 (commit 1c901a46). That commit also mentions the MMC interrupts as "something to add later (if actually useful)". If the registers are actually useful, they should probably be part of the Ethernet register dump instead of statistics, but for now, drop the counters for mmc_rx_ipc_intr and mmc_rx_ipc_intr_mask completely. Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Reviewed-by:
-
Ciprian Regus authored
In order to do a clause 22 access to the PHY registers of the ADIN1110, we have to write the MDIO frame to the ADIN1110_MDIOACC register, and then poll the MDIO_TRDONE bit (for a 1) in the same register. The device will set this bit to 1 once the internal MDIO transaction is done. In practice, this bit takes ~50 - 60 us to be set. The first attempt to poll the bit is right after the ADIN1110_MDIOACC register is written, so it will always be read as 0. The next check will only be done after 10 ms, which will result in the MDIO transactions taking a long time to complete. Reduce this polling interval to 100 us. Since this interval is short enough, switch the poll function to readx_poll_timeout_atomic() instead. Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Signed-off-by:
Ciprian Regus <ciprian.regus@analog.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240223162129.154114-1-ciprian.regus@analog.comSigned-off-by:
-
Paolo Abeni authored
Alex Elder says: ==================== net: ipa: don't abort system suspend Currently the IPA code aborts an in-progress system suspend if an IPA interrupt arrives before the suspend completes. There is no need to do that though, because the IPA driver handles a forced suspend correctly, quiescing any hardware activity before finally turning off clocks and interconnects. This series drops the call to pm_wakeup_dev_event() if an IPA SUSPEND interrupt arrives during system suspend. Doing this makes the two remaining IPA power flags unnecessary, and allows some additional code to be cleaned up--and best of all, removed. The result is much simpler (and I'm really glad not to be using these flags any more). The first patch implements the main change. The second and third remove the flags that were used to determine whether to call pm_wakeup_dev_event(). The next two remove a function that becomes a trivial wrapper, and the last one just avoids writing a register unnecessarily. Note that the first two patches will have checkpatch warnings, because checkpatch disagrees with my compiler on what to do when a block contains only a semicolon. I went with what the compiler recommends. clang says: warning: suggest braces around empty body checkpatch: WARNING: braces {} are not necessary for single statement blocks ==================== Link: https://lore.kernel.org/r/20240223133930.582041-1-elder@linaro.orgSigned-off-by: -
Alex Elder authored
In ipa_interrupt_suspend_clear_all(), if the SUSPEND_INFO register read contains no set bits, there's no interrupt condition to clear. Skip the write to the clear register in that case. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Now that ipa_power_suspend_handler() is a trivial wrapper around ipa_interrupt_suspend_clear_all(), we can open-code it in the one place it's used, and get rid of the function. Signed-off-by:
-
Alex Elder authored
The next patch makes ipa_interrupt_suspend_clear_all() static, calling it only within "ipa_interrupt.c". Move its definition higher in the file so no declaration is needed. Signed-off-by:
-
Alex Elder authored
The IPA_POWER_FLAG_RESUMED was originally used to avoid calling pm_wakeup_dev_event() more than once when handling a SUSPEND interrupt. This call is no longer made, so there' no need for the flag, so get rid of it. That leaves no more IPA power flags usefully defined, so just get rid of the bitmap in the IPA power structure and the definition of the ipa_power_flag enumerated type. Signed-off-by:
-
Alex Elder authored
The SYSTEM IPA power flag is set, cleared, and tested. But nothing happens based on its value when tested, so it serves no purpose. Get rid of this flag. Signed-off-by:
-
Alex Elder authored
The IPA interrupt can fire if there is data to be delivered to a GSI channel that is suspended. This condition occurs in three scenarios. First, runtime power management automatically suspends the IPA hardware after half a second of inactivity. This has nothing to do with system suspend, so a SYSTEM IPA power flag is used to avoid calling pm_wakeup_dev_event() when runtime suspended. Second, if the system is suspended, the receipt of an IPA interrupt should trigger a system resume. Configuring the IPA interrupt for wakeup accomplishes this. Finally, if system suspend is underway and the IPA interrupt fires, we currently call pm_wakeup_dev_event() to abort the system suspend. The IPA driver correctly handles quiescing the hardware before suspending it, so there's really no need to abort a suspend in progress in the third case. We can simply quiesce and suspend things, and be done. Incoming data can still wake the system after it's suspended. The IPA interrupt has wakeup mode enabled, so if it fires *after* we've suspended, it will trigger a wakeup (if not disabled via sysfs). Stop calling pm_wakeup_dev_event() to abort a system suspend in progress in ipa_power_suspend_handler(). Signed-off-by:
-
Heiner Kallweit authored
Simplify the function, no functional change intended. - Remove not needed variable unsupp, I think code is even better readable now. - Move setting phydev->eee_enabled out of the if clause - Simplify return value handling Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/442277c7-7431-4542-80b5-1d3d691714d7@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== mptcp: various small improvements This series brings various small improvements to MPTCP and its selftests: Patch 1 prints an error if there are duplicated subtests names. It is important to have unique (sub)tests names in TAP, because some CI environments drop (sub)tests with duplicated names. Patch 2 is a preparation for patches 3 and 4, which check the protocol in tcp_sk() and mptcp_sk() with DEBUG_NET, only in code from net/mptcp/. We recently had the case where an MPTCP socket was wrongly treated as a TCP one, and fuzzers and static checkers never spot the issue. This would prevent such issues in the future. Patches 5 to 7 are some cleanup for the MPTCP selftests. These patches are not supposed to change the behaviour. Patch 8 sets the poll timeout in diag selftest to the same value as the one used in the other selftests. ==================== Link: https://lore.kernel.org/r/20240223-upstream-net-next-20240223-misc-improvements-v1-0-b6c8a10396bd@kernel.orgSigned-off-by:
-
Geliang Tang authored
Even if it is set to 100ms from the beginning with commit df62f2ec ("selftests/mptcp: add diag interface tests"), there is no reason not to have it to 30ms like all the other tests. "diag.sh" is not supposed to be slower than the other ones. To maintain consistency with other scripts, this patch changes it to 30. Signed-off-by:
Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by:
-
Geliang Tang authored
To maintain consistency with other scripts, this patch changes vars 'capture' and 'checksum' as bool vars in mptcp_join. Signed-off-by:
-
Geliang Tang authored
The variables 'large', 'small', 'sout', 'cout', 'capout' and 'size' are used in multiple functions, so they should be clearly defined as global variables at the top of the file. This patch redefines them at the beginning of simult_flows.sh. Signed-off-by:
-
Geliang Tang authored
The variable 'ret' are defined twice in pm_netlink.sh. This patch drops this duplicate one that has been defined from the beginning, with commit eedbc685 ("selftests: add PM netlink functional tests") Signed-off-by:
-
Matthieu Baerts (NGI0) authored
Fuzzers and static checkers might not detect when mptcp_sk() is used with a non mptcp_sock structure. This is similar to the parent commit, where it is easy to use mptcp_sk() with a TCP sock, e.g. with a subflow sk. So a new simple check is done when CONFIG_DEBUG_NET is enabled to tell kernel devs when a non-MPTCP socket is being used as an MPTCP one. 'mptcp_sk()' macro is then defined differently: with an extra WARN to complain when an unexpected socket is being used. Reviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
-
Matthieu Baerts (NGI0) authored
Fuzzers and static checkers might not detect when tcp_sk() is used with a non tcp_sock structure. This kind of mistake already happened a few times with MPTCP: when wrongly using TCP-specific helpers with mptcp_sock pointers. On the other hand, there are many 'tcp_xxx()' helpers that are taking a 'struct sock' pointer as arguments, and some of them are only looking at fields from 'struct sock', and nothing from 'struct tcp_sock'. It is then tempting to use them with a 'struct mptcp_sock'. So a new simple check is done when CONFIG_DEBUG_NET is enabled to tell kernel devs when a non-TCP socket is being used as a TCP one. 'tcp_sk()' macro is then re-defined to add a WARN when an unexpected socket is being used. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
As it would be done when initiating an MPTCP sock. This is not strictly needed for this test, but it will be when a later patch will check if the right protocol is being used when calling mptcp_sk(). Reviewed-by:
-
Matthieu Baerts (NGI0) authored
It is important to have a unique (sub)test name in TAP, because some CI environments drop tests with duplicated name. When adding a new subtest entry, an error message is printed in case of duplicated entries. If there were duplicated entries and if all features were expected to work, the script exits with an error at the end, after having printed all subtests in the TAP format. Thanks to that, the MPTCP CI will catch such issues early. Reviewed-by:
Geliang Tang <geliang@kernel.org> Signed-off-by:
-
