aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04Merge branch '100GbE' of ↵Jakub Kicinski6-161/+106
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== ice: fix synchronization between .ndo_bpf() and reset Larysa Zaremba says: PF reset can be triggered asynchronously, by tx_timeout or by a user. With some unfortunate timings both ice_vsi_rebuild() and .ndo_bpf will try to access and modify XDP rings at the same time, causing system crash. The first patch factors out rtnl-locked code from VSI rebuild code to avoid deadlock. The following changes lock rebuild and .ndo_bpf() critical sections with an internal mutex as well and provide complementary fixes. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: do not bring the VSI up, if it was down before the XDP setup ice: remove ICE_CFG_BUSY locking from AF_XDP code ice: check ICE_VSI_DOWN under rtnl_lock when preparing for reset ice: check for XDP rings instead of bpf program when unconfiguring ice: protect XDP configuration with a mutex ice: move netif_queue_set_napi to rtnl-protected sections ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04Merge tag 'wireless-next-2024-09-04' of ↵Jakub Kicinski202-1578/+6223
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== pull-request: wireless-next-2024-09-04 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. ==================== Conflicts: drivers/net/wireless/ath/ath12k/hw.c 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850") 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only") https://lore.kernel.org/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04Merge tag 'wireless-2024-09-04' of ↵Jakub Kicinski10-148/+50
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Kalle Valo says: ==================== wireless fixes for v6.11 Hopefully final fixes for v6.11 and this time only fixes to ath11k driver. We need to revert hibernation support due to reported regressions and we have a fix for kernel crash introduced in v6.11-rc1. * tag 'wireless-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: MAINTAINERS: wifi: cw1200: add net-cw1200.h Revert "wifi: ath11k: support hibernation" Revert "wifi: ath11k: restore country code during resume" wifi: ath11k: fix NULL pointer dereference in ath11k_mac_get_eirp_power() ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04net: cadence: macb: Enable software IRQ coalescing by defaultSean Anderson1-0/+2
This NIC doesn't have hardware IRQ coalescing. Under high load, interrupts can adversely affect performance. To mitigate this, enable software IRQ coalescing by default. On my system this increases receive throughput with iperf3 from 853 MBit/sec to 934 MBit/s, decreases interrupts from 69489/sec to 2016/sec, and decreases CPU utilization from 27% (4x Cortex-A53) to 14%. Latency is not affected (as far as I can tell). Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04net: xilinx: axienet: Fix race in axienet_stopSean Anderson2-0/+11
axienet_dma_err_handler can race with axienet_stop in the following manner: CPU 1 CPU 2 ====================== ================== axienet_stop() napi_disable() axienet_dma_stop() axienet_dma_err_handler() napi_disable() axienet_dma_stop() axienet_dma_start() napi_enable() cancel_work_sync() free_irq() Fix this by setting a flag in axienet_stop telling axienet_dma_err_handler not to bother doing anything. I chose not to use disable_work_sync to allow for easier backporting. Signed-off-by: Sean Anderson <[email protected]> Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04net: phy: Check for read errors in SIOCGMIIREGNiklas Söderlund1-6/+11
When reading registers from the PHY using the SIOCGMIIREG IOCTL any errors returned from either mdiobus_read() or mdiobus_c45_read() are ignored, and parts of the returned error is passed as the register value back to user-space. For example, if mdiobus_c45_read() is used with a bus that do not implement the read_c45() callback -EOPNOTSUPP is returned. This is however directly stored in mii_data->val_out and returned as the registers content. As val_out is a u16 the error code is truncated and returned as a plausible register value. Fix this by first checking the return value for errors before returning it as the register content. Before this patch, # phytool read eth0/0:1/0 0xffa1 After this change, $ phytool read eth0/0:1/0 error: phy_read (-95) Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Yoshihiro Shimoda <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04pds_core: Remove redundant null pointer checksLi Zetao1-4/+4
Since the debugfs_create_dir() never returns a null pointer, checking the return value for a null pointer is redundant, and using IS_ERR is safe enough. Signed-off-by: Li Zetao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ionic: Remove redundant null pointer checks in ionic_debugfs_add_qcq()Li Zetao1-1/+1
Since the debugfs_create_dir() never returns a null pointer, checking the return value for a null pointer is redundant, and using IS_ERR is safe enough. Signed-off-by: Li Zetao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04Merge branch 'unmask-upper-dscp-bits-part-3'Jakub Kicinski4-6/+9
Ido Schimmel says: ==================== Unmask upper DSCP bits - part 3 tl;dr - This patchset continues to unmask the upper DSCP bits in the IPv4 flow key in preparation for allowing IPv4 FIB rules to match on DSCP. No functional changes are expected. The TOS field in the IPv4 flow key ('flowi4_tos') is used during FIB lookup to match against the TOS selector in FIB rules and routes. It is currently impossible for user space to configure FIB rules that match on the DSCP value as the upper DSCP bits are either masked in the various call sites that initialize the IPv4 flow key or along the path to the FIB core. In preparation for adding a DSCP selector to IPv4 and IPv6 FIB rules, we need to make sure the entire DSCP value is present in the IPv4 flow key. This patchset continues to unmask the upper DSCP bits, but this time in the output route path, specifically in the callers of ip_route_output_ports(). The next patchset (last) will handle the callers of ip_route_output_key(). Split from this patchset to avoid going over the 15 patches limit. No functional changes are expected as commit 1fa3314c14c6 ("ipv4: Centralize TOS matching") moved the masking of the upper DSCP bits to the core where 'flowi4_tos' is matched against the TOS selector. ==================== Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ipv6: sit: Unmask upper DSCP bits in ipip6_tunnel_bind_dev()Ido Schimmel1-1/+1
Unmask the upper DSCP bits when calling ip_route_output_ports() so that in the future it could perform the FIB lookup according to the full DSCP value. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ip6_tunnel: Unmask upper DSCP bits in ip4ip6_err()Ido Schimmel1-2/+5
Unmask the upper DSCP bits when calling ip_route_output_ports() so that in the future it could perform the FIB lookup according to the full DSCP value. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ipv4: ipmr: Unmask upper DSCP bits in ipmr_queue_xmit()Ido Schimmel1-2/+2
Unmask the upper DSCP bits when calling ip_route_output_ports() so that in the future it could perform the FIB lookup according to the full DSCP value. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ipv4: Unmask upper DSCP bits in __ip_queue_xmit()Ido Schimmel1-1/+1
The function is passed the full DS field in its 'tos' argument by its two callers. It then masks the upper DSCP bits using RT_TOS() when passing it to ip_route_output_ports(). Unmask the upper DSCP bits when passing 'tos' to ip_route_output_ports() so that in the future it could perform the FIB lookup according to the full DSCP value. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04selftests: net: convert comma to semicolonChen Ni1-3/+3
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04ipv4: Fix user space build failure due to header changeIdo Schimmel2-2/+1
RT_TOS() from include/uapi/linux/in_route.h is defined using IPTOS_TOS_MASK from include/uapi/linux/ip.h. This is problematic for files such as include/net/ip_fib.h that want to use RT_TOS() as without including both header files kernel compilation fails: In file included from ./include/net/ip_fib.h:25, from ./include/net/route.h:27, from ./include/net/lwtunnel.h:9, from net/core/dst.c:24: ./include/net/ip_fib.h: In function ‘fib_dscp_masked_match’: ./include/uapi/linux/in_route.h:31:32: error: ‘IPTOS_TOS_MASK’ undeclared (first use in this function) 31 | #define RT_TOS(tos) ((tos)&IPTOS_TOS_MASK) | ^~~~~~~~~~~~~~ ./include/net/ip_fib.h:440:45: note: in expansion of macro ‘RT_TOS’ 440 | return dscp == inet_dsfield_to_dscp(RT_TOS(fl4->flowi4_tos)); Therefore, cited commit changed linux/in_route.h to include linux/ip.h. However, as reported by David, this breaks iproute2 compilation due overlapping definitions between linux/ip.h and /usr/include/netinet/ip.h: In file included from ../include/uapi/linux/in_route.h:5, from iproute.c:19: ../include/uapi/linux/ip.h:25:9: warning: "IPTOS_TOS" redefined 25 | #define IPTOS_TOS(tos) ((tos)&IPTOS_TOS_MASK) | ^~~~~~~~~ In file included from iproute.c:17: /usr/include/netinet/ip.h:222:9: note: this is the location of the previous definition 222 | #define IPTOS_TOS(tos) ((tos) & IPTOS_TOS_MASK) Fix by changing include/net/ip_fib.h to include linux/ip.h. Note that usage of RT_TOS() should not spread further in the kernel due to recent work in this area. Fixes: 1fa3314c14c6 ("ipv4: Centralize TOS matching") Reported-by: David Ahern <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04l2tp: remove unneeded null check in l2tp_v2_session_get_nextJames Chapman1-1/+1
Commit aa92c1cec92b ("l2tp: add tunnel/session get_next helpers") uses idr_get_next APIs to iterate over l2tp session IDR lists. Sessions in l2tp_v2_session_idr always have a non-null session->tunnel pointer since l2tp_session_register sets it before inserting the session into the IDR. Therefore the null check on session->tunnel in l2tp_v2_session_get_next is redundant and can be removed. Removing the check avoids a warning from lkp. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ CC: Dan Carpenter <[email protected]> Signed-off-by: James Chapman <[email protected]> Acked-by: Tom Parkin <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04net: bridge: br_fdb_external_learn_add(): always set EXT_LEARNJonas Gorski1-4/+2
When userspace wants to take over a fdb entry by setting it as EXTERN_LEARNED, we set both flags BR_FDB_ADDED_BY_EXT_LEARN and BR_FDB_ADDED_BY_USER in br_fdb_external_learn_add(). If the bridge updates the entry later because its port changed, we clear the BR_FDB_ADDED_BY_EXT_LEARN flag, but leave the BR_FDB_ADDED_BY_USER flag set. If userspace then wants to take over the entry again, br_fdb_external_learn_add() sees that BR_FDB_ADDED_BY_USER and skips setting the BR_FDB_ADDED_BY_EXT_LEARN flags, thus silently ignores the update. Fix this by always allowing to set BR_FDB_ADDED_BY_EXT_LEARN regardless if this was a user fdb entry or not. Fixes: 710ae7287737 ("net: bridge: Mark FDB entries that were added by user as such") Signed-off-by: Jonas Gorski <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04r8152: fix the firmware doesn't workHayes Wang1-4/+13
generic_ocp_write() asks the parameter "size" must be 4 bytes align. Therefore, write the bp would fail, if the mac->bp_num is odd. Align the size to 4 for fixing it. The way may write an extra bp, but the rtl8152_is_fw_mac_ok() makes sure the value must be 0 for the bp whose index is more than mac->bp_num. That is, there is no influence for the firmware. Besides, I check the return value of generic_ocp_write() to make sure everything is correct. Fixes: e5c266a61186 ("r8152: set bp in bulk") Signed-off-by: Hayes Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04fou: Fix null-ptr-deref in GRO.Kuniyuki Iwashima1-5/+24
We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0] The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou. When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period. So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL. Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers. [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93daee87dc00 RDI: ffff93daee87dc64 RBP: 0000000000000001 R08: ffffffffb5e7b6c0 R09: 0000000000000044 R10: ffff93daee831b04 R11: 00000000000001cd R12: 0000000000000001 R13: ffffffffb5e7b740 R14: 0000000000000001 R15: 0000000000000000 ? sched_clock_cpu (kernel/sched/clock.c:371) acpi_idle_enter (drivers/acpi/processor_idle.c:712 (discriminator 3)) cpuidle_enter_state (drivers/cpuidle/cpuidle.c:237) cpuidle_enter (drivers/cpuidle/cpuidle.c:353) cpuidle_idle_call (kernel/sched/idle.c:158 kernel/sched/idle.c:239) do_idle (kernel/sched/idle.c:302) cpu_startup_entry (kernel/sched/idle.c:395 (discriminator 1)) start_kernel (init/main.c:1048) secondary_startup_64_no_verify (arch/x86/kernel/head_64.S:310) Modules linked in: udp_diag tcp_diag inet_diag nft_nat ipip tunnel4 dummy fou ip_tunnel nft_masq nft_chain_nat nf_nat wireguard nft_ct curve25519_x86_64 libcurve25519_generic nf_conntrack libchacha20poly1305 nf_defrag_ipv6 nf_defrag_ipv4 nft_objref chacha_x86_64 nft_counter nf_tables nfnetlink poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper mousedev psmouse button ena ptp pps_core crc32c_intel CR2: 0000000000000008 Fixes: d92283e338f6 ("fou: change to use UDP socket GRO") Reported-by: Alphonse Kurian <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04net: mana: Improve mana_set_channels() in low mem conditionsShradha Gupta3-17/+19
The mana_set_channels() function requires detaching the mana driver and reattaching it with changed channel values. During this operation if the system is low on memory, the reattach might fail, causing the network device being down. To avoid this we pre-allocate buffers at the beginning of set operation, to prevent complete network loss Signed-off-by: Shradha Gupta <[email protected]> Reviewed-by: Gerhard Engleder <[email protected]> Reviewed-by: Haiyang Zhang <[email protected]> Link: https://patch.msgid.link/1725248734-21760-1-git-send-email-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04bareudp: Fix device stats updates.Guillaume Nault1-11/+11
Bareudp devices update their stats concurrently. Therefore they need proper atomic increments. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by: Guillaume Nault <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://patch.msgid.link/04b7b9d0b480158eb3ab4366ec80aa2ab7e41fcb.1725031794.git.gnault@redhat.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-09-04Merge tag 'bcachefs-2024-09-04' of git://evilpiepirate.org/bcachefsLinus Torvalds4-3/+10
Pull bcachefs fixes from Kent Overstreet: - Fix a typo in the rebalance accounting changes - BCH_SB_MEMBER_INVALID: small on disk format feature which will be needed for full erasure coding support; this is only the minimum so that 6.11 can handle future versions without barfing. * tag 'bcachefs-2024-09-04' of git://evilpiepirate.org/bcachefs: bcachefs: BCH_SB_MEMBER_INVALID bcachefs: fix rebalance accounting
2024-09-04Merge tag 'perf-tools-fixes-for-v6.11-2024-09-04' of ↵Linus Torvalds4-5/+11
git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools Pull perf tools fixes from Namhyung Kim: "A number of small fixes for the late cycle: - Two more build fixes on 32-bit archs - Fixed a segfault during perf test - Fixed spinlock/rwlock accounting bug in perf lock contention" * tag 'perf-tools-fixes-for-v6.11-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: perf daemon: Fix the build on more 32-bit architectures perf python: include "util/sample.h" perf lock contention: Fix spinlock and rwlock accounting perf test pmu: Set uninitialized PMU alias to null
2024-09-04Merge tag 'hwmon-for-v6.11-rc7' of ↵Linus Torvalds2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - hp-wmi-sensors: Check if WMI event data exists before accessing it - ltc2991: fix register bits defines * tag 'hwmon-for-v6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (hp-wmi-sensors) Check if WMI event data exists hwmon: ltc2991: fix register bits defines
2024-09-04Merge tag 'for-6.11-rc6-tag' of ↵Linus Torvalds6-23/+42
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - followup fix for direct io and fsync under some conditions, reported by QEMU users - fix a potential leak when disabling quotas while some extent tracking work can still happen - in zoned mode handle unexpected change of zone write pointer in RAID1-like block groups, turn the zones to read-only * tag 'for-6.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix race between direct IO write and fsync when using same fd btrfs: zoned: handle broken write pointer on zones btrfs: qgroup: don't use extent changeset when not needed
2024-09-04Merge tag 'v6.11-rc6-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds3-2/+8
Pull smb server fixes from Steve French: - Fix crash in session setup - Fix locking bug - Improve access bounds checking * tag 'v6.11-rc6-server-fixes' of git://git.samba.org/ksmbd: ksmbd: Unlock on in ksmbd_tcp_set_interfaces() ksmbd: unset the binding mark of a reused connection smb: Annotate struct xattr_smb_acl with __counted_by()
2024-09-04Merge tag 'vfs-6.11-rc7.fixes' of ↵Linus Torvalds2-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: "Two netfs fixes for this merge window: - Ensure that fscache_cookie_lru_time is deleted when the fscache module is removed to prevent UAF - Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range() Before it used truncate_inode_pages_partial() which causes copy_file_range() to fail on cifs" * tag 'vfs-6.11-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fscache: delete fscache_cookie_lru_timer when fscache exits to avoid UAF mm: Fix filemap_invalidate_inode() to use invalidate_inode_pages2_range()
2024-09-04Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linuxLinus Torvalds2-4/+10
Pull ARM fix from Russell King: - Fix a build issue with older binutils with LD dead code elimination disabled * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rmk/linux: ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATION
2024-09-04Merge tag 'parisc-for-6.11-rc7' of ↵Linus Torvalds1-5/+11
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc architecture fix from Helge Deller: - Fix boot issue where boot memory is marked read-only too early * tag 'parisc-for-6.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Delay write-protection until mark_rodata_ro() call
2024-09-04Merge tag 'mm-hotfixes-stable-2024-09-03-20-19' of ↵Linus Torvalds17-124/+197
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "17 hotfixes, 15 of which are cc:stable. Mostly MM, no identifiable theme. And a few nilfs2 fixups" * tag 'mm-hotfixes-stable-2024-09-03-20-19' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: alloc_tag: fix allocation tag reporting when CONFIG_MODULES=n mm: vmalloc: optimize vmap_lazy_nr arithmetic when purging each vmap_area mailmap: update entry for Jan Kuliga codetag: debug: mark codetags for poisoned page as empty mm/memcontrol: respect zswap.writeback setting from parent cg too scripts: fix gfp-translate after ___GFP_*_BITS conversion to an enum Revert "mm: skip CMA pages when they are not available" maple_tree: remove rcu_read_lock() from mt_validate() kexec_file: fix elfcorehdr digest exclusion when CONFIG_CRASH_HOTPLUG=y mm/slub: add check for s->flags in the alloc_tagging_slab_free_hook nilfs2: fix state management in error path of log writing function nilfs2: fix missing cleanup on rollforward recovery error nilfs2: protect references to superblock parameters exposed in sysfs userfaultfd: don't BUG_ON() if khugepaged yanks our page table userfaultfd: fix checks for huge PMDs mm: vmalloc: ensure vmap_block is initialised before adding to queue selftests: mm: fix build errors on armhf
2024-09-04ARM: 9414/1: Fix build issue with LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu2-4/+10
There is a build issue with LD segmentation fault, while CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled, as bellow. scripts/link-vmlinux.sh: line 49: 3796 Segmentation fault (core dumped) ${ld} ${ldflags} -o ${output} ${wl}--whole-archive ${objs} ${wl}--no-whole-archive ${wl}--start-group ${libs} ${wl}--end-group ${kallsymso} ${btf_vmlinux_bin_o} ${ldlibs} The error occurs in older versions of the GNU ld with version earlier than 2.36. It makes most sense to have a minimum LD version as a dependency for HAVE_LD_DEAD_CODE_DATA_ELIMINATION and eliminate the impact of ".reloc .text, R_ARM_NONE, ." when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is not enabled. Fixes: ed0f94102251 ("ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION") Reported-by: Harith George <[email protected]> Tested-by: Harith George <[email protected]> Suggested-by: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Yuntao Liu <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Russell King (Oracle) <[email protected]>
2024-09-04Merge patch series "can: rockchip_canfd: add support for CAN-FD IP core ↵Marc Kleine-Budde12-0/+2269
found on Rockchip RK3568" Marc Kleine-Budde <[email protected]> says: This series adds support for the CAN-FD IP core found on the Rockchip RK3568. The IP core is a bit complicated and has several documented errata. The driver is added in several stages, first the base driver including the RX-path. Then several workarounds for errata and the TX-path, and finally features like hardware time stamping, loop-back mode and bus error reporting. Link: https://patch.msgid.link/[email protected] [mkl: removed DTS patches] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add support for CAN_CTRLMODE_BERR_REPORTINGMarc Kleine-Budde1-8/+17
Add support for Bus Error Reporting. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add support for CAN_CTRLMODE_LOOPBACKMarc Kleine-Budde2-2/+7
Add support for loopback mode. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add hardware timestamping supportMarc Kleine-Budde6-3/+115
Add support for hardware based timestamping. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: enable full TX-FIFO depth of 2Marc Kleine-Budde1-1/+1
The previous commit prepared the TX path to make use of the full TX-FIFO depth as much as possible. Increase the available TX-FIFO depth to the hardware maximum of 2. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: prepare to use full TX-FIFO depthMarc Kleine-Budde3-3/+38
So far the TX-FIFO is only used with a depth of 1, although the hardware offers a depth of 2. The workaround for the chips that are affected by erratum 6, i.e. EFF frames may be send as standard frames, is to re-send the EFF frame. This means the driver cannot queue the next frame for sending, as long ad the EFF frame has not been successfully send out. Introduce rkcanfd_get_effective_tx_free() that returns "0" space in the TX-FIFO if an EFF frame is pending and the actual free space in the TX-FIFO otherwise. Then replace rkcanfd_get_tx_free() with rkcanfd_get_effective_tx_free() everywhere. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add stats support for errata workaroundsMarc Kleine-Budde5-1/+102
The driver contains workarounds for some of the rk3568v2 errata. Add ethtool-based statistics ("ethtool -S") to track how often an erratum workaround was needed. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_get_berr_counter_corrected(): work around ↵Marc Kleine-Budde4-6/+69
broken {RX,TX}ERRORCNT register Tests show that sometimes both CAN bus error counters read 0x0, even if the controller is in warning mode (RKCANFD_REG_STATE_ERROR_WARNING_STATE in RKCANFD_REG_STATE set). To work around this issue, if both error counters read from hardware are 0x0, use the structure priv->bec, otherwise save the read value in priv->bec. In rkcanfd_handle_rx_int_one() decrement the priv->bec.rxerr for successfully RX'ed CAN frames. In rkcanfd_handle_tx_done_one() decrement the priv->bec.txerr for successfully TX'ed CAN frames. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: implement workaround for erratum 12Marc Kleine-Budde1-0/+7
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | A dominant bit at the third bit of the intermission may cause a | transmission error. | | When sampling the third bit of the intermission as a dominant bit, if | tx_req is configured to transmit extended frames at this time, the | extended frame may be sent to the bus in the format of a standard | frame. The extended frame will be sent as a standard frame and will not | result in error frames Turn on "Interframe Spaceing RX Mode" only during TX to work around erratum 12, according to rock-chip: | Spaceing RX Mode = 1, the third Bit between frames cannot receive | and send, and the fourth Bit begins to receive and send. | | Spaceing RX Mode = 0, allowing the third Bit between frames to | receive and send. Message-ID: <[email protected]> Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: implement workaround for erratum 6Marc Kleine-Budde3-0/+71
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | The CAN controller's transmission of extended frames may | intermittently change into standard frames. | | When using the CAN controller to send extended frames, if the | 'tx_req' is configured as 1 and coincides with the internal | transmission point, the extended frame will be transmitted onto the | bus in the format of a standard frame. To work around Erratum 6, the driver is in self-receiving mode (RXSTX) and all received CAN frames are passed through rkcanfd_rxstx_filter(). Add a check in rkcanfd_rxstx_filter() whether the received frame corresponds to the current outgoing frame, but the extended CAN ID has been mangled to a standard ID. In this case re-send the original CAN frame. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add TX PATHMarc Kleine-Budde4-1/+221
The IP core has a TX event FIFO. In other IP cores, this type of FIFO usually contains the events that a CAN frame has been successfully sent. However, the IP core on the rk3568v2 the FIFO also holds events of unsuccessful transmission attempts. It turned out that the best way to work around this problem is to set the IP core to self-receive mode (RXSTX), filter out the self-received frames and insert them into the complete TX path. Add a pair new functions to check if 2 struct canfd_frame are equal. The 1st checks if the header of the CAN frames are equal, the 2nd checks if the data portion are equal: - rkcanfd_can_frame_header_equal() - rkcanfd_can_frame_data_equal() Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_register_done(): add warning for erratum 5Marc Kleine-Budde1-0/+7
Tests on the rk3568v2 and rk3568v3 show that a reduced "baudclk" (e.g. 80MHz, compared to the standard 300MHz) significantly increases the possibility of incorrect FIFO counters, i.e. erratum 5. Print an info message if the clock is below the known good value of 300MHz. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: rkcanfd_handle_rx_int_one(): implement workaround for ↵Marc Kleine-Budde2-0/+36
erratum 5: check for empty FIFO The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | Erratum 5: Counters related to the TXFIFO and RXFIFO exhibit | abnormal counting behavior. | | Due to a bug in the cross-asynchronous logic of the enable signals | for rx_fifo_cnt and txe_fifo_frame_cnt counters, the counts of these | two counters become inaccurate. This issue has resulted in the | inability to use the TXFIFO and RXFIFO functions. The errata sheet mentioned above states that only the rk3568v2 is affected by this erratum, but tests with the rk3568v2 and rk3568v3 show that the RX_FIFO_CNT is sometimes too high. This leads to CAN frames being read from the FIFO, which is then already empty. Further tests on the rk3568v2 and rk3568v3 show that in this situation (i.e. empty FIFO) all elements of the FIFO header (frameinfo, id, ts) contain the same data. On the rk3568v2 and rk3568v3, this problem only occurs extremely rarely with the standard clock of 300 MHz, but almost immediately at 80 MHz. To workaround this problem, check for empty FIFO with rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit early. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add notes about known issuesMarc Kleine-Budde1-0/+20
Even the rk3568v3 has some known issues. Document them together with a reproducer. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add support for rk3568v3Marc Kleine-Budde2-0/+21
Add the support for the rk3568v3 SoC, the CAN-FD IP core has 7 documented errata. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add quirk for broken CAN-FD supportMarc Kleine-Budde2-1/+25
The errata sheets doesn't say anything about CAN-FD, but tests on the rk3568v2 and rk3568v3 show that receiving certain CAN-FD frames triggers an Error Interrupt. Mark the CAN-FD support as broken. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add quirks for errata workaroundsMarc Kleine-Budde2-2/+64
Add a basic infrastructure for quirks for the 12 documented errata. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04can: rockchip_canfd: add driver for Rockchip CAN-FD controllerMarc Kleine-Budde10-0/+1395
Add driver for the Rockchip CAN-FD controller. The IP core on the rk3568v2 SoC has 12 documented errata. Corrections for these errata will be added in the upcoming patches. Since several workarounds are required for the TX path, only add the base driver that only implements the RX path. Although the RX path implements CAN-FD support, it's not activated in ctrlmode_supported, as the IP core in the rk3568v2 has problems with receiving or sending certain CAN-FD frames. Tested-by: Alibek Omarov <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2024-09-04Merge branch 'fbnic-ethtool'David S. Miller12-3/+260
Mohsin Bashir says: ==================== eth: Add basic ethtool support for fbnic This patch series adds basic ethtool support for fbnic. Specifically, the two patches focus on the following two features respectively: 1: Enable 'ethtool -i <dev>' to provide driver, firmware and bus information. 2: Provide mac group stats. Changes since v2: - Fix v1 reference link - Fix nit --- v2: https://lore.kernel.org/netdev/[email protected] v1: https://lore.kernel.org/netdev/[email protected] ==================== Signed-off-by: David S. Miller <[email protected]>