summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-28Merge branch 'tcp-rcv-drop-reasons'David S. Miller
Jason Xing says: ==================== introduce drop reasons for tcp receive path When I was debugging the reason about why the skb should be dropped in syn cookie mode, I found out that this NOT_SPECIFIED reason is too general. Thus I decided to refine it. v10 Link: https://lore.kernel.org/netdev/20240223193321.6549-1-kuniyu@amazon.com/ 1. fix three nit problems (Kuniyuki) 2. add reviewed-by tag (Kuniyuki) v9 Link: https://lore.kernel.org/netdev/20240222113003.67558-1-kerneljasonxing@gmail.com/ 1. nit: remove one unneeded 'else' (David) 2. add reviewed-by tags (Eric, David) v8 Link: https://lore.kernel.org/netdev/20240221025732.68157-1-kerneljasonxing@gmail.com/ 1. refine part of codes in patch [03/10] and patch [10/10] (Eric) 2. squash patch [11/11] in the last version into patch [10/11] (Eric) 3. add reviewed-by tags (Eric) v7 Link: https://lore.kernel.org/all/20240219032838.91723-1-kerneljasonxing@gmail.com/ 1. fix some misspelled problem (Kuniyuki) 2. remove redundant codes in tcp_v6_do_rcv() (Kuniyuki) 3. add reviewed-by tag in patch [02/11] (Kuniyuki) v6 Link: https://lore.kernel.org/all/c987d2c79e4a4655166eb8eafef473384edb37fb.camel@redhat.com/ Link: https://lore.kernel.org/all/CAL+tcoAgSjwsmFnDh_Gs9ZgMi-y5awtVx+4VhJPNRADjo7LLSA@mail.gmail.com/ 1. Take one case into consideration in tcp_v6_do_rcv(), behave like old days, or else it will trigger errors (Paolo). 2. Extend NO_SOCKET reason to consider two more reasons for request socket and child socket. v5: Link: https://lore.kernel.org/netdev/20240213134205.8705-1-kerneljasonxing@gmail.com/ Link: https://lore.kernel.org/netdev/20240213140508.10878-1-kerneljasonxing@gmail.com/ 1. Use SKB_DROP_REASON_IP_OUTNOROUTES instead of introducing a new one (Eric, David) 2. Reuse SKB_DROP_REASON_NOMEM to handle failure of request socket allocation (Eric) 3. Reuse NO_SOCKET instead of introducing COOKIE_NOCHILD 4. avoid duplication of these opt_skb tests/actions (Eric) 5. Use new name (TCP_ABORT_ON_DATA) for readability (David) 6. Reuse IP_OUTNOROUTES instead of INVALID_DST (Eric) --- HISTORY This series is combined with 2 series sent before suggested by Jakub. So I'm going to separately write changelogs for each of them. PATCH 1/11 - 5/11 preivious Link: https://lore.kernel.org/netdev/20240213134205.8705-1-kerneljasonxing@gmail.com/ Summary 1. introduce all the dropreasons we need, [1/11] patch. 2. use new dropreasons in ipv4 cookie check, [2/11],[3/11] patch. 3. use new dropreasons ipv6 cookie check, [4/11],[5/11] patch. v4: Link: https://lore.kernel.org/netdev/20240212172302.3f95e454@kernel.org/ 1. Fix misspelled name in Kdoc as suggested by Jakub. v3: Link: https://lore.kernel.org/all/CANn89iK40SoyJ8fS2U5kp3pDruo=zfQNPL-ppOF+LYaS9z-MVA@mail.gmail.com/ 1. Split that patch into some smaller ones as suggested by Eric. v2: Link: https://lore.kernel.org/all/20240204104601.55760-1-kerneljasonxing@gmail.com/ 1. change the title of 2/2 patch. 2. fix some warnings checkpatch tool showed before. 3. use return value instead of adding more parameters suggested by Eric. PATCH 6/11 - 11/11 previous Link: https://lore.kernel.org/netdev/20240213140508.10878-1-kerneljasonxing@gmail.com/ v4: Link: https://lore.kernel.org/netdev/CANn89iJar+H3XkQ8HpsirH7b-_sbFe9NBUdAAO3pNJK3CKr_bg@mail.gmail.com/ Link: https://lore.kernel.org/netdev/20240213131205.4309-1-kerneljasonxing@gmail.com/ Already got rid of @acceptable in tcp_rcv_state_process(), so I need to remove *TCP_CONNREQNOTACCEPTABLE related codes which I wrote in the v3 series. v3: Link: https://lore.kernel.org/all/CANn89iK40SoyJ8fS2U5kp3pDruo=zfQNPL-ppOF+LYaS9z-MVA@mail.gmail.com/ 1. Split that patch into some smaller ones as suggested by Eric. v2: Link: https://lore.kernel.org/all/20240204104601.55760-1-kerneljasonxing@gmail.com/ 1. change the title of 2/2 patch. 2. fix some warnings checkpatch tool showed before. 3. use return value instead of adding more parameters suggested by Eric. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-28tcp: make dropreason in tcp_child_process() workJason Xing
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>
2024-02-28tcp: make the dropreason really work when calling tcp_rcv_state_process()Jason Xing
Update three callers including both ipv4 and ipv6 and let the dropreason mechanism work in reality. 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>
2024-02-28tcp: add dropreasons in tcp_rcv_state_process()Jason Xing
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 <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>
2024-02-28tcp: add more specific possible drop reasons in tcp_rcv_synsent_state_process()Jason Xing
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 <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>
2024-02-28tcp: introduce dropreasons in receive pathJason Xing
Soon later patches can use these relatively more accurate reasons to recognise and find out the cause. 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>
2024-02-28tcp: use drop reasons in cookie check for ipv6Jason Xing
Like what I did to ipv4 mode, refine this part: adding more drop reasons for better tracing. 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>
2024-02-28tcp: directly drop skb in cookie check for ipv6Jason Xing
Like previous patch does, only moving skb drop logical code to cookie_v6_check() for later refinement. 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>
2024-02-28tcp: use drop reasons in cookie check for ipv4Jason Xing
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 <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>
2024-02-28tcp: directly drop skb in cookie check for ipv4Jason Xing
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 <kernelxing@tencent.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-28tcp: add a dropreason definitions and prepare for cookie checkJason Xing
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: 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>
2024-02-28net: make SK_MEMORY_PCPU_RESERV tunableAdam Li
This patch adds /proc/sys/net/core/mem_pcpu_rsv sysctl file, to make SK_MEMORY_PCPU_RESERV tunable. Commit 3cd3399dd7a8 ("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 <davem@davemloft.net>
2024-02-28crypto: sun8i-ce - Fix use after free in unprepareAndrey Skvortsov
sun8i_ce_cipher_unprepare should be called before crypto_finalize_skcipher_request, because client callbacks may immediately free memory, that isn't needed anymore. But it will be used by unprepare after free. Before removing prepare/unprepare callbacks it was handled by crypto engine in crypto_finalize_request. Usually that results in a pointer dereference problem during a in crypto selftest. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000004716d000 [0000000000000030] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP This problem is detected by KASAN as well. ================================================================== BUG: KASAN: slab-use-after-free in sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] Read of size 8 at addr ffff00000dcdc040 by task 1c15000.crypto-/373 Hardware name: Pine64 PinePhone (1.2) (DT) Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_load8+0x9c/0xc0 sun8i_ce_cipher_do_one+0x6e8/0xf80 [sun8i_ce] crypto_pump_work+0x354/0x620 [crypto_engine] kthread_worker_fn+0x244/0x498 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x38 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x74/0x1d0 alg_test_skcipher+0x90/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Freed by task 379: kasan_save_stack+0x3c/0x68 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x60 __kasan_slab_free+0x100/0x170 slab_free_freelist_hook+0xd4/0x1e8 __kmem_cache_free+0x15c/0x290 kfree+0x74/0x100 kfree_sensitive+0x80/0xb0 alg_test_skcipher+0x12c/0x1f0 alg_test+0x24c/0x830 cryptomgr_test+0x38/0x60 kthread+0x168/0x178 ret_from_fork+0x10/0x20 The buggy address belongs to the object at ffff00000dcdc000 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff00000dcdc000, ffff00000dcdc100) Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Fixes: 4136212ab18e ("crypto: sun8i-ce - Remove prepare/unprepare request") Cc: <stable@vger.kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-02-28Merge branch 'dsa-realtek-reset'David S. Miller
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 (08f627164126) - 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: David S. Miller <davem@davemloft.net>
2024-02-28net: dsa: realtek: support reset controllerLuiz Angelo Daros de Luca
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: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-28dt-bindings: net: dsa: realtek: add reset controllerLuiz Angelo Daros de Luca
Realtek switches can use a reset controller instead of reset-gpios. Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Cc: devicetree@vger.kernel.org Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-28dt-bindings: net: dsa: realtek: reset-gpios is not requiredLuiz Angelo Daros de Luca
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: Luiz Angelo Daros de Luca <luizluca@gmail.com> Cc: devicetree@vger.kernel.org Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-02-28drm/tests/drm_buddy: add alloc_range_bias testMatthew Auld
Sanity check range bias with DRM_BUDDY_RANGE_ALLOCATION. v2: - Be consistent with u32 here. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-6-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-28drm/buddy: check range allocation matches alignmentMatthew Auld
Likely not a big deal for real users, but for consistency we should respect the min_page_size here. Main issue is that bias allocations turns into normal range allocation if the range and size matches exactly, and in the next patch we want to add some unit tests for this part of the api. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-5-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-28drm/buddy: fix range biasMatthew Auld
There is a corner case here where start/end is after/before the block range we are currently checking. If so we need to be sure that splitting the block will eventually give use the block size we need. To do that we should adjust the block range to account for the start/end, and only continue with the split if the size/alignment will fit the requested size. Not doing so can result in leaving split blocks unmerged when it eventually fails. Fixes: afea229fe102 ("drm: improve drm_buddy_alloc function") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: <stable@vger.kernel.org> # v5.18+ Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219121851.25774-4-matthew.auld@intel.com Signed-off-by: Christian König <christian.koenig@amd.com>
2024-02-27Merge tag 'wireless-2024-02-27' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.8-rc7 Few remaining fixes, hopefully the last wireless pull request to v6.8. Two fixes to the stack and two to iwlwifi but no high priority fixes this time. * tag 'wireless-2024-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: mac80211: only call drv_sta_rc_update for uploaded stations MAINTAINERS: wifi: Add N: ath1*k entries to match .yaml files MAINTAINERS: wifi: update Jeff Johnson e-mail address wifi: iwlwifi: mvm: fix the TXF mapping for BZ devices wifi: iwlwifi: mvm: ensure offloading TID queue exists wifi: nl80211: reject iftype change with mesh ID change ==================== Link: https://lore.kernel.org/r/20240227135751.C5EC6C43390@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27uapi: in6: replace temporary label with rfc9486Justin Iurman
Not really a fix per se, but IPV6_TLV_IOAM is still tagged as "TEMPORARY IANA allocation for IOAM", while RFC 9486 is available for some time now. Just update the reference. Fixes: 9ee11f0fff20 ("ipv6: ioam: Data plane support for Pre-allocated Trace") Signed-off-by: Justin Iurman <justin.iurman@uliege.be> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20240226124921.9097-1-justin.iurman@uliege.be Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: lan78xx: fix "softirq work is pending" errorOleksij Rempel
Disable BH around the call to napi_schedule() to avoid following error: NOHZ tick-stop error: local softirq work is pending, handler #08!!! Fixes: ec4c7e12396b ("lan78xx: Introduce NAPI polling support") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20240226110820.2113584-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27bonding: 802.3ad replace MAC_ADDRESS_EQUAL with __agg_has_partnerJones Syue 薛懷宗
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.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: stmmac: Complete meta data only when enabledKurt Kanzenbach
Currently using plain XDP/ZC sockets on stmmac results in a kernel crash: |[ 255.822584] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 |[...] |[ 255.822764] Call trace: |[ 255.822766] stmmac_tx_clean.constprop.0+0x848/0xc38 The program counter indicates xsk_tx_metadata_complete(). It works on compl->tx_timestamp, which is not set by xsk_tx_metadata_to_compl() due to missing meta data. Therefore, call xsk_tx_metadata_complete() only when meta data is actually used. Tested on imx93 without XDP, with XDP and with XDP/ZC. Fixes: 1347b419318d ("net: stmmac: Add Tx HWTS support to XDP ZC") Suggested-by: Serge Semin <fancer.lancer@gmail.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/netdev/87r0h7wg8u.fsf@kurt.kurt.home/ Acked-by: Stanislav Fomichev <sdf@google.com> Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20240222-stmmac_xdp-v2-1-4beee3a037e4@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: usb: dm9601: fix wrong return value in dm9601_mdio_readJavier Carrasco
The MII code does not check the return value of mdio_read (among others), and therefore no error code should be sent. A previous fix to the use of an uninitialized variable propagates negative error codes, that might lead to wrong operations by the MII library. An example of such issues is the use of mii_nway_restart by the dm9601 driver. The mii_nway_restart function does not check the value returned by mdio_read, which in this case might be a negative number which could contain the exact bit the function checks (BMCR_ANENABLE = 0x1000). Return zero in case of error, as it is common practice in users of mdio_read to avoid wrong uses of the return value. Fixes: 8f8abb863fa5 ("net: usb: dm9601: fix uninitialized variable use in dm9601_mdio_read") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Peter Korsgaard <peter@korsgaard.com> Link: https://lore.kernel.org/r/20240225-dm9601_ret_err-v1-1-02c1d959ea59@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27net: wwan: t7xx: Prefer struct_size over open coded arithmeticErick Archer
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.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27ipv6: raw: remove useless input parameter in rawv6_errZhengchao Shao
The input parameter 'opt' in rawv6_err() is not used. Therefore, remove it. Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240224084121.2479603-1-shaozhengchao@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27Merge tag 'lsm-pr-20240227' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm Pull lsm fixes from Paul Moore: "Two small patches, one for AppArmor and one for SELinux, to fix potential uninitialized variable problems in the new LSM syscalls we added during the v6.8 merge window. We haven't been able to get a response from John on the AppArmor patch, but considering both the importance of the patch and it's rather simple nature it seems like a good idea to get this merged sooner rather than later. I'm sure John is just taking some much needed vacation; if we need to revise this when he gets back to his email we can" * tag 'lsm-pr-20240227' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm: apparmor: fix lsm_get_self_attr() selinux: fix lsm_get_self_attr()
2024-02-27Merge tag 'mm-hotfixes-stable-2024-02-27-14-52' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "Six hotfixes. Three are cc:stable and the remainder address post-6.7 issues or aren't considered appropriate for backporting" * tag 'mm-hotfixes-stable-2024-02-27-14-52' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/debug_vm_pgtable: fix BUG_ON with pud advanced test mm: cachestat: fix folio read-after-free in cache walk MAINTAINERS: add memory mapping entry with reviewers mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index kasan: revert eviction of stack traces in generic mode stackdepot: use variable size records for non-evictable entries
2024-02-27Merge branch 'bpf-arm64-support-exceptions'Alexei Starovoitov
Puranjay Mohan says: ==================== bpf, arm64: Support Exceptions Changes in V2->V3: V2: https://lore.kernel.org/all/20230917000045.56377-1-puranjay12@gmail.com/ - Use unwinder from stacktrace.c rather than open coding the unwind logic. - Fix a bug in the prologue related to BPF_FP (Xu Kuohai) Changes in V1->V2: V1: https://lore.kernel.org/all/20230912233942.6734-1-puranjay12@gmail.com/ - Remove exceptions from DENYLIST.aarch64 as they are supported now. The base support for exceptions was merged with [1] and it was enabled for x86-64. This patch set enables the support on ARM64, all sefltests are passing: # ./test_progs -a exceptions #74/1 exceptions/exception_throw_always_1:OK #74/2 exceptions/exception_throw_always_2:OK #74/3 exceptions/exception_throw_unwind_1:OK #74/4 exceptions/exception_throw_unwind_2:OK #74/5 exceptions/exception_throw_default:OK #74/6 exceptions/exception_throw_default_value:OK #74/7 exceptions/exception_tail_call:OK #74/8 exceptions/exception_ext:OK #74/9 exceptions/exception_ext_mod_cb_runtime:OK #74/10 exceptions/exception_throw_subprog:OK #74/11 exceptions/exception_assert_nz_gfunc:OK #74/12 exceptions/exception_assert_zero_gfunc:OK #74/13 exceptions/exception_assert_neg_gfunc:OK #74/14 exceptions/exception_assert_pos_gfunc:OK #74/15 exceptions/exception_assert_negeq_gfunc:OK #74/16 exceptions/exception_assert_poseq_gfunc:OK #74/17 exceptions/exception_assert_nz_gfunc_with:OK #74/18 exceptions/exception_assert_zero_gfunc_with:OK #74/19 exceptions/exception_assert_neg_gfunc_with:OK #74/20 exceptions/exception_assert_pos_gfunc_with:OK #74/21 exceptions/exception_assert_negeq_gfunc_with:OK #74/22 exceptions/exception_assert_poseq_gfunc_with:OK #74/23 exceptions/exception_bad_assert_nz_gfunc:OK #74/24 exceptions/exception_bad_assert_zero_gfunc:OK #74/25 exceptions/exception_bad_assert_neg_gfunc:OK #74/26 exceptions/exception_bad_assert_pos_gfunc:OK #74/27 exceptions/exception_bad_assert_negeq_gfunc:OK #74/28 exceptions/exception_bad_assert_poseq_gfunc:OK #74/29 exceptions/exception_bad_assert_nz_gfunc_with:OK #74/30 exceptions/exception_bad_assert_zero_gfunc_with:OK #74/31 exceptions/exception_bad_assert_neg_gfunc_with:OK #74/32 exceptions/exception_bad_assert_pos_gfunc_with:OK #74/33 exceptions/exception_bad_assert_negeq_gfunc_with:OK #74/34 exceptions/exception_bad_assert_poseq_gfunc_with:OK #74/35 exceptions/exception_assert_range:OK #74/36 exceptions/exception_assert_range_with:OK #74/37 exceptions/exception_bad_assert_range:OK #74/38 exceptions/exception_bad_assert_range_with:OK #74/39 exceptions/non-throwing fentry -> exception_cb:OK #74/40 exceptions/throwing fentry -> exception_cb:OK #74/41 exceptions/non-throwing fexit -> exception_cb:OK #74/42 exceptions/throwing fexit -> exception_cb:OK #74/43 exceptions/throwing extension (with custom cb) -> exception_cb:OK #74/44 exceptions/throwing extension -> global func in exception_cb:OK #74/45 exceptions/exception_ext_mod_cb_runtime:OK #74/46 exceptions/throwing extension (with custom cb) -> global func in exception_cb:OK #74/47 exceptions/exception_ext:OK #74/48 exceptions/non-throwing fentry -> non-throwing subprog:OK #74/49 exceptions/throwing fentry -> non-throwing subprog:OK #74/50 exceptions/non-throwing fentry -> throwing subprog:OK #74/51 exceptions/throwing fentry -> throwing subprog:OK #74/52 exceptions/non-throwing fexit -> non-throwing subprog:OK #74/53 exceptions/throwing fexit -> non-throwing subprog:OK #74/54 exceptions/non-throwing fexit -> throwing subprog:OK #74/55 exceptions/throwing fexit -> throwing subprog:OK #74/56 exceptions/non-throwing fmod_ret -> non-throwing subprog:OK #74/57 exceptions/non-throwing fmod_ret -> non-throwing global subprog:OK #74/58 exceptions/non-throwing extension -> non-throwing subprog:OK #74/59 exceptions/non-throwing extension -> throwing subprog:OK #74/60 exceptions/non-throwing extension -> non-throwing subprog:OK #74/61 exceptions/non-throwing extension -> throwing global subprog:OK #74/62 exceptions/throwing extension -> throwing global subprog:OK #74/63 exceptions/throwing extension -> non-throwing global subprog:OK #74/64 exceptions/non-throwing extension -> main subprog:OK #74/65 exceptions/throwing extension -> main subprog:OK #74/66 exceptions/reject_exception_cb_type_1:OK #74/67 exceptions/reject_exception_cb_type_2:OK #74/68 exceptions/reject_exception_cb_type_3:OK #74/69 exceptions/reject_exception_cb_type_4:OK #74/70 exceptions/reject_async_callback_throw:OK #74/71 exceptions/reject_with_lock:OK #74/72 exceptions/reject_subprog_with_lock:OK #74/73 exceptions/reject_with_rcu_read_lock:OK #74/74 exceptions/reject_subprog_with_rcu_read_lock:OK #74/75 exceptions/reject_with_rbtree_add_throw:OK #74/76 exceptions/reject_with_reference:OK #74/77 exceptions/reject_with_cb_reference:OK #74/78 exceptions/reject_with_cb:OK #74/79 exceptions/reject_with_subprog_reference:OK #74/80 exceptions/reject_throwing_exception_cb:OK #74/81 exceptions/reject_exception_cb_call_global_func:OK #74/82 exceptions/reject_exception_cb_call_static_func:OK #74/83 exceptions/reject_multiple_exception_cb:OK #74/84 exceptions/reject_exception_throw_cb:OK #74/85 exceptions/reject_exception_throw_cb_diff:OK #74/86 exceptions/reject_set_exception_cb_bad_ret1:OK #74/87 exceptions/reject_set_exception_cb_bad_ret2:OK #74/88 exceptions/check_assert_eq_int_min:OK #74/89 exceptions/check_assert_eq_int_max:OK #74/90 exceptions/check_assert_eq_zero:OK #74/91 exceptions/check_assert_eq_llong_min:OK #74/92 exceptions/check_assert_eq_llong_max:OK #74/93 exceptions/check_assert_lt_pos:OK #74/94 exceptions/check_assert_lt_zero:OK #74/95 exceptions/check_assert_lt_neg:OK #74/96 exceptions/check_assert_le_pos:OK #74/97 exceptions/check_assert_le_zero:OK #74/98 exceptions/check_assert_le_neg:OK #74/99 exceptions/check_assert_gt_pos:OK #74/100 exceptions/check_assert_gt_zero:OK #74/101 exceptions/check_assert_gt_neg:OK #74/102 exceptions/check_assert_ge_pos:OK #74/103 exceptions/check_assert_ge_zero:OK #74/104 exceptions/check_assert_ge_neg:OK #74/105 exceptions/check_assert_range_s64:OK #74/106 exceptions/check_assert_range_u64:OK #74/107 exceptions/check_assert_single_range_s64:OK #74/108 exceptions/check_assert_single_range_u64:OK #74/109 exceptions/check_assert_generic:OK #74/110 exceptions/check_assert_with_return:OK #74 exceptions:OK Summary: 1/110 PASSED, 0 SKIPPED, 0 FAILED [1] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?h=for-next&id=ec6f1b4db95b7eedb3fe85f4f14e08fa0e9281c3 ==================== Link: https://lore.kernel.org/r/20240201125225.72796-1-puranjay12@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-02-27bpf, arm64: support exceptionsPuranjay Mohan
The prologue generation code has been modified to make the callback program use the stack of the program marked as exception boundary where callee-saved registers are already pushed. As the bpf_throw function never returns, if it clobbers any callee-saved registers, they would remain clobbered. So, the prologue of the exception-boundary program is modified to push R23 and R24 as well, which the callback will then recover in its epilogue. The Procedure Call Standard for the Arm 64-bit Architecture[1] states that registers r19 to r28 should be saved by the callee. BPF programs on ARM64 already save all callee-saved registers except r23 and r24. This patch adds an instruction in prologue of the program to save these two registers and another instruction in the epilogue to recover them. These extra instructions are only added if bpf_throw() is used. Otherwise the emitted prologue/epilogue remains unchanged. [1] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Link: https://lore.kernel.org/r/20240201125225.72796-3-puranjay12@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-02-27arm64: stacktrace: Implement arch_bpf_stack_walk() for the BPF JITPuranjay Mohan
This will be used by bpf_throw() to unwind till the program marked as exception boundary and run the callback with the stack of the main program. This is required for supporting BPF exceptions on ARM64. Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20240201125225.72796-2-puranjay12@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-02-27Merge patch series "drivers: perf: fix crash with the legacy riscv driver"Palmer Dabbelt
Vadim Shakirov <vadim.shakirov@syntacore.com> says: This series fix crash with the legacy riscv driver when configs: CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n and you try to perf record * b4-shazam-lts: drivers: perf: ctr_get_width function for legacy is not defined drivers: perf: added capabilities for legacy PMU Link: https://lore.kernel.org/r/20240227170002.188671-1-vadim.shakirov@syntacore.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-27drivers: perf: ctr_get_width function for legacy is not definedVadim Shakirov
With parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n linux kernel crashes when you try perf record: $ perf record ls [ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 46.750199] Oops [#1] [ 46.750342] Modules linked in: [ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2 [ 46.750906] Hardware name: riscv-virtio,qemu (DT) [ 46.751184] epc : 0x0 [ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e [ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0 [ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0 [ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930 [ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000 [ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004 [ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2 [ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000 [ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078 [ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001 [ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff [ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30 [ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c [ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec. [ 46.754939] ---[ end trace 0000000000000000 ]--- [ 46.755131] note: perf-exec[107] exited with irqs disabled [ 46.755546] note: perf-exec[107] exited with preempt_count 4 This happens because in the legacy case the ctr_get_width function was not defined, but it is used in arch_perf_update_userpage. Also remove extra check in riscv_pmu_ctr_get_width_mask Signed-off-by: Vadim Shakirov <vadim.shakirov@syntacore.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Fixes: cc4c07c89aad ("drivers: perf: Implement perf event mmap support in the SBI backend") Link: https://lore.kernel.org/r/20240227170002.188671-3-vadim.shakirov@syntacore.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-27drivers: perf: added capabilities for legacy PMUVadim Shakirov
Added the PERF_PMU_CAP_NO_INTERRUPT flag because the legacy pmu driver does not provide sampling capabilities Added the PERF_PMU_CAP_NO_EXCLUDE flag because the legacy pmu driver does not provide the ability to disable counter incrementation in different privilege modes Suggested-by: Atish Patra <atishp@rivosinc.com> Signed-off-by: Vadim Shakirov <vadim.shakirov@syntacore.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Fixes: 9b3e150e310e ("RISC-V: Add a simple platform driver for RISC-V legacy perf") Link: https://lore.kernel.org/r/20240227170002.188671-2-vadim.shakirov@syntacore.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-02-27Revert "drm/amd/pm: resolve reboot exception for si oland"Alex Deucher
This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. This causes hangs on SI when DC is enabled and errors on driver reboot and power off cycles. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3216 Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2755 Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-02-27drm/amdgpu: Enable gpu reset for S3 abort cases on Raven seriesPrike Liang
Currently, GPU resets can now be performed successfully on the Raven series. While GPU reset is required for the S3 suspend abort case. So now can enable gpu reset for S3 abort cases on the Raven series. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-27drm/amdgpu/pm: Fix the power1_min_cap valueMa Jun
It's unreasonable to use 0 as the power1_min_cap when OD is disabled. So, use the same lower limit as the value used when OD is enabled. Fixes: 1958946858a6 ("drm/amd/pm: Support for getting power1_cap_min value") Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2024-02-27drm/amd/display: Prevent potential buffer overflow in map_hw_resourcesSrinivasan Shanmugam
Adds a check in the map_hw_resources function to prevent a potential buffer overflow. The function was accessing arrays using an index that could potentially be greater than the size of the arrays, leading to a buffer overflow. Adds a check to ensure that the index is within the bounds of the arrays. If the index is out of bounds, an error message is printed and break it will continue execution with just ignoring extra data early to prevent the buffer overflow. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:79 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_stream_id' 6 <= 7 drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml2_wrapper.c:81 map_hw_resources() error: buffer overflow 'dml2->v20.scratch.dml_to_dc_pipe_mapping.disp_cfg_to_plane_id' 6 <= 7 Fixes: 7966f319c66d ("drm/amd/display: Introduce DML2") Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Qingqing Zhuo <Qingqing.Zhuo@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Suggested-by: Roman Li <roman.li@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2024-02-27netlink: use kvmalloc() in netlink_alloc_large_skb()Eric Dumazet
This is a followup of commit 234ec0b6034b ("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: Eric Dumazet <edumazet@google.com> Reviewed-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20240224090630.605917-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27bnxt_en: fix accessing vnic_info before allocating itAlexander Lobakin
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: ef4ee64e9990 ("bnxt_en: Define BNXT_VNIC_DEFAULT for the default vnic index") Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20240226144911.1297336-1-aleksander.lobakin@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-02-27Merge tag 'mt76-for-kvalo-2024-02-22' of https://github.com/nbd168/wirelessKalle Valo
mt76 patches for 6.9 * fixes * support for newer chips in the mt7915 driver * mt7996 improvements * page pool performance improvement
2024-02-27wifi: brcmfmac: do not pass hidden SSID attribute as value directlyAlexey Berezhok
In brcmf_cfg80211_start_ap() do not assume that NL80211_HIDDEN_SSID_NOT_IN_USE is zero but prefer an explicit check instead. Use local variable 'closednet' to pass in function call and use for error message. Compile tested only. Addition for the commit f20073f50dfd1 ("wifi: brcmfmac: do not cast hidden SSID attribute value to boolean"). Signed-off-by: Alexey Berezhok <a@bayrepo.ru> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222122923.46691-1-a@bayrepo.ru
2024-02-27wifi: rtw89: pci: implement PCI CLK/ASPM/L1SS for WiFi 7 chipsChin-Yen Lee
PCI CLK/ASPM/L1SS is power management mechanism used to reduce power consumption of PCI chip. The registers for setting of these features in WiFi 7 Chip are different from WiFi 6 chip, so separate them in generation information. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-4-pkshih@realtek.com
2024-02-27wifi: rtw89: Update EHT PHY beamforming capabilityKuan-Chung Chen
Adjust beamforming capabilities to accurately reflect the supported EHT features by WiFi 7 chip 8922A. It includes 1) Unset EHT CQI feedback and 16-subcarrier grouping. 2) Correct Beamformee SS value. 3) Enable partial and full bandwidth SU/MU feedback. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-3-pkshih@realtek.com
2024-02-27wifi: rtw89: advertise missing extended scan featureKuan-Chung Chen
Add support for random serial number in probe request and configure channel dwell time. Advertise corresponding feature flag NL80211_EXT_FEATURE_SCAN_RANDOM_SN and NL80211_EXT_FEATURE_SET_SCAN_DWELL. Use the scan request duration as channel dwell time when it is non-zero, otherwise use the default value. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240222064258.59782-2-pkshih@realtek.com
2024-02-27wifi: brcmfmac: fweh: Fix boot crash on Raspberry Pi 4Gustavo A. R. Silva
Fix boot crash on Raspberry Pi by moving the update to `event->datalen` before data is copied into flexible-array member `data` via `memcpy()`. Flexible-array member `data` was annotated with `__counted_by(datalen)` in commit 62d19b358088 ("wifi: brcmfmac: fweh: Add __counted_by for struct brcmf_fweh_queue_item and use struct_size()"). The intention of this is to gain visibility into the size of `data` at run-time through its _counter_ (in this case `datalen`), and with this have its accesses bounds-checked at run-time via CONFIG_FORTIFY_SOURCE and CONFIG_UBSAN_BOUNDS. To effectively accomplish the above, we shall update the counter (`datalen`), before the first access to the flexible array (`data`), which was also done in the mentioned commit. However, commit edec42821911 ("wifi: brcmfmac: allow per-vendor event handling") inadvertently caused a buffer overflow, detected by FORTIFY_SOURCE. It moved the `event->datalen = datalen;` update to after the first `data` access, at which point `event->datalen` was not yet updated from zero (after calling `kzalloc()`), leading to the overflow issue. This fix repositions the `event->datalen = datalen;` update before accessing `data`, restoring the intended buffer overflow protection. :) Fixes: edec42821911 ("wifi: brcmfmac: allow per-vendor event handling") Reported-by: Nathan Chancellor <nathan@kernel.org> Closes: https://gist.github.com/nathanchance/e22f681f3bfc467f15cdf6605021aaa6 Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/Zc+3PFCUvLoVlpg8@neat
2024-02-27selftests: netdevsim: be less selective for FW for the devlink testJakub Kicinski
Commit 6151ff9c7521 ("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: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240224050658.930272-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-02-27veth: try harder when allocating queue memoryJakub Kicinski
struct veth_rq is pretty large, 832B total without debug options enabled. Since commit under Fixes we try to pre-allocate enough queues for every possible CPU. Miao Wang reports that this may lead to order-5 allocations which will fail in production. Let the allocation fallback to vmalloc() and try harder. These are the same flags we pass to netdev queue allocation. Reported-and-tested-by: Miao Wang <shankerwangmiao@gmail.com> Fixes: 9d3684c24a52 ("veth: create by default nr_possible_cpus queues") Link: https://lore.kernel.org/all/5F52CAE2-2FB7-4712-95F1-3312FBBFA8DD@gmail.com/ Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20240223235908.693010-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>