commit 1b4861e32e461b6fae14dc49ed0f1c7f20af5146 Author: Greg Kroah-Hartman Date: Thu May 30 09:45:04 2024 +0200 Linux 6.9.3 Link: https://lore.kernel.org/r/20240527185601.713589927@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Pavel Machek (CIP) Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: SeongJae Park Tested-by: Mark Brown Tested-by: Pascal Ernster Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 68648feffc6020ad3f9b010625d92ef0276b6c85 Author: Shuah Khan Date: Thu May 16 20:58:26 2024 -0600 Revert "selftests/sgx: Include KHDR_INCLUDES in Makefile" [ Upstream commit 3da164023582969280df17636a9d829752787b1c ] This reverts commit 2c3b8f8f37c6c0c926d584cf4158db95e62b960c. The framework change to add D_GNU_SOURCE to KHDR_INCLUDES to Makefile, lib.mk, and kselftest_harness.h is reverted as it is causing build failures and warnings. Revert this change as this change depends on the framework change. Reported-by: Mark Brown Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 108fd118175ac3c5be46f676fa9c886ff020559c Author: Shuah Khan Date: Thu May 16 20:51:07 2024 -0600 Revert "selftests: Compile kselftest headers with -D_GNU_SOURCE" [ Upstream commit cee27ae5f1fb8bc4762f5d5de19ec6de6c45e239 ] This reverts commit daef47b89efd0b745e8478d69a3ad724bd8b4dc6. This framework change to add D_GNU_SOURCE to KHDR_INCLUDES to Makefile, lib.mk, and kselftest_harness.h is causing build failures and warnings. Revert this change. Reported-by: Mark Brown Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 7207cbc99ec87d64ce451a4d105cb8a028c09464 Author: Tom Parkin Date: Mon May 13 18:22:47 2024 +0100 l2tp: fix ICMP error handling for UDP-encap sockets [ Upstream commit 6e828dc60e509b79ef09882264952f341cb58425 ] Since commit a36e185e8c85 ("udp: Handle ICMP errors for tunnels with same destination port on both endpoints") UDP's handling of ICMP errors has allowed for UDP-encap tunnels to determine socket associations in scenarios where the UDP hash lookup could not. Subsequently, commit d26796ae58940 ("udp: check udp sock encap_type in __udp_lib_err") subtly tweaked the approach such that UDP ICMP error handling would be skipped for any UDP socket which has encapsulation enabled. In the case of L2TP tunnel sockets using UDP-encap, this latter modification effectively broke ICMP error reporting for the L2TP control plane. To a degree this isn't catastrophic inasmuch as the L2TP control protocol defines a reliable transport on top of the underlying packet switching network which will eventually detect errors and time out. However, paying attention to the ICMP error reporting allows for more timely detection of errors in L2TP userspace, and aids in debugging connectivity issues. Reinstate ICMP error handling for UDP encap L2TP tunnels: * implement struct udp_tunnel_sock_cfg .encap_err_rcv in order to allow the L2TP code to handle ICMP errors; * only implement error-handling for tunnels which have a managed socket: unmanaged tunnels using a kernel socket have no userspace to report errors back to; * flag the error on the socket, which allows for userspace to get an error such as -ECONNREFUSED back from sendmsg/recvmsg; * pass the error into ip[v6]_icmp_error() which allows for userspace to get extended error information via. MSG_ERRQUEUE. Fixes: d26796ae5894 ("udp: check udp sock encap_type in __udp_lib_err") Signed-off-by: Tom Parkin Link: https://lore.kernel.org/r/20240513172248.623261-1-tparkin@katalix.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a7d3af980885dc64f0c5ed7b40844c9c898647ab Author: Jiawen Wu Date: Fri May 17 14:51:40 2024 +0800 net: txgbe: fix to control VLAN strip [ Upstream commit 1d3c6414950badaa38002af3b5857e01a21f01e9 ] When VLAN tag strip is changed to enable or disable, the hardware requires the Rx ring to be in a disabled state, otherwise the feature cannot be changed. Fixes: f3b03c655f67 ("net: wangxun: Implement vlan add and kill functions") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ef5b69d5c3618c9738fc0ce40c376ab274d688e9 Author: Jiawen Wu Date: Fri May 17 14:51:39 2024 +0800 net: wangxun: match VLAN CTAG and STAG features [ Upstream commit ac71ab7816b675f1c9614015bd87bfccb456c394 ] Hardware requires VLAN CTAG and STAG configuration always matches. And whether VLAN CTAG or STAG changes, the configuration needs to be changed as well. Fixes: 6670f1ece2c8 ("net: txgbe: Add netdev features support") Signed-off-by: Jiawen Wu Reviewed-by: Sai Krishna Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 20844ad91d38c3452082131060f98ede8b34a200 Author: Jiawen Wu Date: Fri May 17 14:51:38 2024 +0800 net: wangxun: fix to change Rx features [ Upstream commit 68067f065ee730c7c67b361c3c81808d25d5a90b ] Fix the issue where some Rx features cannot be changed. When using ethtool -K to turn off rx offload, it returns error and displays "Could not change any device features". And netdev->features is not assigned a new value to actually configure the hardware. Fixes: 6dbedcffcf54 ("net: libwx: Implement xx_set_features ops") Signed-off-by: Jiawen Wu Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b85d872d1a026dda1517d044dc75a72130db58fe Author: Cheng Yu Date: Wed Apr 24 21:24:38 2024 +0800 sched/core: Fix incorrect initialization of the 'burst' parameter in cpu_max_write() [ Upstream commit 49217ea147df7647cb89161b805c797487783fc0 ] In the cgroup v2 CPU subsystem, assuming we have a cgroup named 'test', and we set cpu.max and cpu.max.burst: # echo 1000000 > /sys/fs/cgroup/test/cpu.max # echo 1000000 > /sys/fs/cgroup/test/cpu.max.burst then we check cpu.max and cpu.max.burst: # cat /sys/fs/cgroup/test/cpu.max 1000000 100000 # cat /sys/fs/cgroup/test/cpu.max.burst 1000000 Next we set cpu.max again and check cpu.max and cpu.max.burst: # echo 2000000 > /sys/fs/cgroup/test/cpu.max # cat /sys/fs/cgroup/test/cpu.max 2000000 100000 # cat /sys/fs/cgroup/test/cpu.max.burst 1000 ... we find that the cpu.max.burst value changed unexpectedly. In cpu_max_write(), the unit of the burst value returned by tg_get_cfs_burst() is microseconds, while in cpu_max_write(), the burst unit used for calculation should be nanoseconds, which leads to the bug. To fix it, get the burst value directly from tg->cfs_bandwidth.burst. Fixes: f4183717b370 ("sched/fair: Introduce the burstable CFS controller") Reported-by: Qixin Liao Signed-off-by: Cheng Yu Signed-off-by: Zhang Qiao Signed-off-by: Ingo Molnar Reviewed-by: Vincent Guittot Tested-by: Vincent Guittot Link: https://lore.kernel.org/r/20240424132438.514720-1-serein.chengyu@huawei.com Signed-off-by: Sasha Levin commit e927daa72fc93341b00b8b1d90dbaa35e4a56fa8 Author: Vitalii Bursov Date: Tue Apr 30 18:05:23 2024 +0300 sched/fair: Allow disabling sched_balance_newidle with sched_relax_domain_level [ Upstream commit a1fd0b9d751f840df23ef0e75b691fc00cfd4743 ] Change relax_domain_level checks so that it would be possible to include or exclude all domains from newidle balancing. This matches the behavior described in the documentation: -1 no request. use system default or follow request of others. 0 no search. 1 search siblings (hyperthreads in a core). "2" enables levels 0 and 1, level_max excludes the last (level_max) level, and level_max+1 includes all levels. Fixes: 1d3504fcf560 ("sched, cpuset: customize sched domains, core") Signed-off-by: Vitalii Bursov Signed-off-by: Ingo Molnar Tested-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Reviewed-by: Valentin Schneider Link: https://lore.kernel.org/r/bd6de28e80073c79466ec6401cdeae78f0d4423d.1714488502.git.vitaly@bursov.com Signed-off-by: Sasha Levin commit 22a9f300fbe553fdb23738691b320ea5073eb454 Author: Eric Dumazet Date: Wed May 15 16:33:58 2024 +0000 af_packet: do not call packet_read_pending() from tpacket_destruct_skb() [ Upstream commit 581073f626e387d3e7eed55c48c8495584ead7ba ] trafgen performance considerably sank on hosts with many cores after the blamed commit. packet_read_pending() is very expensive, and calling it in af_packet fast path defeats Daniel intent in commit b013840810c2 ("packet: use percpu mmap tx frame pending refcount") tpacket_destruct_skb() makes room for one packet, we can immediately wakeup a producer, no need to completely drain the tx ring. Fixes: 89ed5b519004 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET") Signed-off-by: Eric Dumazet Cc: Neil Horman Cc: Daniel Borkmann Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/20240515163358.4105915-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5bc50a705cfac8f64ce51c95611c3dd0554ef9c3 Author: Eric Dumazet Date: Wed May 15 14:29:34 2024 +0000 netrom: fix possible dead-lock in nr_rt_ioctl() [ Upstream commit e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6 ] syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 stack backtrace: CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240515142934.3708038-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4bb924af08c09bac34971c5dc8b071a8aba167f Author: Michal Schmidt Date: Wed May 15 11:24:14 2024 +0200 idpf: don't skip over ethtool tcp-data-split setting [ Upstream commit 67708158e732bf03d076fba1e3d4453fbf8292a2 ] Disabling tcp-data-split on idpf silently fails: # ethtool -G $NETDEV tcp-data-split off # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: on But it works if you also change 'tx' or 'rx': # ethtool -G $NETDEV tcp-data-split off tx 256 # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: off The bug is in idpf_set_ringparam, where it takes a shortcut out if the TX and RX sizes are not changing. Fix it by checking also if the tcp-data-split setting remains unchanged. Only then can the soft reset be skipped. Fixes: 9b1aa3ef2328 ("idpf: add get/set for Ethtool's header split ringparam") Reported-by: Xu Du Closes: https://issues.redhat.com/browse/RHEL-36182 Signed-off-by: Michal Schmidt Reviewed-by: Alexander Lobakin Link: https://lore.kernel.org/r/20240515092414.158079-1-mschmidt@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 898212413f1ab59b2a9f6e407bb8d1e6782a748c Author: Hangbin Liu Date: Tue May 14 10:33:59 2024 +0800 selftests/net/lib: no need to record ns name if it already exist [ Upstream commit 83e93942796db58652288f0391ac00072401816f ] There is no need to add the name to ns_list again if the netns already recoreded. Fixes: 25ae948b4478 ("selftests/net: add lib.sh") Signed-off-by: Hangbin Liu Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ebe7716b077883666421e126b718966f4870dc2b Author: Chris Lew Date: Mon May 13 10:31:46 2024 -0700 net: qrtr: ns: Fix module refcnt [ Upstream commit fd76e5ccc48f9f54eb44909dd7c0b924005f1582 ] The qrtr protocol core logic and the qrtr nameservice are combined into a single module. Neither the core logic or nameservice provide much functionality by themselves; combining the two into a single module also prevents any possible issues that may stem from client modules loading inbetween qrtr and the ns. Creating a socket takes two references to the module that owns the socket protocol. Since the ns needs to create the control socket, this creates a scenario where there are always two references to the qrtr module. This prevents the execution of 'rmmod' for qrtr. To resolve this, forcefully put the module refcount for the socket opened by the nameservice. Fixes: a365023a76f2 ("net: qrtr: combine nameservice into main module") Reported-by: Jeffrey Hugo Tested-by: Jeffrey Hugo Signed-off-by: Chris Lew Reviewed-by: Manivannan Sadhasivam Reviewed-by: Jeffrey Hugo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ca5051ca55def06a7e4f8b0b66dbbe780cb5a12 Author: Andrii Nakryiko Date: Mon May 13 11:08:03 2024 -0700 libbpf: fix feature detectors when using token_fd [ Upstream commit 1de27bba6d50a909647f304eadc0f7c59a842a50 ] Adjust `union bpf_attr` size passed to kernel in two feature-detecting functions to take into account prog_token_fd field. Libbpf is avoiding memset()'ing entire `union bpf_attr` by only using minimal set of bpf_attr's fields. Two places have been missed when wiring BPF token support in libbpf's feature detection logic. Fix them trivially. Fixes: f3dcee938f48 ("libbpf: Wire up token_fd into feature probing logic") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20240513180804.403775-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit e43dd2b1ec746e105b7db5f9ad6ef14685a615a4 Author: Nikolay Aleksandrov Date: Mon May 13 14:06:27 2024 +0300 net: bridge: mst: fix vlan use-after-free [ Upstream commit 3a7c1661ae1383364cd6092d851f5e5da64d476b ] syzbot reported a suspicious rcu usage[1] in bridge's mst code. While fixing it I noticed that nothing prevents a vlan to be freed while walking the list from the same path (br forward delay timer). Fix the rcu usage and also make sure we are not accessing freed memory by making br_mst_vlan_set_state use rcu read lock. [1] WARNING: suspicious RCU usage 6.9.0-rc6-syzkaller #0 Not tainted ----------------------------- net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage! ... stack backtrace: CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbp_vlan_group net/bridge/br_private.h:1599 [inline] br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105 br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47 br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88 call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429 run_timer_base kernel/time/timer.c:2438 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448 __do_softirq+0x2c6/0x980 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758 Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246 Fixes: ec7328b59176 ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: syzbot+fa04eb8a56fd923fc5d8@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=fa04eb8a56fd923fc5d8 Signed-off-by: Nikolay Aleksandrov Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a431a0ebcc6d03054b5a6d6e6becce0ac92c9441 Author: Nikolay Aleksandrov Date: Mon May 13 13:52:57 2024 +0300 selftests: net: bridge: increase IGMP/MLD exclude timeout membership interval [ Upstream commit 06080ea23095afe04a2cb7a8d05fab4311782623 ] When running the bridge IGMP/MLD selftests on debug kernels we can get spurious errors when setting up the IGMP/MLD exclude timeout tests because the membership interval is just 3 seconds and the setup has 2 seconds of sleep plus various validations, the one second that is left is not enough. Increase the membership interval from 3 to 5 seconds to make room for the setup validation and 2 seconds of sleep. Fixes: 34d7ecb3d4f7 ("selftests: net: bridge: update IGMP/MLD membership interval value") Reported-by: Jakub Kicinski Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b5d669f569807c7ab07546e73c0741845a2547a Author: Nikolay Aleksandrov Date: Mon May 13 13:34:19 2024 +0300 net: bridge: xmit: make sure we have at least eth header len bytes [ Upstream commit 8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc ] syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+a63a1f6a062033cf0f40@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a63a1f6a062033cf0f40 Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit df003a18d9f250b4c0fdfd4c2fa44a7d97ea1103 Author: Wang Yao Date: Wed Apr 17 13:35:30 2024 +0800 modules: Drop the .export_symbol section from the final modules [ Upstream commit 8fe51b45c5645c259f759479c374648e9dfeaa03 ] Commit ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost") forget drop the .export_symbol section from the final modules. Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost") Signed-off-by: Wang Yao Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 52e665d950e3dc84c2533d98f58c81c317da2643 Author: Beau Belgrave Date: Tue Apr 23 16:23:37 2024 +0000 tracing/user_events: Fix non-spaced field matching [ Upstream commit bd125a084091396f3e796bb3dc009940d9771811 ] When the ABI was updated to prevent same name w/different args, it missed an important corner case when fields don't end with a space. Typically, space is used for fields to help separate them, like "u8 field1; u8 field2". If no spaces are used, like "u8 field1;u8 field2", then the parsing works for the first time. However, the match check fails on a subsequent register, leading to confusion. This is because the match check uses argv_split() and assumes that all fields will be split upon the space. When spaces are used, we get back { "u8", "field1;" }, without spaces we get back { "u8", "field1;u8" }. This causes a mismatch, and the user program gets back -EADDRINUSE. Add a method to detect this case before calling argv_split(). If found force a space after the field separator character ';'. This ensures all cases work properly for matching. With this fix, the following are all treated as matching: u8 field1;u8 field2 u8 field1; u8 field2 u8 field1;\tu8 field2 u8 field1;\nu8 field2 Link: https://lore.kernel.org/linux-trace-kernel/20240423162338.292-2-beaub@linux.microsoft.com Fixes: ba470eebc2f6 ("tracing/user_events: Prevent same name but different args event") Signed-off-by: Beau Belgrave Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit c29a9b84cd9b2ed5fcc46d6c2cd8dee30554eb48 Author: Ivanov Mikhail Date: Tue Mar 26 17:56:25 2024 +0800 samples/landlock: Fix incorrect free in populate_ruleset_net [ Upstream commit 42212936d9d811c7cf6efc4804747a6c417aafd4 ] Pointer env_port_name changes after strsep(). Memory allocated via strdup() will not be freed if landlock_add_rule() returns non-zero value. Fixes: 5e990dcef12e ("samples/landlock: Support TCP restrictions") Signed-off-by: Ivanov Mikhail Reviewed-by: Konstantin Meskhidze Link: https://lore.kernel.org/r/20240326095625.3576164-1-ivanov.mikhail1@huawei-partners.com Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin commit b3a7fb93afd888793ef226e9665fbda98a95c48e Author: Zhu Yanjun Date: Fri May 10 23:12:47 2024 +0200 RDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw [ Upstream commit 9c0731832d3b7420cbadba6a7f334363bc8dfb15 ] When running blktests nvme/rdma, the following kmemleak issue will appear. kmemleak: Kernel memory leak detector initialized (mempool available:36041) kmemleak: Automatic memory scanning thread started kmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88855da53400 (size 192): comm "rdma", pid 10630, jiffies 4296575922 hex dump (first 32 bytes): 37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00 7............... 10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff .4.].....4.].... backtrace (crc 47f66721): [] kmalloc_trace+0x30d/0x3b0 [] alloc_gid_entry+0x47/0x380 [ib_core] [] add_modify_gid+0x166/0x930 [ib_core] [] ib_cache_update.part.0+0x6d8/0x910 [ib_core] [] ib_cache_setup_one+0x24a/0x350 [ib_core] [] ib_register_device+0x9e/0x3a0 [ib_core] [] 0xffffffffc2a3d389 [] nldev_newlink+0x2b8/0x520 [ib_core] [] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core] [] rdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core] [] netlink_unicast+0x445/0x710 [] netlink_sendmsg+0x761/0xc40 [] __sys_sendto+0x3a9/0x420 [] __x64_sys_sendto+0xdc/0x1b0 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause: rdma_put_gid_attr is not called when sgid_attr is set to ERR_PTR(-ENODEV). Reported-and-tested-by: Yi Zhang Closes: https://lore.kernel.org/all/19bf5745-1b3b-4b8a-81c2-20d945943aaf@linux.dev/T/ Fixes: f8ef1be816bf ("RDMA/cma: Avoid GID lookups on iWARP devices") Reviewed-by: Chuck Lever Signed-off-by: Zhu Yanjun Link: https://lore.kernel.org/r/20240510211247.31345-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 1a8c2cc4c2a6ff3c0606ce8443072b008c108111 Author: Leon Romanovsky Date: Thu May 9 10:39:33 2024 +0300 RDMA/IPoIB: Fix format truncation compilation errors [ Upstream commit 49ca2b2ef3d003402584c68ae7b3055ba72e750a ] Truncate the device name to store IPoIB VLAN name. [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 allmodconfig [leonro@5b4e8fba4ddd kernel]$ make -s -j 20 W=1 drivers/infiniband/ulp/ipoib/ drivers/infiniband/ulp/ipoib/ipoib_vlan.c: In function ‘ipoib_vlan_add’: drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:52: error: ‘%04x’ directive output may be truncated writing 4 bytes into a region of size between 0 and 15 [-Werror=format-truncation=] 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~ drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:48: note: directive argument in the range [0, 65535] 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~~~~~~ drivers/infiniband/ulp/ipoib/ipoib_vlan.c:187:9: note: ‘snprintf’ output between 6 and 21 bytes into a destination of size 16 187 | snprintf(intf_name, sizeof(intf_name), "%s.%04x", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 188 | ppriv->dev->name, pkey); | ~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[6]: *** [scripts/Makefile.build:244: drivers/infiniband/ulp/ipoib/ipoib_vlan.o] Error 1 make[6]: *** Waiting for unfinished jobs.... Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support") Link: https://lore.kernel.org/r/e9d3e1fef69df4c9beaf402cc3ac342bad680791.1715240029.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8ff23f8ab55ce42c8a4656a193162ce017de53c1 Author: Edward Liaw Date: Mon Apr 29 23:46:09 2024 +0000 selftests/kcmp: remove unused open mode [ Upstream commit eb59a58113717df04b8a8229befd8ab1e5dbf86e ] Android bionic warns that open modes are ignored if O_CREAT or O_TMPFILE aren't specified. The permissions for the file are set above: fd1 = open(kpath, O_RDWR | O_CREAT | O_TRUNC, 0644); Link: https://lkml.kernel.org/r/20240429234610.191144-1-edliaw@google.com Fixes: d97b46a64674 ("syscalls, x86: add __NR_kcmp syscall") Signed-off-by: Edward Liaw Reviewed-by: Cyrill Gorcunov Cc: Eric Biederman Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cf640a9d52e780468ee403ff7fee8e04d7914c35 Author: SeongJae Park Date: Fri May 3 11:03:10 2024 -0700 selftests/damon/_damon_sysfs: check errors from nr_schemes file reads [ Upstream commit 732b8815c079199d29b0426d9372bb098c63cdc7 ] DAMON context staging method in _damon_sysfs.py is not checking the returned error from nr_schemes file read. Check it. Link: https://lkml.kernel.org/r/20240503180318.72798-3-sj@kernel.org Fixes: f5f0e5a2bef9 ("selftests/damon/_damon_sysfs: implement kdamonds start function") Signed-off-by: SeongJae Park Cc: Jonathan Corbet Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8ca148915670a2921afcc255af9e1dc80f37b052 Author: Chuck Lever Date: Tue May 7 09:10:41 2024 -0400 SUNRPC: Fix gss_free_in_token_pages() [ Upstream commit bafa6b4d95d97877baa61883ff90f7e374427fae ] Dan Carpenter says: > Commit 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") from Oct > 24, 2019 (linux-next), leads to the following Smatch static checker > warning: > > net/sunrpc/auth_gss/svcauth_gss.c:1039 gss_free_in_token_pages() > warn: iterator 'i' not incremented > > net/sunrpc/auth_gss/svcauth_gss.c > 1034 static void gss_free_in_token_pages(struct gssp_in_token *in_token) > 1035 { > 1036 u32 inlen; > 1037 int i; > 1038 > --> 1039 i = 0; > 1040 inlen = in_token->page_len; > 1041 while (inlen) { > 1042 if (in_token->pages[i]) > 1043 put_page(in_token->pages[i]); > ^ > This puts page zero over and over. > > 1044 inlen -= inlen > PAGE_SIZE ? PAGE_SIZE : inlen; > 1045 } > 1046 > 1047 kfree(in_token->pages); > 1048 in_token->pages = NULL; > 1049 } Based on the way that the ->pages[] array is constructed in gss_read_proxy_verf(), we know that once the loop encounters a NULL page pointer, the remaining array elements must also be NULL. Reported-by: Dan Carpenter Suggested-by: Trond Myklebust Fixes: 5866efa8cbfb ("SUNRPC: Fix svcauth_gss_proxy_init()") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 8b799c00cea6fcfe5b501bbaeb228c8821acb753 Author: Michal Schmidt Date: Tue May 7 12:39:28 2024 +0200 bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq [ Upstream commit 78cfd17142ef70599d6409cbd709d94b3da58659 ] Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 ---[ end trace ]--- Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Signed-off-by: Michal Schmidt Link: https://lore.kernel.org/r/20240507103929.30003-1-mschmidt@redhat.com Acked-by: Selvin Xavier Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit e45b69360a63165377b30db4a1dfddd89ca18e9a Author: Sergey Shtylyov Date: Sun Apr 14 11:51:39 2024 +0300 of: module: add buffer overflow check in of_modalias() [ Upstream commit cf7385cb26ac4f0ee6c7385960525ad534323252 ] In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/bbfc6be0-c687-62b6-d015-5141b93f313e@omp.ru Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 0224bf502aee39a7bf92741bd1dad04159808002 Author: Gabor Juhos Date: Tue Mar 26 14:34:11 2024 +0100 clk: qcom: apss-ipq-pll: fix PLL rate for IPQ5018 [ Upstream commit c55f7ee2ec239b6afd8639c7ac06493876deb0ea ] According to ipq5018.dtsi, the maximum supported rate by the CPU is 1.008 GHz on the IPQ5018 platform, however the current configuration of the PLL results in 1.2 GHz rate. Change the 'L' value in the PLL configuration to limit the rate to 1.008 GHz. The downstream kernel also uses the same value [1]. Also add a comment to indicate the desired frequency. [1] https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c?ref_type=heads#L151 Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018") Signed-off-by: Gabor Juhos Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240326-fix-ipq5018-apss-pll-rate-v1-1-82ab31c9da7e@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit e0cfada5861dbd2a80a74d38fd7b2722fc988eb3 Author: Nathan Chancellor Date: Mon Mar 18 08:18:11 2024 -0700 clk: qcom: Fix SM_GPUCC_8650 dependencies [ Upstream commit 07fb0a76bb757990b99fc2ab78ad7d1709cc441d ] CONFIG_SM_GCC_8650 depends on ARM64 but it is selected by CONFIG_SM_GPUCC_8650, which can be selected on ARM, resulting in a Kconfig warning. WARNING: unmet direct dependencies detected for SM_GCC_8650 Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n]) Selected by [y]: - SM_GPUCC_8650 [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] Add the same dependencies to CONFIG_SM_GPUCC_8650 to resolve the warning. Fixes: 8676fd4f3874 ("clk: qcom: add the SM8650 GPU Clock Controller driver") Signed-off-by: Nathan Chancellor Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240318-fix-some-qcom-kconfig-deps-v1-2-ea0773e3df5a@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 939ce2fb81a9b8d1741190e015a4307c24c72766 Author: Nathan Chancellor Date: Mon Mar 18 08:18:10 2024 -0700 clk: qcom: Fix SC_CAMCC_8280XP dependencies [ Upstream commit e00f2540a581f8b8c165e5ae8afe52e4ad038550 ] CONFIG_SC_GCC_8280XP depends on ARM64 but it is selected by CONFIG_SC_CAMCC_8280XP, which can be selected on ARM, resulting in a Kconfig warning. WARNING: unmet direct dependencies detected for SC_GCC_8280XP Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] && (ARM64 || COMPILE_TEST [=n]) Selected by [y]: - SC_CAMCC_8280XP [=y] && COMMON_CLK [=y] && COMMON_CLK_QCOM [=y] Add the same dependencies to CONFIG_SC_CAMCC_8280XP to resolve the warning. Fixes: ff93872a9c61 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC") Signed-off-by: Nathan Chancellor Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240318-fix-some-qcom-kconfig-deps-v1-1-ea0773e3df5a@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ad78fd91c569917202f46690e0fd46baac8e5c40 Author: Zhang Yi Date: Fri Apr 19 10:30:05 2024 +0800 ext4: remove the redundant folio_wait_stable() [ Upstream commit df0b5afc62f3368d657a8fe4a8d393ac481474c2 ] __filemap_get_folio() with FGP_WRITEBEGIN parameter has already wait for stable folio, so remove the redundant folio_wait_stable() in ext4_da_write_begin(), it was left over from the commit cc883236b792 ("ext4: drop unnecessary journal handle in delalloc write") that removed the retry getting page logic. Fixes: cc883236b792 ("ext4: drop unnecessary journal handle in delalloc write") Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20240419023005.2719050-1-yi.zhang@huaweicloud.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4ab422499a9332e4312b67868a96568ac84cea13 Author: Dan Carpenter Date: Wed Apr 17 21:10:40 2024 +0300 ext4: fix potential unnitialized variable [ Upstream commit 3f4830abd236d0428e50451e1ecb62e14c365e9b ] Smatch complains "err" can be uninitialized in the caller. fs/ext4/indirect.c:349 ext4_alloc_branch() error: uninitialized symbol 'err'. Set the error to zero on the success path. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/363a4673-0fb8-4adf-b4fb-90a499077276@moroto.mountain Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 76ee68d93a5430ef69886db6d39dced7eb943853 Author: Vishal Verma Date: Tue Apr 30 11:44:26 2024 -0600 dax/bus.c: use the right locking mode (read vs write) in size_show [ Upstream commit 2acf04532d6d655d8c3b2ee4ddeb320107043086 ] In size_show(), the dax_dev_rwsem only needs a read lock, but was acquiring a write lock. Change it to down_read_interruptible() so it doesn't unnecessarily hold a write lock. Link: https://lkml.kernel.org/r/20240430-vv-dax_abi_fixes-v3-4-e3dcd755774c@intel.com Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Signed-off-by: Vishal Verma Reviewed-by: Dan Williams Cc: Alison Schofield Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 5c7c179e0bff4544b3cb24f52097be7ae68aa4a1 Author: Vishal Verma Date: Tue Apr 30 11:44:25 2024 -0600 dax/bus.c: don't use down_write_killable for non-user processes [ Upstream commit e39dbcfba714c4c2e924e96fc8fdde1080a5a737 ] Change an instance of down_write_killable() to a simple down_write() where there is no user process that might want to interrupt the operation. Link: https://lkml.kernel.org/r/20240430-vv-dax_abi_fixes-v3-3-e3dcd755774c@intel.com Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Signed-off-by: Vishal Verma Reported-by: Dan Williams Reviewed-by: Dan Williams Cc: Alison Schofield Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ed049a1dc3b921bcb7628c5e899cfb1bc30a5e39 Author: Vishal Verma Date: Tue Apr 30 11:44:24 2024 -0600 dax/bus.c: fix locking for unregister_dax_dev / unregister_dax_mapping paths [ Upstream commit 6f6544f27e41f9d7dca55c288f12175a9c48dfe2 ] Commit c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") aimed to undo device_lock() abuses for protecting changes to dax-driver internal data-structures like the dax_region resource tree to device-dax-instance range structures. However, the device_lock() was legitimately enforcing that devices to be deleted were not current actively attached to any driver nor assigned any capacity from the region. As a result of the device_lock restoration in delete_store(), the conditional locking in unregister_dev_dax() and unregister_dax_mapping() can be removed. Link: https://lkml.kernel.org/r/20240430-vv-dax_abi_fixes-v3-2-e3dcd755774c@intel.com Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Signed-off-by: Vishal Verma Reported-by: Dan Williams Reviewed-by: Dan Williams Cc: Alison Schofield Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit ca4ac88e61a62890ecd29999ea6de4d388e10c41 Author: Vishal Verma Date: Tue Apr 30 11:44:23 2024 -0600 dax/bus.c: replace WARN_ON_ONCE() with lockdep asserts [ Upstream commit c14c647bbe23fd96f6bffcc122b9c6c8c46c7928 ] Patch series "dax/bus.c: Fixups for dax-bus locking", v3. Commit Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") introduced a few problems that this series aims to fix. Add back device_lock() where it was correctly used (during device manipulation operations), remove conditional locking in unregister_dax_dev() and unregister_dax_mapping(), use non-interruptible versions of rwsem locks when not called from a user process, and fix up a write vs. read usage of an rwsem. This patch (of 4): In [1], Dan points out that all of the WARN_ON_ONCE() usage in the referenced patch should be replaced with lockdep_assert_held, or lockdep_held_assert_write(). Replace these as appropriate. Link: https://lkml.kernel.org/r/20240430-vv-dax_abi_fixes-v3-0-e3dcd755774c@intel.com Link: https://lore.kernel.org/r/65f0b5ef41817_aa222941a@dwillia2-mobl3.amr.corp.intel.com.notmuch [1] Link: https://lkml.kernel.org/r/20240430-vv-dax_abi_fixes-v3-1-e3dcd755774c@intel.com Fixes: c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local rwsem") Signed-off-by: Vishal Verma Reported-by: Dan Williams Reviewed-by: Dan Williams Cc: Alison Schofield Cc: Dave Jiang Cc: Vishal Verma Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 83429bf05f42aa79c0b6b311ef0b492afce7589e Author: NeilBrown Date: Wed Apr 17 07:23:02 2024 +1000 nfsd: don't create nfsv4recoverydir in nfsdfs when not used. [ Upstream commit 0770249b90f9d9f69714b76adc36cf6c895bc1f9 ] When CONFIG_NFSD_LEGACY_CLIENT_TRACKING is not set, the virtual file /proc/fs/nfsd/nfsv4recoverydir is created but responds EINVAL to any access. This is not useful, is somewhat surprising, and it causes ltp to complain. The only known user of this file is in nfs-utils, which handles non-existence and read-failure equally well. So there is nothing to gain from leaving the file present but inaccessible. So this patch removes the file when its content is not available - i.e. when that config option is not selected. Also remove the #ifdef which hides some of the enum values when CONFIG_NFSD_V$ not selection. simple_fill_super() quietly ignores array entries that are not present, so having slots in the array that don't get used is perfectly acceptable. So there is no value in this #ifdef. Reported-by: Petr Vorel Reviewed-by: Jeff Layton Fixes: 74fd48739d04 ("nfsd: new Kconfig option for legacy client tracking") Signed-off-by: NeilBrown Reviewed-by: Petr Vorel Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 30d91a2ad76afaa73b70176b8f69c127299736b8 Author: Aleksandr Aprelkov Date: Wed Mar 27 14:10:44 2024 +0700 sunrpc: removed redundant procp check [ Upstream commit a576f36971ab4097b6aa76433532aa1fb5ee2d3b ] since vs_proc pointer is dereferenced before getting it's address there's no need to check for NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8e5b67731d08 ("SUNRPC: Add a callback to initialise server requests") Signed-off-by: Aleksandr Aprelkov Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 6f69d9a2e805355e8711f7c5f452727b6c8160c0 Author: Vasant Hegde Date: Mon May 6 08:20:39 2024 +0000 iommu/amd: Enable Guest Translation after reading IOMMU feature register [ Upstream commit de111f6b4f6a3010020825d22a068f416bc29c95 ] Commit 8e0179733172 ("iommu/amd: Enable Guest Translation before registering devices") moved IOMMU Guest Translation (GT) enablement to early init path. It does feature check based on Global EFR value (got from ACPI IVRS table). Later it adjusts EFR value based on IOMMU feature register (late_iommu_features_init()). It seems in some systems BIOS doesn't set gloabl EFR value properly. This is causing mismatch. Hence move IOMMU GT enablement after late_iommu_features_init() so that it does check based on IOMMU EFR value. Fixes: 8e0179733172 ("iommu/amd: Enable Guest Translation before registering devices") Reported-by: Klara Modin Closes: https://lore.kernel.org/linux-iommu/333e6eb6-361c-4afb-8107-2573324bf689@gmail.com/ Signed-off-by: Vasant Hegde Tested-by: Klara Modin Link: https://lore.kernel.org/r/20240506082039.7575-1-vasant.hegde@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ff67c88bb26c555c0861b93cecc35019cbc50fbd Author: Lu Baolu Date: Fri May 3 21:36:02 2024 +0800 iommu/vt-d: Decouple igfx_off from graphic identity mapping [ Upstream commit ba00196ca41c4f6d0b0d3c4a6748a133577abe05 ] A kernel command called igfx_off was introduced in commit ("Intel IOMMU: Intel IOMMU driver"). This command allows the user to disable the IOMMU dedicated to SOC-integrated graphic devices. Commit <9452618e7462> ("iommu/intel: disable DMAR for g4x integrated gfx") used this mechanism to disable the graphic-dedicated IOMMU for some problematic devices. Later, more problematic graphic devices were added to the list by commit <1f76249cc3beb> ("iommu/vt-d: Declare Broadwell igfx dmar support snafu"). On the other hand, commit <19943b0e30b05> ("intel-iommu: Unify hardware and software passthrough support") uses the identity domain for graphic devices if CONFIG_DMAR_BROKEN_GFX_WA is selected. + if (iommu_pass_through) + iommu_identity_mapping = 1; +#ifdef CONFIG_DMAR_BROKEN_GFX_WA + else + iommu_identity_mapping = 2; +#endif ... static int iommu_should_identity_map(struct pci_dev *pdev, int startup) { + if (iommu_identity_mapping == 2) + return IS_GFX_DEVICE(pdev); ... In the following driver evolution, CONFIG_DMAR_BROKEN_GFX_WA and quirk_iommu_igfx() are mixed together, causing confusion in the driver's device_def_domain_type callback. On one hand, dmar_map_gfx is used to turn off the graphic-dedicated IOMMU as a workaround for some buggy hardware; on the other hand, for those graphic devices, IDENTITY mapping is required for the IOMMU core. Commit <4b8d18c0c986> "iommu/vt-d: Remove INTEL_IOMMU_BROKEN_GFX_WA" has removed the CONFIG_DMAR_BROKEN_GFX_WA option, so the IDENTITY_DOMAIN requirement for graphic devices is no longer needed. Therefore, this requirement can be removed from device_def_domain_type() and igfx_off can be made independent. Fixes: 4b8d18c0c986 ("iommu/vt-d: Remove INTEL_IOMMU_BROKEN_GFX_WA") Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240428032020.214616-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 2c8d6e24930b8ef7d4a81787627c559ae0e0d3bb Author: David Hildenbrand Date: Wed Apr 10 17:55:25 2024 +0200 drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() [ Upstream commit 3d6586008f7b638f91f3332602592caa8b00b559 ] Patch series "mm: follow_pte() improvements and acrn follow_pte() fixes". Patch #1 fixes a bunch of issues I spotted in the acrn driver. It compiles, that's all I know. I'll appreciate some review and testing from acrn folks. Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding more sanity checks, and improving the documentation. Gave it a quick test on x86-64 using VM_PAT that ends up using follow_pte(). This patch (of 3): We currently miss handling various cases, resulting in a dangerous follow_pte() (previously follow_pfn()) usage. (1) We're not checking PTE write permissions. Maybe we should simply always require pte_write() like we do for pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for ACRN_MEM_ACCESS_WRITE for now. (2) We're not rejecting refcounted pages. As we are not using MMU notifiers, messing with refcounted pages is dangerous and can result in use-after-free. Let's make sure to reject them. (3) We are only looking at the first PTE of a bigger range. We only lookup a single PTE, but memmap->len may span a larger area. Let's loop over all involved PTEs and make sure the PFN range is actually contiguous. Reject everything else: it couldn't have worked either way, and rather made use access PFNs we shouldn't be accessing. Link: https://lkml.kernel.org/r/20240410155527.474777-1-david@redhat.com Link: https://lkml.kernel.org/r/20240410155527.474777-2-david@redhat.com Fixes: 8a6e85f75a83 ("virt: acrn: obtain pa from VMA with PFNMAP flag") Signed-off-by: David Hildenbrand Cc: Alex Williamson Cc: Christoph Hellwig Cc: Fei Li Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Ingo Molnar Cc: Paolo Bonzini Cc: Yonghua Huang Cc: Sean Christopherson Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c38eaa9bc2ff5c3ca6a3c7cec253296e8c3de699 Author: Christoph Hellwig Date: Mon Mar 25 07:45:40 2024 +0800 virt: acrn: stop using follow_pfn [ Upstream commit 1b265da7ea1e1ae997fa119c2846bb389eb39c6b ] Patch series "remove follow_pfn". This series open codes follow_pfn in the only remaining caller, although the code there remains questionable. It then also moves follow_phys into the only user and simplifies it a bit. This patch (of 3): Switch from follow_pfn to follow_pte so that we can get rid of follow_pfn. Note that this doesn't fix any of the pre-existing raciness and lack of permission checking in the code. Link: https://lkml.kernel.org/r/20240324234542.2038726-1-hch@lst.de Link: https://lkml.kernel.org/r/20240324234542.2038726-2-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: David Hildenbrand Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fei Li Cc: Peter Zijlstra Cc: Ingo Molnar Signed-off-by: Andrew Morton Stable-dep-of: 3d6586008f7b ("drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()") Signed-off-by: Sasha Levin commit 168f6fbde0eabd71d1f4133df7d001a950b96977 Author: Konstantin Taranov Date: Fri Apr 26 06:12:39 2024 -0700 RDMA/mana_ib: boundary check before installing cq callbacks [ Upstream commit f79edef79b6a2161f4124112f9b0c46891bb0b74 ] Add a boundary check inside mana_ib_install_cq_cb to prevent index overflow. Fixes: 2a31c5a7e0d8 ("RDMA/mana_ib: Introduce mana_ib_install_cq_cb helper function") Signed-off-by: Konstantin Taranov Link: https://lore.kernel.org/r/1714137160-5222-5-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6e59dcd5b3340f650a747ca93376c03f281f2947 Author: Konstantin Taranov Date: Tue Mar 26 13:08:06 2024 -0700 RDMA/mana_ib: Use struct mana_ib_queue for CQs [ Upstream commit 60a7ac0b8bec5df9764b7460ffee91fc981e8a31 ] Use struct mana_ib_queue and its helpers for CQs Signed-off-by: Konstantin Taranov Link: https://lore.kernel.org/r/1711483688-24358-3-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks") Signed-off-by: Sasha Levin commit 57de310151b179876e583fdde3663927098467c9 Author: Konstantin Taranov Date: Tue Mar 26 13:08:05 2024 -0700 RDMA/mana_ib: Introduce helpers to create and destroy mana queues [ Upstream commit 46f5be7cd4bceb3a503c544b3dab7b75fe4bb96b ] Intoduce helpers to work with mana ib queues (struct mana_ib_queue). A queue always consists of umem, gdma_region, and id. A queue can become a WQ or a CQ. Signed-off-by: Konstantin Taranov Link: https://lore.kernel.org/r/1711483688-24358-2-git-send-email-kotaranov@linux.microsoft.com Reviewed-by: Long Li Signed-off-by: Leon Romanovsky Stable-dep-of: f79edef79b6a ("RDMA/mana_ib: boundary check before installing cq callbacks") Signed-off-by: Sasha Levin commit 4f702721c6b1933977cafdf6066bf305c44ea5d5 Author: Jan Kara Date: Thu Mar 7 12:53:20 2024 +0100 ext4: avoid excessive credit estimate in ext4_tmpfile() [ Upstream commit 35a1f12f0ca857fee1d7a04ef52cbd5f1f84de13 ] A user with minimum journal size (1024 blocks these days) complained about the following error triggered by generic/697 test in ext4_tmpfile(): run fstests generic/697 at 2024-02-28 05:34:46 JBD2: vfstest wants too many credits credits:260 rsv_credits:0 max:256 EXT4-fs error (device loop0) in __ext4_new_inode:1083: error 28 Indeed the credit estimate in ext4_tmpfile() is huge. EXT4_MAXQUOTAS_INIT_BLOCKS() is 219, then 10 credits from ext4_tmpfile() itself and then ext4_xattr_credits_for_new_inode() adds more credits needed for security attributes and ACLs. Now the EXT4_MAXQUOTAS_INIT_BLOCKS() is in fact unnecessary because we've already initialized quotas with dquot_init() shortly before and so EXT4_MAXQUOTAS_TRANS_BLOCKS() is enough (which boils down to 3 credits). Fixes: af51a2ac36d1 ("ext4: ->tmpfile() support") Signed-off-by: Jan Kara Tested-by: Luis Henriques Tested-by: Disha Goel Link: https://lore.kernel.org/r/20240307115320.28949-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 83bd32a7a593330709550a802b9c10016699b830 Author: Adrian Hunter Date: Thu May 2 13:58:46 2024 +0300 x86/insn: Add VEX versions of VPDPBUSD, VPDPBUSDS, VPDPWSSD and VPDPWSSDS [ Upstream commit b8000264348979b60dbe479255570a40e1b3a097 ] The x86 instruction decoder is used not only for decoding kernel instructions. It is also used by perf uprobes (user space probes) and by perf tools Intel Processor Trace decoding. Consequently, it needs to support instructions executed by user space also. Intel Architecture Instruction Set Extensions and Future Features manual number 319433-044 of May 2021, documented VEX versions of instructions VPDPBUSD, VPDPBUSDS, VPDPWSSD and VPDPWSSDS, but the opcode map has them listed as EVEX only. Remove EVEX-only (ev) annotation from instructions VPDPBUSD, VPDPBUSDS, VPDPWSSD and VPDPWSSDS, which allows them to be decoded with either a VEX or EVEX prefix. Fixes: 0153d98f2dd6 ("x86/insn: Add misc instructions to x86 instruction decoder") Signed-off-by: Adrian Hunter Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240502105853.5338-4-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 88ecd5434422d6652aa19b67e87e12b30f65fb92 Author: Adrian Hunter Date: Thu May 2 13:58:45 2024 +0300 x86/insn: Fix PUSH instruction in x86 instruction decoder opcode map [ Upstream commit 59162e0c11d7257cde15f907d19fefe26da66692 ] The x86 instruction decoder is used not only for decoding kernel instructions. It is also used by perf uprobes (user space probes) and by perf tools Intel Processor Trace decoding. Consequently, it needs to support instructions executed by user space also. Opcode 0x68 PUSH instruction is currently defined as 64-bit operand size only i.e. (d64). That was based on Intel SDM Opcode Map. However that is contradicted by the Instruction Set Reference section for PUSH in the same manual. Remove 64-bit operand size only annotation from opcode 0x68 PUSH instruction. Example: $ cat pushw.s .global _start .text _start: pushw $0x1234 mov $0x1,%eax # system call number (sys_exit) int $0x80 $ as -o pushw.o pushw.s $ ld -s -o pushw pushw.o $ objdump -d pushw | tail -4 0000000000401000 <.text>: 401000: 66 68 34 12 pushw $0x1234 401004: b8 01 00 00 00 mov $0x1,%eax 401009: cd 80 int $0x80 $ perf record -e intel_pt//u ./pushw [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.014 MB perf.data ] Before: $ perf script --insn-trace=disasm Warning: 1 instruction trace errors pushw 10349 [000] 10586.869237014: 401000 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) pushw $0x1234 pushw 10349 [000] 10586.869237014: 401006 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb %al, (%rax) pushw 10349 [000] 10586.869237014: 401008 [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb %cl, %ch pushw 10349 [000] 10586.869237014: 40100a [unknown] (/home/ahunter/git/misc/rtit-tests/pushw) addb $0x2e, (%rax) instruction trace error type 1 time 10586.869237224 cpu 0 pid 10349 tid 10349 ip 0x40100d code 6: Trace doesn't match instruction After: $ perf script --insn-trace=disasm pushw 10349 [000] 10586.869237014: 401000 [unknown] (./pushw) pushw $0x1234 pushw 10349 [000] 10586.869237014: 401004 [unknown] (./pushw) movl $1, %eax Fixes: eb13296cfaf6 ("x86: Instruction decoder API") Signed-off-by: Adrian Hunter Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240502105853.5338-3-adrian.hunter@intel.com Signed-off-by: Sasha Levin commit 98a1cfa29fc2049227806561753ab46ebfef3e90 Author: Marc Gonzalez Date: Thu Apr 25 17:07:07 2024 +0200 clk: qcom: mmcc-msm8998: fix venus clock issue [ Upstream commit e20ae5ae9f0c843aded4f06f3d1cab7384789e92 ] Right now, msm8998 video decoder (venus) is non-functional: $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm (+) Video --vid=1 (*) (vp9 854x480 29.970fps) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) [ffmpeg/video] vp9_v4l2m2m: output VIDIOC_REQBUFS failed: Connection timed out [ffmpeg/video] vp9_v4l2m2m: no v4l2 output context's buffers [ffmpeg/video] vp9_v4l2m2m: can't configure decoder Could not open codec. Software decoding fallback is disabled. Exiting... (Quit) Bryan O'Donoghue suggested the proper fix: - Set required register offsets in venus GDSC structs. - Set HW_CTRL flag. $ time mpv --hwdec=v4l2m2m-copy --vd-lavc-software-fallback=no --vo=null --no-audio --untimed --length=30 --quiet demo-480.webm (+) Video --vid=1 (*) (vp9 854x480 29.970fps) Audio --aid=1 --alang=eng (*) (opus 2ch 48000Hz) [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl [ffmpeg/video] vp9_v4l2m2m: VIDIOC_G_FMT ioctl ... Using hardware decoding (v4l2m2m-copy). VO: [null] 854x480 nv12 Exiting... (End of file) real 0m3.315s user 0m1.277s sys 0m0.453s NOTES: GDSC = Globally Distributed Switch Controller Use same code as mmcc-msm8996 with: s/venus_gdsc/video_top_gdsc/ s/venus_core0_gdsc/video_subcore0_gdsc/ s/venus_core1_gdsc/video_subcore1_gdsc/ https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8996.h https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/include/dt-bindings/clock/msm-clocks-hwio-8998.h 0x1024 = MMSS_VIDEO GDSCR (undocumented) 0x1028 = MMSS_VIDEO_CORE_CBCR 0x1030 = MMSS_VIDEO_AHB_CBCR 0x1034 = MMSS_VIDEO_AXI_CBCR 0x1038 = MMSS_VIDEO_MAXI_CBCR 0x1040 = MMSS_VIDEO_SUBCORE0 GDSCR (undocumented) 0x1044 = MMSS_VIDEO_SUBCORE1 GDSCR (undocumented) 0x1048 = MMSS_VIDEO_SUBCORE0_CBCR 0x104c = MMSS_VIDEO_SUBCORE1_CBCR Fixes: d14b15b5931c2b ("clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver") Reviewed-by: Bryan O'Donoghue Signed-off-by: Marc Gonzalez Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/ff4e2e34-a677-4c39-8c29-83655c5512ae@freebox.fr Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 37dcba7be735343582c4af5e8c644683b06a5a71 Author: Dmitry Baryshkov Date: Wed Apr 24 04:39:32 2024 +0300 clk: qcom: dispcc-sm8650: fix DisplayPort clocks [ Upstream commit 615a292ee4d51303246278f3fa33cc38700fe00e ] On SM8650 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display af54000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 9e939f008338 ("clk: qcom: add the SM8650 Display Clock Controller driver") Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong # on SM8650-HDK Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-4-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da04b9a4610473289b8617e9f4694284846c27a8 Author: Dmitry Baryshkov Date: Wed Apr 24 04:39:31 2024 +0300 clk: qcom: dispcc-sm8550: fix DisplayPort clocks [ Upstream commit e90b5139da8465a15c3820b4b67ca9468dce93b4 ] On SM8550 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 90114ca11476 ("clk: qcom: add SM8550 DISPCC driver") Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong # on SM8550-HDK Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-3-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7e75e4c6958ad0a74db73f672f624ed11a8c8802 Author: Dmitry Baryshkov Date: Wed Apr 24 04:39:30 2024 +0300 clk: qcom: dispcc-sm6350: fix DisplayPort clocks [ Upstream commit 1113501cfb46d5c0eb960f0a8a9f6c0f91dc6fb6 ] On SM6350 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Reviewed-by: Neil Armstrong Tested-by: Luca Weiss Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-2-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 0fc8caa556376db2473ad455fa27e4125a1e7a1e Author: Dmitry Baryshkov Date: Wed Apr 24 04:39:29 2024 +0300 clk: qcom: dispcc-sm8450: fix DisplayPort clocks [ Upstream commit e801038a02ce1e8c652a0b668dd233a4ee48aeb7 ] On SM8450 DisplayPort link clocks use frequency tables inherited from the vendor kernel, it is not applicable in the upstream kernel. Drop frequency tables and use clk_byte2_ops for those clocks. This fixes frequency selection in the OPP core (which otherwise attempts to use invalid 810 KHz as DP link rate), also fixing the following message: msm-dp-display ae90000.displayport-controller: _opp_config_clk_single: failed to set clock rate: -22 Fixes: 16fb89f92ec4 ("clk: qcom: Add support for Display Clock Controller on SM8450") Reviewed-by: Neil Armstrong Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240424-dispcc-dp-clocks-v2-1-b44038f3fa96@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a08d94502b25ecd181338909a56322cf58197c70 Author: Jinjiang Tu Date: Thu Mar 28 19:10:08 2024 +0800 mm/ksm: fix ksm exec support for prctl [ Upstream commit 3a9e567ca45fb5280065283d10d9a11f0db61d2b ] Patch series "mm/ksm: fix ksm exec support for prctl", v4. commit 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") inherits MMF_VM_MERGE_ANY flag when a task calls execve(). However, it doesn't create the mm_slot, so ksmd will not try to scan this task. The first patch fixes the issue. The second patch refactors to prepare for the third patch. The third patch extends the selftests of ksm to verfity the deduplication really happens after fork/exec inherits ths KSM setting. This patch (of 3): commit 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") inherits MMF_VM_MERGE_ANY flag when a task calls execve(). Howerver, it doesn't create the mm_slot, so ksmd will not try to scan this task. To fix it, allocate and add the mm_slot to ksm_mm_head in __bprm_mm_init() when the mm has MMF_VM_MERGE_ANY flag. Link: https://lkml.kernel.org/r/20240328111010.1502191-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20240328111010.1502191-2-tujinjiang@huawei.com Fixes: 3c6f33b7273a ("mm/ksm: support fork/exec for prctl") Signed-off-by: Jinjiang Tu Reviewed-by: David Hildenbrand Cc: Johannes Weiner Cc: Kefeng Wang Cc: Nanyong Sun Cc: Rik van Riel Cc: Stefan Roesch Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc Author: Duoming Zhou Date: Tue Mar 12 08:59:05 2024 +0800 lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure [ Upstream commit c2af060d1c18beaec56351cf9c9bcbbc5af341a3 ] The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations. Link: https://lkml.kernel.org/r/20240312005905.9939-1-duoming@zju.edu.cn Fixes: b2ef9f5a5cb3 ("mm/hmm/test: add selftest driver for HMM") Signed-off-by: Duoming Zhou Cc: Jérôme Glisse Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 8134c37caa164f2f9702cd415bafb6458a40f51e Author: Lad Prabhakar Date: Wed Apr 3 21:09:52 2024 +0100 clk: renesas: r9a07g043: Add clock and reset entry for PLIC [ Upstream commit 44019387fce230beda35b83da3a2c9fc5787704e ] Add the missing clock and reset entry for PLIC. Also add R9A07G043_NCEPLIC_ACLK to the critical clocks list. Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240403200952.633084-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 192dd0b04aa8aa68d576aabb2ce4ff6dc903c003 Author: Geert Uytterhoeven Date: Tue Apr 16 17:00:51 2024 +0200 clk: renesas: r8a779a0: Fix CANFD parent clock [ Upstream commit 3b23118bdbd898dc2f4de8f549d598d492c42ba8 ] According to Figure 52A.1 ("RS-CANFD Module Block Diagram (in classical CAN mode)") in the R-Car V3U Series User’s Manual Rev. 0.5, the parent clock for the CANFD peripheral module clock is the S3D2 clock. Fixes: 9b621b6adff53346 ("clk: renesas: r8a779a0: Add CANFD module clock") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/aef9300f44c9141b1465343f91c5cc7303249b6e.1713279523.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit e028ff4c34c5a85f57a69f752b2fee1560950448 Author: Jason Gunthorpe Date: Thu Apr 11 13:46:19 2024 -0300 IB/mlx5: Use __iowrite64_copy() for write combining stores [ Upstream commit ef302283ddfceaba2657923af3f90fd58e6dff06 ] mlx5 has a built in self-test at driver startup to evaluate if the platform supports write combining to generate a 64 byte PCIe TLP or not. This has proven necessary because a lot of common scenarios end up with broken write combining (especially inside virtual machines) and there is other way to learn this information. This self test has been consistently failing on new ARM64 CPU designs (specifically with NVIDIA Grace's implementation of Neoverse V2). The C loop around writeq() generates some pretty terrible ARM64 assembly, but historically this has worked on a lot of existing ARM64 CPUs till now. We see it succeed about 1 time in 10,000 on the worst effected systems. The CPU architects speculate that the load instructions interspersed with the stores makes the WC buffers statistically flush too often and thus the generation of large TLPs becomes infrequent. This makes the boot up test unreliable in that it indicates no write-combining, however userspace would be fine since it uses a ST4 instruction. Further, S390 has similar issues where only the special zpci_memcpy_toio() will actually generate large TLPs, and the open coded loop does not trigger it at all. Fix both ARM64 and S390 by switching to __iowrite64_copy() which now provides architecture specific variants that have a high change of generating a large TLP with write combining. x86 continues to use a similar writeq loop in the generate __iowrite64_copy(). Fixes: 11f552e21755 ("IB/mlx5: Test write combining support") Link: https://lore.kernel.org/r/6-v3-1893cd8b9369+1925-mlx5_arm_wc_jgg@nvidia.com Tested-by: Niklas Schnelle Acked-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4fa07c3f1730aed3559a30b32ce6dc5d645f86da Author: Bob Pearson Date: Fri Mar 29 09:55:12 2024 -0500 RDMA/rxe: Fix incorrect rxe_put in error path [ Upstream commit 8776618dbbd1b6f210b31509507e1aad461d6435 ] In rxe_send() a ref is taken on the qp to keep it alive until the kfree_skb() has a chance to call the skb destructor rxe_skb_tx_dtor() which drops the reference. If the packet has an incorrect protocol the error path just calls kfree_skb() which will call the destructor which will drop the ref. Currently the driver also calls rxe_put() which is incorrect. Additionally since the packets sent to rxe_send() are under the control of the driver and it only ever produces IPV4 or IPV6 packets the simplest fix is to remove all the code in this block. Link: https://lore.kernel.org/r/20240329145513.35381-12-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Fixes: 9eb7f8e44d13 ("IB/rxe: Move refcounting earlier in rxe_send()") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e6b04fa993f48f703c7b2af21bc6f268a4396433 Author: Bob Pearson Date: Fri Mar 29 09:55:05 2024 -0500 RDMA/rxe: Allow good work requests to be executed [ Upstream commit b703374837a8f8422fa3f1edcf65505421a65a6a ] A previous commit incorrectly added an 'if(!err)' before scheduling the requester task in rxe_post_send_kernel(). But if there were send wrs successfully added to the send queue before a bad wr they might never get executed. This commit fixes this by scheduling the requester task if any wqes were successfully posted in rxe_post_send_kernel() in rxe_verbs.c. Link: https://lore.kernel.org/r/20240329145513.35381-5-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 30df4bef8b8e183333e9b6e9d4509d552c7da6eb Author: Bob Pearson Date: Fri Mar 29 09:55:04 2024 -0500 RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt [ Upstream commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 ] In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale. This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed. Link: https://lore.kernel.org/r/20240329145513.35381-4-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats") Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 7e4ff475cf2b5dc498508509968f2d606777f7df Author: Tudor Ambarus Date: Fri Apr 19 10:09:15 2024 +0000 clk: samsung: gs101: propagate PERIC1 USI SPI clock rate [ Upstream commit 7cf0324ba0bc61a8c360d23d284e06d2994b1fef ] When SPI transfer is being prepared, the spi-s3c64xx driver will call clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK is a gate (leaf) clock, so it must propagate the rate change up the clock tree, so that corresponding MUX/DIV clocks can actually change their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for all USI instances in GS101 PERIC1: USI{0, 9, 10, 11, 12, 13}. This change involves the following clocks: PERIC1 USI*: Clock Div range MUX Selection ------------------------------------------------------------------- gout_peric1_peric1_top0_ipclk_* - - dout_peric1_usi*_usi /1..16 - mout_peric1_usi*_usi_user - {24.5 MHz, 400 MHz} With input clock of 400 MHz this scheme provides the following IPCLK rate range, for each USI block: PERIC1 USI*: 1.5 MHz ... 400 MHz Accounting for internal /4 divider in SPI blocks, and because the max SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates: PERIC1 USI_SPI*: 384 KHz ... 49.9 MHz Which shall be fine for the applications of the SPI bus. Note that with this we allow the reparenting of the MUX_USIx clocks to OSCCLK. Each instance of the USI IP has its own MUX_USI clock, thus the reparenting of a MUX_USI clock corresponds to a single instance of the USI IP. The datasheet mentions OSCCLK just in the low-power mode context, but the downstream driver reparents too the MUX_USI clocks to OSCCLK. Follow the downstream driver and do the same. Fixes: 2999e786d7e9 ("clk: samsung: gs101: add support for cmu_peric1") Reviewed-by: Peter Griffin Acked-by: André Draszik Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240419100915.2168573-3-tudor.ambarus@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 12c46ebda8e316d5afe18c1d1277b83089b49f55 Author: Tudor Ambarus Date: Fri Apr 19 10:09:14 2024 +0000 clk: samsung: gs101: propagate PERIC0 USI SPI clock rate [ Upstream commit 7b54d9113cd4923432c0b2441c5e2663873b4e5b ] Introduce nMUX() for MUX clocks that can be reparented on clock rate change. "nMUX" comes from "n-to-1 selector", hopefully emphasising that the selector can change on clock rate changes. Ideally MUX/MUX_F() should change to not have the CLK_SET_RATE_NO_REPARENT flag set by default, and all their users to be updated to add the flag back (like in the case of DIV and GATE). But this is a very intrusive change and because for now only GS101 allows MUX reparenting on clock rate change, stick with nMUX(). GS101 defines MUX clocks that are dedicated for each instance of the IP. One example is USI IP (SPI, I2C, serial). The reparenting of these MUX clocks will not affect other instances of the same IP or different IPs altogether. When SPI transfer is being prepared, the spi-s3c64xx driver will call clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK is a gate (leaf) clock, so it must propagate the rate change up the clock tree, so that corresponding MUX/DIV clocks can actually change their values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for all USI instances in GS101 PERIC0: USI{1-8, 14}. This change involves the following clocks: PERIC0 USI*: Clock Div range MUX Selection ------------------------------------------------------------------- gout_peric0_peric0_top0_ipclk_* - - dout_peric0_usi*_usi /1..16 - mout_peric0_usi*_usi_user - {24.5 MHz, 400 MHz} With input clock of 400 MHz this scheme provides the following IPCLK rate range, for each USI block: PERIC0 USI*: 1.5 MHz ... 400 MHz Accounting for internal /4 divider in SPI blocks, and because the max SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates: PERIC0 USI_SPI*: 384 KHz ... 49.9 MHz Fixes: 893f133a040b ("clk: samsung: gs101: add support for cmu_peric0") Reviewed-by: Peter Griffin Acked-by: André Draszik Signed-off-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240419100915.2168573-2-tudor.ambarus@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 90f852809f38090caba76ed0c884b88cf9a640ff Author: Gabor Juhos Date: Mon Mar 11 19:45:19 2024 +0100 clk: qcom: clk-alpha-pll: remove invalid Stromer register offset [ Upstream commit 4f2bc4acbb1916b8cd2ce4bb3ba7b1cd7cb705fa ] The offset of the CONFIG_CTL_U register defined for the Stromer PLL is wrong. It is not aligned on a 4 bytes boundary which might causes errors in regmap operations. Maybe the intention behind of using the 0xff value was to indicate that the register is not implemented in the PLL, but this is not verified anywhere in the code. Moreover, this value is not used even in other register offset arrays despite that those PLLs also have unimplemented registers. Additionally, on the Stromer PLLs the current code only touches the CONFIG_CTL_U register if the result of pll_has_64bit_config() is true which condition is not affected by the change. Due to the reasons above, simply remove the CONFIG_CTL_U entry from the Stromer specific array. Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs") Signed-off-by: Gabor Juhos Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240311-alpha-pll-stromer-cleanup-v1-1-f7c0c5607cca@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9f885cea07bafb3e7c6cfedeccc88e94b82fc5d4 Author: Catalin Popescu Date: Mon Apr 15 16:03:48 2024 +0200 clk: rs9: fix wrong default value for clock amplitude [ Upstream commit 1758c68c81b8b881818fcebaaeb91055362a82f8 ] According to 9FGV0241, 9FGV0441 & 9FGV0841 datasheets, the default value for the clock amplitude is 0.8V, while the driver assumes 0.7V. Additionally, define constants for default values for both clock amplitude and spread spectrum and use them. Fixes: 892e0ddea1aa ("clk: rs9: Add Renesas 9-series PCIe clock generator driver") Signed-off-by: Catalin Popescu Reviewed-by: Marek Vasut Link: https://lore.kernel.org/r/20240415140348.2887619-1-catalin.popescu@leica-geosystems.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 524d555e76d0d56838c3012183335dac77fea33b Author: Alexandre Mergnat Date: Thu Apr 18 16:17:00 2024 +0200 clk: mediatek: mt8365-mm: fix DPI0 parent [ Upstream commit 4c0c087772d7e29bc2489ddb068d5167140bfc38 ] To have a working display through DPI, a workaround has been implemented downstream to add "mm_dpi0_dpi0" and "dpi0_sel" to the DPI node. Shortly, that add an extra clock. It seems consistent to have the "dpi0_sel" as parent. Additionnaly, "vpll_dpix" isn't used/managed. Then, set the "mm_dpi0_dpi0" parent clock to "dpi0_sel". The new clock tree is: clk26m lvdspll lvdspll_X (2, 4, 8, 16) dpi0_sel mm_dpi0_dpi0 Fixes: d46adccb7966 ("clk: mediatek: add driver for MT8365 SoC") Signed-off-by: Alexandre Mergnat Link: https://lore.kernel.org/r/20231023-display-support-v3-12-53388f3ed34b@baylibre.com Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 06cf121346bbd3d83a5eea05bb87666c6b279990 Author: Chengchang Tang Date: Fri Apr 12 17:16:16 2024 +0800 RDMA/hns: Modify the print level of CQE error [ Upstream commit 349e859952285ab9689779fb46de163f13f18f43 ] Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level. Fixes: 7c044adca272 ("RDMA/hns: Simplify the cqe code of poll cq") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-11-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 8723e8b21e71aacb9ba0d65864ebb433e6338b40 Author: Chengchang Tang Date: Fri Apr 12 17:16:15 2024 +0800 RDMA/hns: Use complete parentheses in macros [ Upstream commit 4125269bb9b22e1d8cdf4412c81be8074dbc61ca ] Use complete parentheses to ensure that macro expansion does not produce unexpected results. Fixes: a25d13cbe816 ("RDMA/hns: Add the interfaces to support multi hop addressing for the contexts in hip08") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-10-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit a217037eb63190614e9700f6fe5f5f3830e0ef82 Author: Chengchang Tang Date: Fri Apr 12 17:16:13 2024 +0800 RDMA/hns: Fix GMV table pagesize [ Upstream commit ee045493283403969591087bd405fa280103282a ] GMV's BA table only supports 4K pages. Currently, PAGESIZE is used to calculate gmv_bt_num, which will cause an abnormal number of gmv_bt_num in a 64K OS. Fixes: d6d91e46210f ("RDMA/hns: Add support for configuring GMV table") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-8-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ba8112cff00a217b5d182e6caaccc3f619bd3c94 Author: wenglianfa Date: Fri Apr 12 17:16:12 2024 +0800 RDMA/hns: Fix mismatch exception rollback [ Upstream commit dc3bda6e568e9310b7cd07769dd70a3f0cd696ca ] When dma_alloc_coherent() fails in hns_roce_alloc_hem(), just call kfree() to release hem instead of hns_roce_free_hem(). Fixes: c00743cbf2b8 ("RDMA/hns: Simplify 'struct hns_roce_hem' allocation") Signed-off-by: wenglianfa Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-7-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 37a7559dc1358a8d300437e99ed8ecdab0671507 Author: Chengchang Tang Date: Fri Apr 12 17:16:11 2024 +0800 RDMA/hns: Fix UAF for cq async event [ Upstream commit a942ec2745ca864cd8512142100e4027dc306a42 ] The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d271e66abac5c7eb8de345b9b44d89f777437a4c Author: Chengchang Tang Date: Fri Apr 12 17:16:10 2024 +0800 RDMA/hns: Fix deadlock on SRQ async events. [ Upstream commit b46494b6f9c19f141114a57729e198698f40af37 ] xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. Fixes: 81fce6291d99 ("RDMA/hns: Add SRQ asynchronous event support") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 28f051d5ec4cac7db53a885eba0010a7cd5227e1 Author: Chengchang Tang Date: Fri Apr 12 17:16:09 2024 +0800 RDMA/hns: Add max_ah and cq moderation capacities in query_device() [ Upstream commit 2ce384307f2ddf39dc662878e151722199afc9ae ] Add max_ah and cq moderation capacities to hns_roce_query_device(). Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang Signed-off-by: Junxian Huang Link: https://lore.kernel.org/r/20240412091616.370789-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f935def55a10e148ac30a0ba4fdaa6ace09d6c4e Author: Zhengchao Shao Date: Thu Apr 11 11:38:51 2024 +0800 RDMA/hns: Fix return value in hns_roce_map_mr_sg [ Upstream commit 203b70fda63425a4eb29f03f9074859afe821a39 ] As described in the ib_map_mr_sg function comment, it returns the number of sg elements that were mapped to the memory region. However, hns_roce_map_mr_sg returns the number of pages required for mapping the DMA area. Fix it. Fixes: 9b2cf76c9f05 ("RDMA/hns: Optimize PBL buffer allocation process") Signed-off-by: Zhengchao Shao Link: https://lore.kernel.org/r/20240411033851.2884771-1-shaozhengchao@huawei.com Reviewed-by: Junxian Huang Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ef9e376d482f86809989c73ebe8cc2d50a9fdbd5 Author: Yi Liu Date: Thu Mar 28 05:29:57 2024 -0700 iommu: Undo pasid attachment only for the devices that have succeeded [ Upstream commit b025dea63cded0d82bccd591fa105d39efc6435d ] There is no error handling now in __iommu_set_group_pasid(), it relies on its caller to loop all the devices to undo the pasid attachment. This is not self-contained and has drawbacks. It would result in unnecessary remove_dev_pasid() calls on the devices that have not been attached to the new domain. But the remove_dev_pasid() callback would get the new domain from the group->pasid_array. So for such devices, the iommu driver won't find the attachment under the domain, hence unable to do cleanup. This may not be a real problem today. But it depends on the implementation of the underlying iommu driver. e.g. the intel iommu driver would warn for such devices. Such warnings are unnecessary. To solve the above problem, it is necessary to handle the error within __iommu_set_group_pasid(). It only loops the devices that have attached to the new domain, and undo it. Fixes: 16603704559c ("iommu: Add attach/detach_dev_pasid iommu interfaces") Suggested-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Signed-off-by: Yi Liu Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/20240328122958.83332-2-yi.l.liu@intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit d998108a04688073bf80b8f18cdade1c67bbce1d Author: Nícolas F. R. A. Prado Date: Fri Mar 8 15:29:56 2024 -0500 clk: mediatek: pllfh: Don't log error for missing fhctl node [ Upstream commit bb7b3c8e7180f36de75cdea200ab7127f93f58cc ] Support for fhctl clocks in apmixedsys was introduced at a later point and to this moment only one mt6795 based platform has a fhctl DT node present. Therefore the fhctl support in apmixedsys should be seen as optional and not cause an error when it is missing. Change the message's log level to warning. The warning level is chosen so that it will still alert the fact that fhctl support might be unintentionally missing, but without implying that this is necessarily an issue. Even if the FHCTL DT nodes are added to all current platforms moving forward, since those changes won't be backported, this ensures stable kernel releases won't have live with this error. Fixes: d7964de8a8ea ("clk: mediatek: Add new clock driver to handle FHCTL hardware") Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20240308-mtk-fhctl-no-node-error-v1-1-51e446eb149a@collabora.com Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 959a831e1eea7262bf0df9463ca885202afec831 Author: Or Har-Toov Date: Wed Apr 3 13:36:01 2024 +0300 RDMA/mlx5: Adding remote atomic access flag to updatable flags [ Upstream commit 2ca7e93bc963d9ec2f5c24d117176851454967af ] Currently IB_ACCESS_REMOTE_ATOMIC is blocked from being updated via UMR although in some cases it should be possible. These cases are checked in mlx5r_umr_can_reconfig function. Fixes: ef3642c4f54d ("RDMA/mlx5: Fix error unwinds for rereg_mr") Signed-off-by: Or Har-Toov Link: https://lore.kernel.org/r/24dac73e2fa48cb806f33a932d97f3e402a5ea2c.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit da415a205eaa7a04eb28e87cf0f29e6ea2b4a45b Author: Or Har-Toov Date: Wed Apr 3 13:36:00 2024 +0300 RDMA/mlx5: Change check for cacheable mkeys [ Upstream commit 8c1185fef68cc603b954fece2a434c9f851d6a86 ] umem can be NULL for user application mkeys in some cases. Therefore umem can't be used for checking if the mkey is cacheable and it is changed for checking a flag that indicates it. Also make sure that all mkeys which are not returned to the cache will be destroyed. Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow") Signed-off-by: Or Har-Toov Link: https://lore.kernel.org/r/2690bc5c6896bcb937f89af16a1ff0343a7ab3d0.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 85bb348cf0f843b306c713350d0eb7c9da8ec3cc Author: Or Har-Toov Date: Wed Apr 3 13:35:59 2024 +0300 RDMA/mlx5: Uncacheable mkey has neither rb_key or cache_ent [ Upstream commit 0611a8e8b475fc5230b9a24d29c8397aaab20b63 ] As some mkeys can't be modified with UMR due to some UMR limitations, like the size of translation that can be updated, not all user mkeys can be cached. Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow") Signed-off-by: Or Har-Toov Link: https://lore.kernel.org/r/f2742dd934ed73b2d32c66afb8e91b823063880c.1712140377.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bacf2b4446735aad42a8c3ecf2b1326130e89377 Author: Jaewon Kim Date: Thu Mar 28 18:10:00 2024 +0900 clk: samsung: exynosautov9: fix wrong pll clock id value [ Upstream commit 04ee3a0b44e3d18cf6b0c712d14b98624877fd26 ] All PLL id values of CMU_TOP were incorrectly set to FOUT_SHARED0_PLL. It modified to the correct PLL clock id value. Fixes: 6587c62f69dc ("clk: samsung: add top clock support for Exynos Auto v9 SoC") Signed-off-by: Jaewon Kim Reviewed-by: Sam Protsenko Link: https://lore.kernel.org/r/20240328091000.17660-1-jaewon02.kim@samsung.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit ae96311b0e4e2d08b1c989dd8fcb1df946eec8ed Author: Thomas Weißschuh Date: Fri Mar 29 09:18:29 2024 +0100 power: supply: core: simplify charge_behaviour formatting [ Upstream commit 91b623cda43e449a49177ba99b6723f551a4bfbe ] The function power_supply_show_charge_behaviour() is not needed and can be removed completely. Removing the function also saves a spurious read of the property from the driver on each call. The convulted logic was a leftover from an earlier patch revision. Some restructuring made this cleanup possible. Suggested-by: Hans de Goede Link: https://lore.kernel.org/all/9e035ae4-cb07-4f84-8336-1a0050855bea@redhat.com/ Fixes: 4e61f1e9d58f ("power: supply: core: fix charge_behaviour formatting") Signed-off-by: Thomas Weißschuh Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20240329-power-supply-simplify-v1-1-416f1002739f@weissschuh.net Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 9dc1df604826126f4f596492f21270ce126e009b Author: Pratyush Yadav Date: Fri Feb 23 13:53:01 2024 +0530 media: cadence: csi2rx: configure DPHY before starting source stream [ Upstream commit fd64dda48f7e3f67ada1e1fe47e784ab350da72e ] When the source device is operating above 1.5 Gbps per lane, it needs to send the Skew Calibration Sequence before sending any HS data. If the DPHY is initialized after the source stream is started, then it might miss the sequence and not be able to receive data properly. Move the start of source subdev to the end of the sequence to make sure everything is ready to receive data before the source starts streaming. Signed-off-by: Pratyush Yadav Fixes: 3295cf1241d3 ("media: cadence: Add support for external dphy") Tested-by: Julien Massot Tested-by: Changhuang Liang Reviewed-by: Julien Massot Reviewed-by: Changhuang Liang Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3092ef7774535d6b5df4bdc4313ab5dc1ebcd58a Author: Ville Syrjälä Date: Wed Apr 10 21:01:39 2024 +0300 drm/edid: Parse topology block for all DispID structure v1.x [ Upstream commit e0a200ab4b72afd581bd6f82fc1ef510a4fb5478 ] DisplayID spec v1.3 revision history notes do claim that the toplogy block was added in v1.3 so requiring structure v1.2 would seem correct, but there is at least one EDID in edid.tv with a topology block and structure v1.0. And there are also EDIDs with DisplayID structure v1.3 which seems to be totally incorrect as DisplayID spec v1.3 lists structure v1.2 as the only legal value. Unfortunately I couldn't find copies of DisplayID spec v1.0-v1.2 anywhere (even on vesa.org), so I'll have to go on empirical evidence alone. We used to parse the topology block on all v1.x structures until the check for structure v2.0 was added. Let's go back to doing that as the evidence does suggest that there are DisplayIDs in the wild that would miss out on the topology stuff otherwise. Also toss out DISPLAY_ID_STRUCTURE_VER_12 entirely as it doesn't appear we can really use it for anything. I *think* we could technically skip all the structure version checks as the block tags shouldn't conflict between v2.0 and v1.x. But no harm in having a bit of extra sanity checks I guess. So far I'm not aware of any user reported regressions from overly strict check, but I do know that it broke igt/kms_tiled_display's fake DisplayID as that one gets generated with structure v1.0. Cc: Jani Nikula Cc: Dmitry Osipenko Fixes: c5a486af9df7 ("drm/edid: parse Tiled Display Topology Data Block for DisplayID 2.0") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20240410180139.21352-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula Signed-off-by: Sasha Levin commit 65e964bc97098785bda49b4176a56a14902902b4 Author: Atish Patra Date: Sat Apr 20 08:17:17 2024 -0700 RISC-V: Fix the typo in Scountovf CSR name [ Upstream commit d1927f64e0e1094f296842e127138cb5f3bf3c6d ] The counter overflow CSR name is "scountovf" not "sscountovf". Fix the csr name. Fixes: 4905ec2fb7e6 ("RISC-V: Add sscofpmf extension support") Reviewed-by: Clément Léger Reviewed-by: Conor Dooley Reviewed-by: Anup Patel Reviewed-by: Andrew Jones Acked-by: Palmer Dabbelt Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/20240420151741.962500-2-atishp@rivosinc.com Signed-off-by: Anup Patel Signed-off-by: Sasha Levin commit ee4ff1b25b6668775fc16513420b684eb9f5d2d4 Author: Detlev Casanova Date: Sun Apr 14 14:27:06 2024 -0400 drm/rockchip: vop2: Do not divide height twice for YUV [ Upstream commit e80c219f52861e756181d7f88b0d341116daac2b ] For the cbcr format, gt2 and gt4 are computed again after src_h has been divided by vsub. As src_h as already been divided by 2 before, introduce cbcr_src_h and cbcr_src_w to keep a copy of those values to be used for cbcr gt2 and gt4 computation. This fixes yuv planes being unaligned vertically when down scaling to 1080 pixels from 2160. Signed-off-by: Detlev Casanova Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Acked-by: Andy Yan Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20240414182706.655270-1-detlev.casanova@collabora.com Signed-off-by: Sasha Levin commit fd8ca99dd1a2de31506f663fb112c00f659b155a Author: Ricardo Ribalda Date: Thu Apr 4 18:00:49 2024 +0000 media: uvcvideo: Add quirk for Logitech Rally Bar [ Upstream commit 07731053d11f7647d5d8bc23caac997a4d562dfe ] Logitech Rally Bar devices, despite behaving as UVC cameras, have a different power management system that the other cameras from Logitech. USB_QUIRK_RESET_RESUME is applied to all the UVC cameras from Logitech at the usb core. Unfortunately, USB_QUIRK_RESET_RESUME causes undesired USB disconnects in the Rally Bar that make them completely unusable. There is an open discussion about if we should fix this in the core or add a quirk in the UVC driver. In order to enable this hardware, let's land this patch first, and we can revert it later if there is a different conclusion. Fixes: e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams") Acked-by: Greg Kroah-Hartman Reviewed-by: Devinder Khroad Reviewed-by: Sergey Senozhatsky Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda Link: https://lore.kernel.org/r/20240404-rallybar-v6-1-6d67bb6b69af@chromium.org Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 8971b2da4b6cea1a533a1b77d647f739a85e4c63 Author: Dmitry Baryshkov Date: Mon Apr 8 02:53:51 2024 +0300 drm/mipi-dsi: use correct return type for the DSC functions [ Upstream commit de1c705c50326acaceaf1f02bc5bf6f267c572bd ] The functions mipi_dsi_compression_mode() and mipi_dsi_picture_parameter_set() return 0-or-error rather than a buffer size. Follow example of other similar MIPI DSI functions and use int return type instead of size_t. Fixes: f4dea1aaa9a1 ("drm/dsi: add helpers for DSI compression mode and PPS packets") Reviewed-by: Marijn Suijten Reviewed-by: Jessica Zhang Signed-off-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20240408-lg-sw43408-panel-v5-2-4e092da22991@linaro.org Signed-off-by: Sasha Levin commit 4a67ebea9d14c167ddb53dba6a275fd448547cd2 Author: Stefan Binding Date: Thu Apr 11 12:08:13 2024 +0100 ALSA: hda: cs35l41: Remove Speaker ID for Lenovo Legion slim 7 16ARHA7 [ Upstream commit 4a1a8065f5d3565677347d34a908ff2d0803b14f ] These laptops do not have _DSD and must be added by configuration table, however, the initial entries for them are incorrect: Neither laptop contains a Speaker ID GPIO. This issue would not affect audio playback, but may affect which files are loaded when loading firmware. Fixes: b67a7dc418aa ("ALSA: hda/realtek: Add sound quirks for Lenovo Legion slim 7 16ARHA7 models") Signed-off-by: Stefan Binding Signed-off-by: Takashi Iwai Message-ID: <20240411110813.330483-8-sbinding@opensource.cirrus.com> Signed-off-by: Sasha Levin commit 88fcce7c31e6c1d99a2a3b2bd9c0aeade0dd41c3 Author: Marek Vasut Date: Thu Mar 28 11:27:36 2024 +0100 drm/panel: simple: Add missing Innolux G121X1-L03 format, flags, connector [ Upstream commit 11ac72d033b9f577e8ba0c7a41d1c312bb232593 ] The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , add the missing bus_format. Add missing connector type and bus_flags as well. Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is capable of both RGB 18bit/24bit panel, the current configuration uses 18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6. Support for the 24bit mode would require another entry in panel-simple with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which is out of scope of this fix. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf Fixes: f8fa17ba812b ("drm/panel: simple: Add support for Innolux G121X1-L03") Signed-off-by: Marek Vasut Acked-by: Jessica Zhang Link: https://patchwork.freedesktop.org/patch/msgid/20240328102746.17868-2-marex@denx.de Signed-off-by: Sasha Levin commit d8285fea0656f221bcea0c551d98094117126f59 Author: Hsin-Te Yuan Date: Tue Apr 16 07:21:35 2024 +0000 drm/bridge: anx7625: Update audio status while detecting [ Upstream commit a665b4e60369867cddf50f37f16169a3e2f434ad ] Previously, the audio status was not updated during detection, leading to a persistent audio despite hot plugging events. To resolve this issue, update the audio status during detection. Fixes: 566fef1226c1 ("drm/bridge: anx7625: add HDMI audio function") Signed-off-by: Hsin-Te Yuan Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240416-anx7625-v3-1-f916ae31bdd7@chromium.org Signed-off-by: Sasha Levin commit 48de4f92a44c20f645bbbe15e7af0d3710de2693 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:36 2024 -0400 drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found [ Upstream commit 5ff5505b9a2d827cae3f95dceba258c963138175 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-8-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit 3673f70f6a16ee6d896dbc7b7d246b7b3ce42f96 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:35 2024 -0400 drm/bridge: dpc3433: Don't log an error when DSI host can't be found [ Upstream commit 24f4f575214de776539d346b99b8717bffa8ebba ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Also move the "failed to attach" error message so that it's only printed when the devm_mipi_dsi_attach() call fails. Fixes: 6352cd451ddb ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-7-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit a073e011bd174987bd715843be81a13ee5b66382 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:34 2024 -0400 drm/bridge: tc358775: Don't log an error when DSI host can't be found [ Upstream commit 272377aa0e3dddeec3f568c8bb9d12c7a79d8ef5 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-6-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit 72ca4171142f7e3d8c838da865099de7218eb133 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:33 2024 -0400 drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found [ Upstream commit 6d9e877cde7e9b516a9a99751b8222c87557436d ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 0cbbd5b1a012 ("drm: bridge: add support for lontium LT9611UXC bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-5-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit a86321bfe52b2c19a29acaaea1ee84dadd3388fe Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:32 2024 -0400 drm/bridge: lt9611: Don't log an error when DSI host can't be found [ Upstream commit cd0a2c6a081ff67007323725b9ff07d9934b1ed8 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-4-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit 69bc77fef6add11f42eb62bde7ad189e01e0ba70 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:31 2024 -0400 drm/bridge: lt8912b: Don't log an error when DSI host can't be found [ Upstream commit b3b4695ff47c4964d4ccb930890c9ffd8e455e20 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-3-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit 4f9faca2f2d5f9cdb50817c58e33c86276b87c32 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:30 2024 -0400 drm/bridge: icn6211: Don't log an error when DSI host can't be found [ Upstream commit 275fafe58faa7fdb10fa245412696ecef676aac5 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 8dde6f7452a1 ("drm: bridge: icn6211: Add I2C configuration support") Suggested-by: AngeloGioacchino Del Regno Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit ccf8dc41b8d7e5dfbce693919c95e00c79211567 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 17:49:29 2024 -0400 drm/bridge: anx7625: Don't log an error when DSI host can't be found [ Upstream commit ef4a9204d594fe959cdbc7418273caf4001535c8 ] Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found") Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Neil Armstrong Reviewed-by: Laurent Pinchart Signed-off-by: Nícolas F. R. A. Prado Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-1-619a28148e5c@collabora.com Signed-off-by: Sasha Levin commit 3f05a1ae921221767011eea6cb8183e95db6aa49 Author: Steven Rostedt Date: Tue Apr 16 00:03:03 2024 -0400 ASoC: tracing: Export SND_SOC_DAPM_DIR_OUT to its value [ Upstream commit 58300f8d6a48e58d1843199be743f819e2791ea3 ] The string SND_SOC_DAPM_DIR_OUT is printed in the snd_soc_dapm_path trace event instead of its value: (((REC->path_dir) == SND_SOC_DAPM_DIR_OUT) ? "->" : "<-") User space cannot parse this, as it has no idea what SND_SOC_DAPM_DIR_OUT is. Use TRACE_DEFINE_ENUM() to convert it to its value: (((REC->path_dir) == 1) ? "->" : "<-") So that user space tools, such as perf and trace-cmd, can parse it correctly. Reported-by: Luca Ceresoli Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events") Signed-off-by: Steven Rostedt (Google) Link: https://lore.kernel.org/r/20240416000303.04670cdf@rorschach.local.home Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bd7827d46d403f8cdb43d16744cb1114e4726b21 Author: Aleksandr Mishin Date: Tue Apr 9 10:56:22 2024 +0300 drm: vc4: Fix possible null pointer dereference [ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishin@t-argos.ru Signed-off-by: Sasha Levin commit 93f76ec1eddce60dbb5885cbc0d7df54adee4639 Author: Huai-Yuan Liu Date: Sun Apr 7 14:30:53 2024 +0800 drm/arm/malidp: fix a possible null pointer dereference [ Upstream commit a1f95aede6285dba6dd036d907196f35ae3a11ea ] In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector") Signed-off-by: Huai-Yuan Liu Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq810974084@gmail.com Signed-off-by: Sasha Levin commit 6482c433863b257b0b9b687c28ce80b89d5f89f0 Author: Zhipeng Lu Date: Thu Jan 18 16:13:00 2024 +0100 media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries [ Upstream commit 3b621e9e9e148c0928ab109ac3d4b81487469acb ] The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. Link: https://lore.kernel.org/r/20240118151303.3828292-1-alexious@zju.edu.cn Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Zhipeng Lu Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f5ec77ce4ee1abcdb85d91ac53305102d6152b2a Author: Randy Dunlap Date: Fri Feb 9 21:39:38 2024 -0800 fbdev: sh7760fb: allow modular build [ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ] There is no reason to prohibit sh7760fb from being built as a loadable module as suggested by Geert, so change the config symbol from bool to tristate to allow that and change the FB dependency as needed. Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y") Suggested-by: Geert Uytterhoeven Signed-off-by: Randy Dunlap Cc: Thomas Zimmermann Cc: Javier Martinez Canillas Cc: John Paul Adrian Glaubitz Cc: Sam Ravnborg Cc: Helge Deller Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Acked-by: John Paul Adrian Glaubitz Acked-by: Javier Martinez Canillas Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 8e4d288a75bd9ec87a5011bb416ec31d3a0ef691 Author: Laurent Pinchart Date: Tue Apr 2 02:37:25 2024 +0300 media: v4l2-subdev: Fix stream handling for crop API [ Upstream commit 34d7bf1c8e59f5fbf438ee32c96389ebe41ca2e8 ] When support for streams was added to the V4L2 subdev API, the v4l2_subdev_crop structure was extended with a stream field, but the field was not handled in the core code that translates the VIDIOC_SUBDEV_[GS]_CROP ioctls to the selection API. Fix it. Fixes: 2f91e10ee6fd ("media: subdev: add stream based configuration") Signed-off-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 904db2ba44ae60641b6378c5013254d09acf5e80 Author: Uwe Kleine-König Date: Sun Mar 24 17:00:44 2024 +0100 media: i2c: et8ek8: Don't strip remove function when driver is builtin [ Upstream commit 545b215736c5c4b354e182d99c578a472ac9bfce ] Using __exit for the remove function results in the remove callback being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -> et8ek8_remove (section: .exit.text) Fixes: c5254e72b8ed ("[media] media: Driver for Toshiba et8ek8 5MP sensor") Signed-off-by: Uwe Kleine-König Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit cea7eb9183d727bb9fcb5d676f1059f52b45fe45 Author: Fabio Estevam Date: Tue Apr 2 14:40:27 2024 -0300 media: dt-bindings: ovti,ov2680: Fix the power supply names [ Upstream commit e2f6ea61b6f3e4ebbb7dff857eea6220c18cd17b ] The original .txt bindings had the OV2680 power supply names correct, but the transition from .txt to yaml spelled them incorrectly. Fix the OV2680 power supply names as the original .txt bindings as these are the names used by the OV2680 driver and in devicetree. Fixes: 57226cd8c8bf ("media: dt-bindings: ov2680: convert bindings to yaml") Signed-off-by: Fabio Estevam Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit a58975f8cd0d89c840cb0ec7f6bcf832d8b0e44e Author: Sakari Ailus Date: Tue Dec 20 16:01:20 2022 +0200 media: ipu3-cio2: Request IRQ earlier [ Upstream commit a069f79bfa6ec1ea0744981ea8425c8a25322579 ] Call devm_request_irq() before registering the async notifier, as otherwise it would be possible to use the device before the interrupts could be delivered to the driver. Fixes: c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver") Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f8035d0880096b7408cecc17c5bdc876cd03241c Author: Douglas Anderson Date: Fri Mar 15 14:36:30 2024 -0700 drm/msm/dp: Account for the timeout in wait_hpd_asserted() callback [ Upstream commit c8520d5e5d8fe2e329f21ce04464a22b3d456caa ] The DP wait_hpd_asserted() callback is passed a timeout which indicates how long we should wait for HPD. This timeout was being ignored in the MSM DP implementation and instead a hardcoded 500 ms timeout was used. Fix it to use the proper timeout. As part of this we move the hardcoded 500 ms number into the AUX transfer function, which isn't given a timeout. The wait in the AUX transfer function will be removed in a future commit. Fixes: e2969ee30252 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by: Douglas Anderson Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/583128/ Link: https://lore.kernel.org/r/20240315143621.v2.2.I7758d18a1773821fa39c034b16a12ef3f18a51ee@changeid Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d7ef3143ccb0828a84cddbae65c001b37c64f510 Author: Douglas Anderson Date: Fri Mar 15 14:36:29 2024 -0700 drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected [ Upstream commit 5d1a7493343cc00d9019880b686e4e0a0f649531 ] As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and userspace accesses "/dev/drm_dp_auxN" directly then the AUX transfer function will be called regardless of whether a DP device is connected. For eDP panels we have a special rule where we wait (with a 5 second timeout) for HPD to go high. This rule was important before all panels drivers were converted to call wait_hpd_asserted() and actually can be removed in a future commit. For external DP devices we never checked for HPD. That means that trying to access the DP AUX character device (AKA `hexdump -C /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my system: $ time hexdump -C /dev/drm_dp_aux0 hexdump: /dev/drm_dp_aux0: Connection timed out real 0m8.200s We want access to the drm_dp_auxN character device to fail faster than 8 seconds when no DP cable is plugged in. Let's add a test to make transfers fail right away if a device isn't plugged in. Rather than testing the HPD line directly, we have the dp_display module tell us when AUX transfers should be enabled so we can handle cases where HPD is signaled out of band like with Type C. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Douglas Anderson Reviewed-by: Guenter Roeck Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/583127/ Link: https://lore.kernel.org/r/20240315143621.v2.1.I16aff881c9fe82b5e0fc06ca312da017aa7b5b3e@changeid Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 01cabb472bf31a49fc74a320760f8986a5283a0a Author: Dmitry Baryshkov Date: Sat Feb 3 15:47:25 2024 +0200 drm/msm/dp: allow voltage swing / pre emphasis of 3 [ Upstream commit 22578178e5dd6d3aa4490879df8b6c2977d980be ] Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and pre-emphasis to 2, while the real maximum value for the sum of the voltage swing and pre-emphasis is 3. Fix the DP code to remove this limitation. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Dmitry Baryshkov Reviewed-by: Kuogee Hsieh Tested-by: Kuogee Hsieh Patchwork: https://patchwork.freedesktop.org/patch/577006/ Link: https://lore.kernel.org/r/20240203-dp-swing-3-v1-1-6545e1706196@linaro.org Signed-off-by: Sasha Levin commit 88d7042904d1c293126a8285688ae37b9c494c2e Author: Armin Wolf Date: Tue Apr 2 16:30:57 2024 +0200 platform/x86: xiaomi-wmi: Fix race condition when reporting key events [ Upstream commit 290680c2da8061e410bcaec4b21584ed951479af ] Multiple WMI events can be received concurrently, so multiple instances of xiaomi_wmi_notify() can be active at the same time. Since the input device is shared between those handlers, the key input sequence can be disturbed. Fix this by protecting the key input sequence with a mutex. Compile-tested only. Fixes: edb73f4f0247 ("platform/x86: wmi: add Xiaomi WMI key driver") Signed-off-by: Armin Wolf Link: https://lore.kernel.org/r/20240402143059.8456-2-W_Armin@gmx.de Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 47889711da20be9b43e1e136e5cb68df37cbcc79 Author: Aleksandr Mishin Date: Mon Apr 8 15:58:10 2024 +0300 drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference [ Upstream commit 935a92a1c400285545198ca2800a4c6c519c650a ] In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishin@t-argos.ru Signed-off-by: Sasha Levin commit 64dc853bff135179ca93ad3b69c832541833f1fd Author: Ricardo Ribalda Date: Mon Mar 25 14:50:24 2024 +0000 media: radio-shark2: Avoid led_names truncations [ Upstream commit 1820e16a3019b6258e6009d34432946a6ddd0a90 ] Increase the size of led_names so it can fit any valid v4l2 device name. Fixes: drivers/media/radio/radio-shark2.c:197:17: warning: ‘%s’ directive output may be truncated writing up to 35 bytes into a region of size 32 [-Wformat-truncation=] Signed-off-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 0d27a8425929ec5fe93447fea2af173d23c9f128 Author: Arnd Bergmann Date: Fri Mar 22 14:33:46 2024 +0100 media: rcar-vin: work around -Wenum-compare-conditional warning [ Upstream commit 1a742c6010d136cb6c441a0f1dd2bfbfae3c4df2 ] clang-19 warns about mixing two enum types here: drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-core.c:216:18: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] drivers/media/platform/renesas/rcar-vin/rcar-vin.h:296:12: error: conditional expression between different enumeration types ('enum rvin_csi_id' and 'enum rvin_isp_id') [-Werror,-Wenum-compare-conditional] This one is intentional, and there is already a cast to work around another warning, so address this by adding another cast. Fixes: 406bb586dec0 ("media: rcar-vin: Add r8a779a0 support") Signed-off-by: Arnd Bergmann Reviewed-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c58270de8d54948783db709648c2c6868fccc725 Author: Changhuang Liang Date: Mon Mar 11 05:03:09 2024 -0700 staging: media: starfive: Remove links when unregistering devices [ Upstream commit 810dd605e917c716f6f83e6cd8ea23d9155d32a2 ] Need to remove links when unregistering devices. Fixes: ac7da4a73b10 ("media: staging: media: starfive: camss: Register devices") Signed-off-by: Changhuang Liang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 303dc938c16fb2a8da6ff3035d7ec977e3207fea Author: Aleksandr Burakov Date: Fri Mar 1 14:15:53 2024 +0300 media: ngene: Add dvb_ca_en50221_init return value check [ Upstream commit 9bb1fd7eddcab2d28cfc11eb20f1029154dac718 ] The return value of dvb_ca_en50221_init() is not checked here that may cause undefined behavior in case of nonzero value return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 25aee3debe04 ("[media] Rename media/dvb as media/pci") Signed-off-by: Aleksandr Burakov Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 252c05efeab8c563a5f6ccc8b9faa234b0d5f5a2 Author: Cezary Rojewski Date: Fri Apr 5 11:09:24 2024 +0200 ASoC: Intel: avs: Test result of avs_get_module_entry() [ Upstream commit 41bf4525fadb3d8df3860420d6ac9025c51a3bac ] While PROBE_MOD_UUID is always part of the base AudioDSP firmware manifest, from maintenance point of view it is better to check the result. Fixes: dab8d000e25c ("ASoC: Intel: avs: Add data probing requests") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240405090929.1184068-9-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c2521a3c16f019b3d616e1fea70fb887c8233d9 Author: Cezary Rojewski Date: Fri Apr 5 11:09:23 2024 +0200 ASoC: Intel: avs: Fix potential integer overflow [ Upstream commit c7e832cabe635df47c2bf6df7801e97bf3045b1e ] While stream_tag for CLDMA on SKL-based platforms is always 1, function hda_cldma_setup() uses AZX_SD_CTL_STRM() macro which does: stream_tag << 20 what combined with stream_tag type of 'unsigned int' generates a potential overflow issue. Update the field type to fix that. Fixes: 45864e49a05a ("ASoC: Intel: avs: Implement CLDMA transfer") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240405090929.1184068-8-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 70d058d60aa7db69a010bd7c55beb69d23cae658 Author: Cezary Rojewski Date: Fri Apr 5 11:09:21 2024 +0200 ASoC: Intel: avs: Fix ASRC module initialization [ Upstream commit 9d2e26f31c7cc3fa495c423af9b4902ec0dc7be3 ] The ASRC module configuration consists of several reserved fields. Zero them out when initializing the module to avoid sending invalid data. Fixes: 274d79e51875 ("ASoC: Intel: avs: Configure modules according to their type") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240405090929.1184068-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 125962549c4fb63dc8ff04e464e61d0f03b7f071 Author: Cezary Rojewski Date: Fri Apr 5 11:09:18 2024 +0200 ASoC: Intel: avs: Fix debug-slot offset calculation [ Upstream commit c91b692781c1839fcc389b2a9120e46593c6424b ] For resources with ID other than 0 the current calculus is incorrect. Fixes: 275b583d047a ("ASoC: Intel: avs: ICL-based platforms support") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240405090929.1184068-3-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b33040a3b898e32ea6543fa5c1e4d5a2eb0f85e5 Author: Amadeusz Sławiński Date: Fri Apr 5 11:09:17 2024 +0200 ASoC: Intel: avs: Restore stream decoupling on prepare [ Upstream commit 680507581e025d16a0b6d3782603ca8c598fbe2b ] Revert changes from commit b87b8f43afd5 ("ASoC: Intel: avs: Drop superfluous stream decoupling") to restore working streaming during S3. Fixes: b87b8f43afd5 ("ASoC: Intel: avs: Drop superfluous stream decoupling") Signed-off-by: Amadeusz Sławiński Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240405090929.1184068-2-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0b6d0d1eca4188ff13b1f8f0aedaeed9b9516dc2 Author: Tianchen Ding Date: Wed Mar 27 10:44:37 2024 +0800 selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate [ Upstream commit 4793cb599b1bdc3d356f0374c2c99ffe890ae876 ] The test case test_cgcore_lesser_ns_open only tasks effect when cgroup2 is mounted with "nsdelegate" mount option. If it misses this option, or is remounted without "nsdelegate", the test case will fail. For example, running bpf/test_cgroup_storage first, and then run cgroup/test_core will fail on test_cgcore_lesser_ns_open. Skip it if "nsdelegate" is not detected in cgroup2 mount options. Fixes: bf35a7879f1d ("selftests: cgroup: Test open-time cgroup namespace usage for migration checks") Signed-off-by: Tianchen Ding Reviewed-by: Muhammad Usama Anjum Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit f3a0cd92c055623f40faae3d593f620071fc0a08 Author: Arnd Bergmann Date: Wed Apr 3 10:06:31 2024 +0200 fbdev: sisfb: hide unused variables [ Upstream commit 688cf598665851b9e8cb5083ff1d208ce43d10ff ] Building with W=1 shows that a couple of variables in this driver are only used in certain configurations: drivers/video/fbdev/sis/init301.c:239:28: error: 'SiS_Part2CLVX_6' defined but not used [-Werror=unused-const-variable=] 239 | static const unsigned char SiS_Part2CLVX_6[] = { /* 1080i */ | ^~~~~~~~~~~~~~~ drivers/video/fbdev/sis/init301.c:230:28: error: 'SiS_Part2CLVX_5' defined but not used [-Werror=unused-const-variable=] 230 | static const unsigned char SiS_Part2CLVX_5[] = { /* 750p */ | ^~~~~~~~~~~~~~~ drivers/video/fbdev/sis/init301.c:211:28: error: 'SiS_Part2CLVX_4' defined but not used [-Werror=unused-const-variable=] 211 | static const unsigned char SiS_Part2CLVX_4[] = { /* PAL */ | ^~~~~~~~~~~~~~~ drivers/video/fbdev/sis/init301.c:192:28: error: 'SiS_Part2CLVX_3' defined but not used [-Werror=unused-const-variable=] 192 | static const unsigned char SiS_Part2CLVX_3[] = { /* NTSC, 525i, 525p */ | ^~~~~~~~~~~~~~~ drivers/video/fbdev/sis/init301.c:184:28: error: 'SiS_Part2CLVX_2' defined but not used [-Werror=unused-const-variable=] 184 | static const unsigned char SiS_Part2CLVX_2[] = { | ^~~~~~~~~~~~~~~ drivers/video/fbdev/sis/init301.c:176:28: error: 'SiS_Part2CLVX_1' defined but not used [-Werror=unused-const-variable=] 176 | static const unsigned char SiS_Part2CLVX_1[] = { | ^~~~~~~~~~~~~~~ This started showing up after the definitions were moved into the source file from the header, which was not flagged by the compiler. Move the definition into the appropriate #ifdef block that already exists next to them. Fixes: 5908986ef348 ("video: fbdev: sis: avoid mismatched prototypes") Signed-off-by: Arnd Bergmann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit fae7c3d7ae8b64ccf761164b611b669ffc95478b Author: Peter Ujfalusi Date: Wed Apr 3 13:52:08 2024 +0300 ASoC: SOF: Intel: mtl: Implement firmware boot state check [ Upstream commit 6b1c1c47e76f0161bda2b1ac2e86a219fe70244f ] With the corrected rom_status_reg values we can now add a check for target boot status for firmware booting. With the check now we can identify failed firmware boots (IMR boots) and we can use the fallback to purge boot the DSP. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f7eacef75767d380c1b7936d5a43f41fd041e5c2 Author: Peter Ujfalusi Date: Wed Apr 3 13:52:07 2024 +0300 ASoC: SOF: Intel: mtl: Disable interrupts when firmware boot failed [ Upstream commit 26187f44aabdf3df7609b7c78724a059c230a2ad ] In case of error during the firmware boot we need to disable the interrupts which were enabled as part of the boot sequence. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0f925309d75d3625c309f47ae45be991f63dd20f Author: Peter Ujfalusi Date: Wed Apr 3 13:52:06 2024 +0300 ASoC: SOF: Intel: lnl: Correct rom_status_reg [ Upstream commit b852574c671a9983dd51c81582c8c5085f3dc382 ] ACE2 architecture changed the place where the ROM updates the status code from the shared SRAM window (and HFFLGP1QW0 in ACE1) to HFDSC register for the status and HFDEC (HFDSC + 4) for the error code. The rom_status_reg is not used on LNL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Add new header file for lnl specific register definitions. Fixes: 64a63d9914a5 ("ASoC: SOF: Intel: LNL: Add support for Lunarlake platform") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f25539ac3a6a3b151daafee6beed5fffe18907c2 Author: Peter Ujfalusi Date: Wed Apr 3 13:52:05 2024 +0300 ASoC: SOF: Intel: mtl: Correct rom_status_reg [ Upstream commit 1f1b820dc3c65b6883da3130ba3b8624dcbf87db ] ACE1 architecture changed the place where the ROM updates the status code from the shared SRAM window to HFFLGP1QW0 register for the status and HFFLGP1QW0 + 4 for the error code. The rom_status_reg is not used on MTL because it was wrongly assigned based on older platform convention (SRAM window) and it was giving inconsistent readings. Fixes: 064520e8aeaa ("ASoC: SOF: Intel: Add support for MeteorLake (MTL)") Signed-off-by: Peter Ujfalusi Reviewed-by: Rander Wang Reviewed-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Liam Girdwood Link: https://msgid.link/r/20240403105210.17949-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5ef39cc3f85c408e82160f135366aaec33e07bcc Author: Arnd Bergmann Date: Wed Apr 3 10:06:19 2024 +0200 powerpc/fsl-soc: hide unused const variable [ Upstream commit 01acaf3aa75e1641442cc23d8fe0a7bb4226efb1 ] vmpic_msi_feature is only used conditionally, which triggers a rare -Werror=unused-const-variable= warning with gcc: arch/powerpc/sysdev/fsl_msi.c:567:37: error: 'vmpic_msi_feature' defined but not used [-Werror=unused-const-variable=] 567 | static const struct fsl_msi_feature vmpic_msi_feature = Hide this one in the same #ifdef as the reference so we can turn on the warning by default. Fixes: 305bcf26128e ("powerpc/fsl-soc: use CONFIG_EPAPR_PARAVIRT for hcalls") Signed-off-by: Arnd Bergmann Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/20240403080702.3509288-2-arnd@kernel.org Signed-off-by: Sasha Levin commit 64028347af70a776c65e12fa6e861561559c870b Author: Pierre-Louis Bossart Date: Tue Apr 2 10:18:12 2024 -0500 ASoC: SOF: Intel: hda-dai: fix channel map configuration for aggregated dailink [ Upstream commit 831045513c8a2ef14c3cf39b33d1ccedf588c4a8 ] The existing code derives the channel map used to program the HDaudio link DMA from the hw_params, but that is not quite right in the case of aggregation. The code in soc-pcm.c splits the hw_params depending on the codec_ch_map, and we need to reconstruct the channel-map to insert the data in the right places. This issue is seen only on amplifier feedback capture where the data from the second amplifier was replaced by that of the first amplifier. Note that the loop iterator of the macro for_each_rtd_cpu_dais() is reused in a following loop. This is different to all existing usages of that macro, hence the use of a boolean flag to avoid an access to an uninitialized variable. Fixes: 2960ee5c4814 ("ASoC: SOF: Intel: hda-dai: add helpers for SoundWire callbacks") Reviewed-by: Bard Liao Reviewed-by: Rander Wang Signed-off-by: Pierre-Louis Bossart Link: https://msgid.link/r/20240402151828.175002-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1 Author: Douglas Anderson Date: Thu Mar 28 09:22:49 2024 -0700 drm/mediatek: Init `ddp_comp` with devm_kcalloc() [ Upstream commit 01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 ] In the case where `conn_routes` is true we allocate an extra slot in the `ddp_comp` array but mtk_drm_crtc_create() never seemed to initialize it in the test case I ran. For me, this caused a later crash when we looped through the array in mtk_drm_crtc_mode_valid(). This showed up for me when I booted with `slub_debug=FZPUA` which poisons the memory initially. Without `slub_debug` I couldn't reproduce, presumably because the later code handles the value being NULL and in most cases (not guaranteed in all cases) the memory the allocator returned started out as 0. It really doesn't hurt to initialize the array with devm_kcalloc() since the array is small and the overhead of initting a handful of elements to 0 is small. In general initting memory to zero is a safer practice and usually it's suggested to only use the non-initting alloc functions if you really need to. Let's switch the function to use an allocation function that zeros the memory. For me, this avoids the crash. Fixes: 01389b324c97 ("drm/mediatek: Add connector dynamic selection capability") Signed-off-by: Douglas Anderson Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240328092248.1.I2e73c38c0f264ee2fa4a09cdd83994e37ba9f541@changeid/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit fb4aabdb1b48c25d9e1ee28f89440fd2ce556405 Author: Justin Green Date: Thu Mar 7 13:00:51 2024 -0500 drm/mediatek: Add 0 size check to mtk_drm_gem_obj [ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425-1-greenjustin@chromium.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit ec637468e4e4b94808dcc488917581a896a08c74 Author: Christian Hewitt Date: Tue Jan 9 23:07:04 2024 +0000 drm/meson: vclk: fix calculation of 59.94 fractional rates [ Upstream commit bfbc68e4d8695497f858a45a142665e22a512ea3 ] Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen to lose sync with the following error reported in the system log: [ 89.610280] Fatal Error, invalid HDMI vclk freq 593406 Modetest shows the following: 3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx, drm calculated value -------------------------------------^ Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down which results in vclk freq failing to match correctly. Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by: Christian Hewitt Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240109230704.4120561-1-christianshewitt@gmail.com Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240109230704.4120561-1-christianshewitt@gmail.com Signed-off-by: Sasha Levin commit 802b49e39da669b54bd9b77dc3c649999a446bf6 Author: Aleksandr Mishin Date: Thu Mar 28 20:33:37 2024 +0300 ASoC: kirkwood: Fix potential NULL dereference [ Upstream commit ea60ab95723f5738e7737b56dda95e6feefa5b50 ] In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if CONFIG_PLAT_ORION macro is not defined. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb6a40fc5a83 ("ASoC: kirkwood: Fix reference to PCM buffer address") Signed-off-by: Aleksandr Mishin Link: https://msgid.link/r/20240328173337.21406-1-amishin@t-argos.ru Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5609a449902445cb097172f354c1b1bb300ab42e Author: Arnd Bergmann Date: Tue Mar 26 23:38:00 2024 +0100 fbdev: shmobile: fix snprintf truncation [ Upstream commit 26c8cfb9d1e4b252336d23dd5127a8cbed414a32 ] The name of the overlay does not fit into the fixed-length field: drivers/video/fbdev/sh_mobile_lcdcfb.c:1577:2: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 25 Make it short enough by changing the string. Fixes: c5deac3c9b22 ("fbdev: sh_mobile_lcdc: Implement overlays support") Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 4e8de27007ad5f95c517d0a5f1bcdbb575a3af7e Author: Heiko Stuebner Date: Wed Mar 20 14:12:32 2024 +0100 drm/panel: ltk050h3146w: drop duplicate commands from LTK050H3148W init [ Upstream commit 55679cc22e60e8ec23b2340248389022798416cd ] The init sequence specifies the 0x11 and 0x29 dsi commands, which are the exit-sleep and display-on commands. In the actual prepare step the driver already uses the appropriate function calls for those, so drop the duplicates. Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant") Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Link: https://patchwork.freedesktop.org/patch/msgid/20240320131232.327196-2-heiko@sntech.de Signed-off-by: Sasha Levin commit 6127ea0302e9186a85fce121de6084a8fdf9d043 Author: Heiko Stuebner Date: Wed Mar 20 14:12:31 2024 +0100 drm/panel: ltk050h3146w: add MIPI_DSI_MODE_VIDEO to LTK050H3148W flags [ Upstream commit 80cc8c0d09e6bab3bd016ddaccd0570cadbe1891 ] Similar to other variants, the LTK050H3148W wants to run in video mode when displaying data. So far only the Synopsis DSI driver was using this panel and it is always switching to video mode, independent of this flag being set. Other DSI drivers might handle this differently, so add the flag. Fixes: e5f9d543419c ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant") Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Acked-by: Jessica Zhang Link: https://patchwork.freedesktop.org/patch/msgid/20240320131232.327196-1-heiko@sntech.de Signed-off-by: Sasha Levin commit 0c052b1c11d8119f3048b1f7b3c39a90500cacf9 Author: AngeloGioacchino Del Regno Date: Wed Mar 13 12:01:29 2024 +0100 ASoC: mediatek: Assign dummy when codec not specified for a DAI link [ Upstream commit 5f39231888c63f0a7708abc86b51b847476379d8 ] MediaTek sound card drivers are checking whether a DAI link is present and used on a board to assign the correct parameters and this is done by checking the codec DAI names at probe time. If no real codec is present, assign the dummy codec to the DAI link to avoid NULL pointer during string comparison. Fixes: 4302187d955f ("ASoC: mediatek: common: add soundcard driver common code") Signed-off-by: AngeloGioacchino Del Regno Link: https://msgid.link/r/20240313110147.1267793-5-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a8e01256c5be7ce08bfe787852103960c44111bd Author: Arnd Bergmann Date: Fri Mar 22 14:01:09 2024 +0100 drm/imagination: avoid -Woverflow warning [ Upstream commit 07b9d0144fff9af08b8dcd0ae134510bfd539e42 ] The array size calculation in pvr_vm_mips_fini() appears to be incorrect based on taking the size of the pointer rather than the size of the array, which manifests as a warning about signed integer overflow: In file included from include/linux/kernel.h:16, from drivers/gpu/drm/imagination/pvr_rogue_fwif.h:10, from drivers/gpu/drm/imagination/pvr_ccb.h:7, from drivers/gpu/drm/imagination/pvr_device.h:7, from drivers/gpu/drm/imagination/pvr_vm_mips.c:4: drivers/gpu/drm/imagination/pvr_vm_mips.c: In function 'pvr_vm_mips_fini': include/linux/array_size.h:11:25: error: overflow in conversion from 'long unsigned int' to 'int' changes value from '18446744073709551615' to '-1' [-Werror=overflow] 11 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr)) | ^ drivers/gpu/drm/imagination/pvr_vm_mips.c:106:24: note: in expansion of macro 'ARRAY_SIZE' 106 | for (page_nr = ARRAY_SIZE(mips_data->pt_pages) - 1; page_nr >= 0; page_nr--) { | ^~~~~~~~~~ Just use the number of array elements directly here, and in the corresponding init function for consistency. Fixes: 927f3e0253c1 ("drm/imagination: Implement MIPS firmware processor and MMU support") Reviewed-by: Donald Robson Link: https://lore.kernel.org/lkml/9df9e4f87727399928c068dbbf614c9895ae15f9.camel@imgtec.com/ Signed-off-by: Arnd Bergmann Signed-off-by: Matt Coster Signed-off-by: Sasha Levin commit 04118146689661882e4e45bc6acd830951382494 Author: Maxim Korotkov Date: Wed Mar 13 13:27:20 2024 +0300 mtd: rawnand: hynix: fixed typo [ Upstream commit 6819db94e1cd3ce24a432f3616cd563ed0c4eaba ] The function hynix_nand_rr_init() should probably return an error code. Judging by the usage, it seems that the return code is passed up the call stack. Right now, it always returns 0 and the function hynix_nand_cleanup() in hynix_nand_init() has never been called. Found by RASU JSC and Linux Verification Center (linuxtesting.org) Fixes: 626994e07480 ("mtd: nand: hynix: Add read-retry support for 1x nm MLC NANDs") Signed-off-by: Maxim Korotkov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240313102721.1991299-1-korotkov.maxim.s@gmail.com Signed-off-by: Sasha Levin commit c2db9cb14467363f6a357ef4f7abcef84b10b0f5 Author: Aapo Vienamo Date: Wed Mar 13 19:34:24 2024 +0200 mtd: core: Report error if first mtd_otp_size() call fails in mtd_otp_nvmem_add() [ Upstream commit d44f0bbbd8d182debcce88bda55b05269f3d33d6 ] Jump to the error reporting code in mtd_otp_nvmem_add() if the mtd_otp_size() call fails. Without this fix, the error is not logged. Signed-off-by: Aapo Vienamo Reviewed-by: Mika Westerberg Reviewed-by: Michael Walle Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240313173425.1325790-2-aapo.vienamo@linux.intel.com Signed-off-by: Sasha Levin commit 308bff2299947a1b611166d972f339e2a228d138 Author: Cezary Rojewski Date: Fri Mar 8 10:05:00 2024 +0100 ASoC: Intel: avs: ssm4567: Do not ignore route checks [ Upstream commit e6719d48ba6329536c459dcee5a571e535687094 ] A copy-paste from intel/boards/skl_nau88l25_ssm4567.c made the avs's equivalent disable route checks as well. Such behavior is not desired. Fixes: 69ea14efe99b ("ASoC: Intel: avs: Add ssm4567 machine board") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240308090502.2136760-4-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 214c70c0ad5ab49d3a70da219cfba7a646f0a863 Author: Cezary Rojewski Date: Fri Mar 8 10:04:58 2024 +0100 ASoC: Intel: Disable route checks for Skylake boards [ Upstream commit 0cb3b7fd530b8c107443218ce6db5cb6e7b5dbe1 ] Topology files that are propagated to the world and utilized by the skylake-driver carry shortcomings in their SectionGraphs. Since commit daa480bde6b3 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()") route checks are no longer permissive. Probe failures for Intel boards have been partially addressed by commit a22ae72b86a4 ("ASoC: soc-core: disable route checks for legacy devices") and its follow up but only skl_nau88l25_ssm4567.c is patched. Fix the problem for the rest of the boards. Link: https://lore.kernel.org/all/20200309192744.18380-1-pierre-louis.bossart@linux.intel.com/ Fixes: daa480bde6b3 ("ASoC: soc-core: tidyup for snd_soc_dapm_add_routes()") Signed-off-by: Cezary Rojewski Link: https://msgid.link/r/20240308090502.2136760-2-cezary.rojewski@intel.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6a9cffd96c4a6178d443447cd1447c12d7cbe157 Author: Srinivasan Shanmugam Date: Sat Feb 24 09:23:53 2024 +0530 drm/amd/display: Remove redundant condition in dcn35_calc_blocks_to_gate() [ Upstream commit a43dbeaba81eb645a12a004c67722c632ed0d94b ] pipe_ctx->plane_res.mpcc_inst is of a type that can only hold values between 0 and 255, so it's always greater than or equal to 0. Thus the condition 'pipe_ctx->plane_res.mpcc_inst >= 0' was always true and has been removed. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn35/dcn35_hwseq.c:1023 dcn35_calc_blocks_to_gate() warn: always true condition '(pipe_ctx->plane_res.mpcc_inst >= 0) => (0-255 >= 0)' Fixes: 6f8b7565cca4 ("drm/amd/display: Add DCN35 HWSEQ") Cc: Qingqing Zhuo Cc: Harry Wentland Cc: Rodrigo Siqueira Cc: Roman Li Cc: Aurabindo Pillai Cc: Tom Chung Signed-off-by: Srinivasan Shanmugam Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29 Author: Srinivasan Shanmugam Date: Mon Feb 26 18:38:08 2024 +0530 drm/amd/display: Fix potential index out of bounds in color transformation function [ Upstream commit 63ae548f1054a0b71678d0349c7dc9628ddd42ca ] Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max Fixes: b629596072e5 ("drm/amd/display: Build unity lut for shaper") Cc: Vitaly Prosyak Cc: Charlene Liu Cc: Harry Wentland Cc: Rodrigo Siqueira Cc: Roman Li Cc: Aurabindo Pillai Cc: Tom Chung Signed-off-by: Srinivasan Shanmugam Reviewed-by: Tom Chung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9386206d4c229a7c48708d929271eab477afd08c Author: Douglas Anderson Date: Wed Mar 13 14:12:14 2024 -0700 drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert [ Upstream commit 5e842d55bad7794823a50f24fd645b58f2ef93ab ] When the atna33xc20 driver was first written the resume code never returned an error. If there was a problem waiting for HPD it just printed a warning and moved on. This changed in response to review feedback [1] on a future patch but I accidentally didn't account for rolling back the regulator enable in the error cases. Do so now. [1] https://lore.kernel.org/all/5f3cf3a6-1cc2-63e4-f76b-4ee686764705@linaro.org/ Fixes: 3b5765df375c ("drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux") Acked-by: Jessica Zhang Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20240313-homestarpanel-regulator-v1-1-b8e3a336da12@chromium.org Signed-off-by: Sasha Levin commit cf26003151b1c612759d434e69528c51ac513961 Author: Marek Vasut Date: Mon Feb 26 09:26:27 2024 +0100 drm/lcdif: Do not disable clocks on already suspended hardware [ Upstream commit 172695f145fb4798ab605e8a73f6e87711930124 ] In case the LCDIF is enabled in DT but unused, the clocks used by the LCDIF are not enabled. Those clocks may even have a use count of 0 in case there are no other users of those clocks. This can happen e.g. in case the LCDIF drives HDMI bridge which has no panel plugged into the HDMI connector. Do not attempt to disable clocks in the suspend callback and re-enable clocks in the resume callback unless the LCDIF is enabled and was in use before the system entered suspend, otherwise the driver might end up trying to disable clocks which are already disabled with use count 0, and would trigger a warning from clock core about this condition. Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions internally perform the clocks disable and enable operations and act as runtime PM hooks too. Reviewed-by: Liu Ying Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20240226082644.32603-1-marex@denx.de Signed-off-by: Sasha Levin commit ff0599313e27553221e1db36361c3c546838e8dc Author: Geert Uytterhoeven Date: Wed Feb 28 15:00:03 2024 +0100 dev_printk: Add and use dev_no_printk() [ Upstream commit c26ec799042a3888935d59b599f33e41efedf5f8 ] When printk-indexing is enabled, each dev_printk() invocation emits a pi_entry structure. This is even true when the dev_printk() is protected by an always-false check, as is typically the case for debug messages: while the actual code to print the message is optimized out by the compiler, the pi_entry structure is still emitted. Avoid emitting pi_entry structures for unavailable dev_printk() kernel messages by: 1. Introducing a dev_no_printk() helper, mimicked after the existing no_printk() helper, which calls _dev_printk() instead of dev_printk(), 2. Replacing all "if (0) dev_printk(...)" constructs by calls to the new helper. This reduces the size of an arm64 defconfig kernel with CONFIG_PRINTK_INDEX=y by 957 KiB. Fixes: ad7d61f159db7397 ("printk: index: Add indexing support to dev_printk") Signed-off-by: Geert Uytterhoeven Reviewed-by: Andy Shevchenko Reviewed-by: Xiubo Li Reviewed-by: Chris Down Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/8583d54f1687c801c6cda8edddf2cf0344c6e883.1709127473.git.geert+renesas@glider.be Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 5184e5a6969f29bbe690dd8dda02643bde89dd79 Author: Geert Uytterhoeven Date: Wed Feb 28 15:00:02 2024 +0100 printk: Let no_printk() use _printk() [ Upstream commit 8522f6b760ca588928eede740d5d69dd1e936b49 ] When printk-indexing is enabled, each printk() invocation emits a pi_entry structure, containing the format string and other information related to its location in the kernel sources. This is even true for no_printk(): while the actual code to print the message is optimized out by the compiler due to the always-false check, the pi_entry structure is still emitted. As the main purpose of no_printk() is to provide a helper to maintain printf()-style format checking when debugging is disabled, this leads to the inclusion in the index of lots of printk formats that cannot be emitted by the current kernel. Fix this by switching no_printk() from printk() to _printk(). This reduces the size of an arm64 defconfig kernel with CONFIG_PRINTK_INDEX=y by 576 KiB. Fixes: 337015573718b161 ("printk: Userspace format indexing support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Andy Shevchenko Reviewed-by: Xiubo Li Reviewed-by: Chris Down Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/56cf92edccffea970e1f40a075334dd6cf5bb2a4.1709127473.git.geert+renesas@glider.be Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 4ca427f40f3e6e3a8b2eaf2d541ec0d439781901 Author: Tony Lindgren Date: Wed Feb 28 08:35:32 2024 +0200 drm/omapdrm: Fix console with deferred ops [ Upstream commit 01c0cce88c5480cc2505b79330246ef12eda938f ] Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers") stopped console from updating for command mode displays because there is no damage handling in fb_sys_write() unlike we had earlier in drm_fb_helper_sys_write(). Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly for write-combine. Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers") Suggested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-3-tony@atomide.com Signed-off-by: Sasha Levin commit e669be0bcf58e9a9536a53be2fa184b564311bf2 Author: Tony Lindgren Date: Wed Feb 28 08:35:31 2024 +0200 drm/omapdrm: Fix console by implementing fb_dirty [ Upstream commit 632bac50544c0929ced9eed41e7d04c08adecbb0 ] The framebuffer console stopped updating with commit f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic"). Let's fix the issue by implementing fb_dirty similar to what was done with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel custom fb helper"). Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Reviewed-by: Thomas Zimmermann Signed-off-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-2-tony@atomide.com Signed-off-by: Sasha Levin commit 68160442dce98f32bfdf82ae52d36998852038f9 Author: Lyude Paul Date: Fri Mar 15 17:20:56 2024 -0400 drm/nouveau/dp: Fix incorrect return code in r535_dp_aux_xfer() [ Upstream commit 97252d0a4bfbb07079503d059f7522d305fe0f7a ] I've recently been seeing some unexplained GSP errors on my RTX 6000 from failed aux transactions: [ 132.915867] nouveau 0000:1f:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff While the cause of these is not yet clear, these messages made me notice that the aux transactions causing these transactions were succeeding - not failing. As it turns out, this is because we're currently not returning the correct variable when r535_dp_aux_xfer() hits an error - causing us to never propagate GSP errors for failed aux transactions to userspace. So, let's fix that. Fixes: 4ae3a20102b2 ("nouveau/gsp: don't free ctrl messages on errors") Signed-off-by: Lyude Paul Reviewed-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20240315212104.776936-1-lyude@redhat.com Signed-off-by: Sasha Levin commit c93d80cea0b3596c979fdd6358646fe824efd882 Author: Vignesh Raman Date: Thu Mar 7 07:48:41 2024 +0530 drm/ci: update device type for volteer devices [ Upstream commit a2c71b711e7efc6478976233768bdbc3386e6dce ] Volteer devices in the collabora lab are categorized under the asus-cx9400-volteer device type. The majority of these units has an Intel Core i5-1130G7 CPU, while some of them have a Intel Core i7-1160G7 CPU instead. So due to this difference, new device type template is added for the Intel Core i5-1130G7 and i7-1160G7 variants of the Acer Chromebook Spin 514 (CP514-2H) volteer Chromebooks. So update the same in drm-ci. https://gitlab.collabora.com/lava/lava/-/merge_requests/149 Fixes: 0119c894ab0d ("drm: Add initial ci/ subdirectory") Reviewed-by: David Heidelberg Signed-off-by: Vignesh Raman Acked-by: Helen Koike Signed-off-by: Helen Koike Link: https://patchwork.freedesktop.org/patch/msgid/20240307021841.100561-1-vignesh.raman@collabora.com Signed-off-by: Sasha Levin commit ceb79a4368b02a7f4da79e7224acffe7dc3eb15c Author: Jagan Teki Date: Tue Mar 28 22:37:51 2023 +0530 drm/bridge: Fix improper bridge init order with pre_enable_prev_first [ Upstream commit e18aeeda0b6905c333df5a0566b99f5c84426098 ] For a given bridge pipeline if any bridge sets pre_enable_prev_first flag then the pre_enable for the previous bridge will be called before pre_enable of this bridge and opposite is done for post_disable. These are the potential bridge flags to alter bridge init order in order to satisfy the MIPI DSI host and downstream panel or bridge to function. However the existing pre_enable_prev_first logic with associated bridge ordering has broken for both pre_enable and post_disable calls. [pre_enable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flag on each iteration and assigned the previou bridge to limit pointer if the bridge doesn't enable pre_enable_prev_first flags. If control found Bridge 2 is pre_enable_prev_first then the iteration looks for Bridge 3 and found it is not pre_enable_prev_first and assigns it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3 and Bridge 2 and assign iter pointer with limit which is Bridge 4. Here is the actual problem, for the next iteration control look for Bridge 5 instead of Bridge 4 has iter pointer in previous iteration moved to Bridge 4 so this iteration skips the Bridge 4. The iteration found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned to Encoder. From next iteration Encoder skips as it is the last bridge for reverse order pipeline. So, the resulting pre_enable bridge order would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5. This patch fixes this by assigning limit to next pointer instead of previous bridge since the iteration always looks for bridge that does NOT request prev so assigning next makes sure the last bridge on a given iteration what exactly the limit bridge is. So, the resulting pre_enable bridge order with fix would be, - Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. [post_disable] The altered bridge ordering has failed if two consecutive bridges on a given pipeline enables the pre_enable_prev_first flag. Example: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder In this example Bridge 5 and Bridge 4 have pre_enable_prev_first. The logic looks for a bridge which enabled pre_enable_prev_first flags on each iteration and assigned the previou bridge to next and next to limit pointer if the bridge does enable pre_enable_prev_first flag. If control starts from Bridge 6 then it found next Bridge 5 is pre_enable_prev_first and immediately the next assigned to previous Bridge 6 and limit assignments to next Bridge 6 and call post_enable of Bridge 6 even though the next consecutive Bridge 5 is enabled with pre_enable_prev_first. This clearly misses the logic to find the state of next conducive bridge as everytime the next and limit assigns previous bridge if given bridge enabled pre_enable_prev_first. So, the resulting post_disable bridge order would be, - Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1, Panel. This patch fixes this by assigning next with previou bridge only if the bridge doesn't enable pre_enable_prev_first flag and the next further assign it to limit. This way we can find the bridge that NOT requested prev to disable last. So, the resulting pre_enable bridge order with fix would be, - Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1, Panel. Validated the bridge init ordering by incorporating dummy bridges in the sun6i-mipi-dsi pipeline Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order") Signed-off-by: Jagan Teki Tested-by: Michael Trimarchi Reviewed-by: Dave Stevenson Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20230328170752.1102347-1-jagan@amarulasolutions.com Signed-off-by: Sasha Levin commit 9ea499a97b0a9c459bc1cc83f673ed8acda1cf11 Author: Zhengqiao Xia Date: Fri Mar 1 16:40:06 2024 +0800 drm/panel-edp: Add prepare_to_enable to 200ms for MNC207QS1-1 [ Upstream commit e635b7eb7062b464bbd9795308b1a80eac0b01f5 ] For MNC207QS1-1 panel, Splash screen occur when switch from VT1 to VT2. The BL_EN signal does not conform to the VESA protocol. BL_EN signal needs to be pulled high after video signal. So add prepare_to_enable to 200ms. [ dianders: Adjusted subject prefix and added Fixes tag ] Fixes: 0547692ac146 ("drm/panel-edp: Add several generic edp panels") Signed-off-by: Zhengqiao Xia Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20240301084006.14422-1-xiazhengqiao@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin commit 0baa80343e78b9b69bb14d23d1dfe032dc95ad93 Author: Luiz Augusto von Dentz Date: Mon May 13 16:07:55 2024 -0400 Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1 [ Upstream commit e77f43d531af41e9ce299eab10dcae8fa5dbc293 ] If hdev->le_num_of_adv_sets is set to 1 it means that only handle 0x00 can be used, but since the MGMT interface instances start from 1 (instance 0 means all instances in case of MGMT_OP_REMOVE_ADVERTISING) the code needs to map the instance to handle otherwise users will not be able to advertise as instance 1 would attempt to use handle 0x01. Fixes: 1d0fac2c38ed ("Bluetooth: Use controller sets when available") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit ec339f0c3472445003b47f28da951e119446146c Author: Gustavo A. R. Silva Date: Fri Apr 26 16:52:46 2024 -0600 Bluetooth: hci_conn, hci_sync: Use __counted_by() to avoid -Wfamnae warnings [ Upstream commit c4585edf708edb5277a3cc4b8581ccb833f3307d ] Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). Also, -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, use the `DEFINE_FLEX()` helper for multiple on-stack definitions of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. Notice that, due to the use of `__counted_by()` in `struct hci_cp_le_create_cis`, the for loop in function `hci_cs_le_create_cis()` had to be modified. Once the index `i`, through which `cp->cis[i]` is accessed, falls in the interval [0, cp->num_cis), `cp->num_cis` cannot be decremented all the way down to zero while accessing `cp->cis[]`: net/bluetooth/hci_event.c:4310: 4310 for (i = 0; cp->num_cis; cp->num_cis--, i++) { ... 4314 handle = __le16_to_cpu(cp->cis[i].cis_handle); otherwise, only half (one iteration before `cp->num_cis == i`) or half plus one (one iteration before `cp->num_cis < i`) of the items in the array will be accessed before running into an out-of-bounds issue. So, in order to avoid this, set `cp->num_cis` to zero just after the for loop. Also, make use of `aux_num_cis` variable to update `cmd->num_cis` after a `list_for_each_entry_rcu()` loop. With these changes, fix the following warnings: net/bluetooth/hci_sync.c:1239:56: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] net/bluetooth/hci_sync.c:1415:51: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] net/bluetooth/hci_sync.c:1731:51: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] net/bluetooth/hci_sync.c:6497:45: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Link: https://github.com/KSPP/linux/issues/202 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: e77f43d531af ("Bluetooth: hci_core: Fix not handling hdev->le_num_of_adv_sets=1") Signed-off-by: Sasha Levin commit af1d425b6dc67cd67809f835dd7afb6be4d43e03 Author: Luiz Augusto von Dentz Date: Mon May 6 18:33:52 2024 -0400 Bluetooth: HCI: Remove HCI_AMP support [ Upstream commit 84a4bb6548a29326564f0e659fb8064503ecc1c7 ] Since BT_HS has been remove HCI_AMP controllers no longer has any use so remove it along with the capability of creating AMP controllers. Since we no longer need to differentiate between AMP and Primary controllers, as only HCI_PRIMARY is left, this also remove hdev->dev_type altogether. Fixes: e7b02296fb40 ("Bluetooth: Remove BT_HS") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit c581c331100ad5fe1d332e541b6b854a56450898 Author: Iulia Tanasescu Date: Tue Apr 2 14:39:30 2024 +0300 Bluetooth: ISO: Make iso_get_sock_listen generic [ Upstream commit 311527e9dafdcae0c5a20d62f4f84ad01b33b5f4 ] This makes iso_get_sock_listen more generic, to return matching socket in the state provided as argument. Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()") Signed-off-by: Sasha Levin commit 4a171b9054f1ce9f7667bf91ce9125625209b874 Author: Dan Carpenter Date: Sat May 4 14:25:43 2024 +0300 Bluetooth: qca: Fix error code in qca_read_fw_build_info() [ Upstream commit a189f0ee6685457528db7a36ded3085e5d13ddc3 ] Return -ENOMEM on allocation failure. Don't return success. Fixes: cda0d6a198e2 ("Bluetooth: qca: fix info leak when fetching fw build id") Signed-off-by: Dan Carpenter Reviewed-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 0c287656fce837201c295fc4f9747603593615b2 Author: Sebastian Urban Date: Wed May 1 12:08:58 2024 +0200 Bluetooth: compute LE flow credits based on recvbuf space [ Upstream commit ce60b9231b66710b6ee24042ded26efee120ecfc ] Previously LE flow credits were returned to the sender even if the socket's receive buffer was full. This meant that no back-pressure was applied to the sender, thus it continued to send data, resulting in data loss without any error being reported. Furthermore, the amount of credits was essentially fixed to a small amount, leading to reduced performance. This is fixed by computing the number of returned LE flow credits based on the estimated available space in the receive buffer of an L2CAP socket. Consequently, if the receive buffer is full, no credits are returned until the buffer is read and thus cleared by user-space. Since the computation of available receive buffer space can only be performed approximately (due to sk_buff overhead) and the receive buffer size may be changed by user-space after flow credits have been sent, superfluous received data is temporary stored within l2cap_pinfo. This is necessary because Bluetooth LE provides no retransmission mechanism once the data has been acked by the physical layer. If receive buffer space estimation is not possible at the moment, we fall back to providing credits for one full packet as before. This is currently the case during connection setup, when MPS is not yet available. Fixes: b1c325c23d75 ("Bluetooth: Implement returning of LE L2CAP credits") Signed-off-by: Sebastian Urban Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 64a47cf634ae44e92be24ebc982410841093bd7b Author: Horatiu Vultur Date: Mon May 13 21:21:57 2024 +0200 net: micrel: Fix receiving the timestamp in the frame for lan8841 [ Upstream commit aea27a92a41dae14843f92c79e9e42d8f570105c ] The blamed commit started to use the ptp workqueue to get the second part of the timestamp. And when the port was set down, then this workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING is not enabled, then the ptp_clock is not initialized so then it would crash when it would try to access the delayed work. So then basically by setting up and then down the port, it would crash. The fix consists in checking if the ptp_clock is initialized and only then cancel the delayed work. Fixes: cc7554954848 ("net: micrel: Change to receive timestamp in the frame for lan8841") Signed-off-by: Horatiu Vultur Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f476aff2d8da1a189621c4c16a76a6c534e4312 Author: Xiaolei Wang Date: Mon May 13 09:43:45 2024 +0800 net: stmmac: move the EST lock to struct stmmac_priv [ Upstream commit 36ac9e7f2e5786bd37c5cd91132e1f39c29b8197 ] Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c Fixes: b2aae654a479 ("net: stmmac: add mutex lock to protect est parameters") Signed-off-by: Xiaolei Wang Reviewed-by: Simon Horman Reviewed-by: Serge Semin Reviewed-by: Andrew Halaney Link: https://lore.kernel.org/r/20240513014346.1718740-2-xiaolei.wang@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c4d5cc8ce9842a6638fca44c50fa53571a6a2e85 Author: Matthieu Baerts (NGI0) Date: Mon May 13 18:13:26 2024 -0700 mptcp: fix full TCP keep-alive support [ Upstream commit bd11dc4fb969ec148e50cd87f88a78246dbc4d0b ] SO_KEEPALIVE support has been added a while ago, as part of a series "adding SOL_SOCKET" support. To have a full control of this keep-alive feature, it is important to also support TCP_KEEP* socket options at the SOL_TCP level. Supporting them on the setsockopt() part is easy, it is just a matter of remembering each value in the MPTCP sock structure, and calling tcp_sock_set_keep*() helpers on each subflow. If the value is not modified (0), calling these helpers will not do anything. For the getsockopt() part, the corresponding value from the MPTCP sock structure or the default one is simply returned. All of this is very similar to other TCP_* socket options supported by MPTCP. It looks important for kernels supporting SO_KEEPALIVE, to also support TCP_KEEP* options as well: some apps seem to (wrongly) consider that if the former is supported, the latter ones will be supported as well. But also, not having this simple and isolated change is preventing MPTCP support in some apps, and libraries like GoLang [1]. This is why this patch is seen as a fix. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/383 Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY") Link: https://github.com/golang/go/issues/56539 [1] Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20240514011335.176158-3-martineau@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bcd9450e672f9290a98d53aae804dad183bb3a5f Author: Matthieu Baerts (NGI0) Date: Mon May 13 18:13:25 2024 -0700 mptcp: SO_KEEPALIVE: fix getsockopt support [ Upstream commit a65198136eaa15b74ee0abf73f12ef83d469a334 ] SO_KEEPALIVE support has to be set on each subflow: on each TCP socket, where sk_prot->keepalive is defined. Technically, nothing has to be done on the MPTCP socket. That's why mptcp_sol_socket_sync_intval() was called instead of mptcp_sol_socket_intval(). Except that when nothing is done on the MPTCP socket, the getsockopt(SO_KEEPALIVE), handled in net/core/sock.c:sk_getsockopt(), will not know if SO_KEEPALIVE has been set on the different subflows or not. The fix is simple: simply call mptcp_sol_socket_intval() which will end up calling net/core/sock.c:sk_setsockopt() where the SOCK_KEEPOPEN flag will be set, the one used in sk_getsockopt(). So now, getsockopt(SO_KEEPALIVE) on an MPTCP socket will return the same value as the one previously set with setsockopt(SO_KEEPALIVE). Fixes: 1b3e7ede1365 ("mptcp: setsockopt: handle SO_KEEPALIVE and SO_PRIORITY") Acked-by: Paolo Abeni Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: Mat Martineau Link: https://lore.kernel.org/r/20240514011335.176158-2-martineau@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f Author: Wei Fang Date: Sat May 11 14:20:09 2024 +0800 net: fec: remove .ndo_poll_controller to avoid deadlocks [ Upstream commit c2e0c58b25a0a0c37ec643255558c5af4450c9f5 ] There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. Fixes: 7f5c6addcdc0 ("net/fec: add poll controller function for fec nic") Signed-off-by: Wei Fang Link: https://lore.kernel.org/r/20240511062009.652918-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0aca9ef921fe24257efb2210dabaf1dcb04dfa05 Author: Chen Ni Date: Mon May 13 11:28:24 2024 +0800 dpll: fix return value check for kmemdup [ Upstream commit ad506586cb69292b6ac59ab95468aadd54b19ab7 ] The return value of kmemdup() is dst->freq_supported, not src->freq_supported. Update the check accordingly. Fixes: 830ead5fb0c5 ("dpll: fix pin dump crash for rebound module") Signed-off-by: Chen Ni Reviewed-by: Przemek Kitszel Reviewed-by: Arkadiusz Kubalewski Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240513032824.2410459-1-nichen@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit eef95df9b752699bddecefa851f64858247246e9 Author: Duoming Zhou Date: Thu May 9 17:37:02 2024 +0800 ax25: Fix reference count leak issue of net_device [ Upstream commit 36e56b1b002bb26440403053f19f9e1a8bc075b2 ] There is a reference count leak issue of the object "net_device" in ax25_dev_device_down(). When the ax25 device is shutting down, the ax25_dev_device_down() drops the reference count of net_device one or zero times depending on if we goto unlock_put or not, which will cause memory leak. In order to solve the above issue, decrease the reference count of net_device after dev->ax25_ptr is set to null. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter Signed-off-by: Duoming Zhou Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/7ce3b23a40d9084657ba1125432f0ecc380cbc80.1715247018.git.duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1ea02699c7557eeb35ccff2bd822de1b3e09d868 Author: Duoming Zhou Date: Thu May 9 17:36:47 2024 +0800 ax25: Fix reference count leak issues of ax25_dev [ Upstream commit b505e0319852b08a3a716b64620168eab21f4ced ] The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference count leak issue of the object "ax25_dev". Memory leak issue in ax25_addr_ax25dev(): The reference count of the object "ax25_dev" can be increased multiple times in ax25_addr_ax25dev(). This will cause a memory leak. Memory leak issues in ax25_dev_device_down(): The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and then increase the reference count when ax25_dev is added to ax25_dev_list. As a result, the reference count of ax25_dev is 2. But when the device is shutting down. The ax25_dev_device_down() drops the reference count once or twice depending on if we goto unlock_put or not, which will cause memory leak. As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the issue of ax25_dev_device_down(), increase the reference count of ax25_dev once in ax25_dev_device_up() and decrease the reference count of ax25_dev after it is removed from the ax25_dev_list. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Suggested-by: Dan Carpenter Signed-off-by: Duoming Zhou Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/361bbf2a4b091e120006279ec3b382d73c4a0c17.1715247018.git.duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5954945db960bfb8edad4234c1d1a13fb48e7424 Author: Duoming Zhou Date: Thu May 9 17:36:33 2024 +0800 ax25: Use kernel universal linked list to implement ax25_dev_list [ Upstream commit a7d6e36b9ad052926ba2ecba3a59d8bb67dabcb4 ] The origin ax25_dev_list implements its own single linked list, which is complicated and error-prone. For example, when deleting the node of ax25_dev_list in ax25_dev_device_down(), we have to operate on the head node and other nodes separately. This patch uses kernel universal linked list to replace original ax25_dev_list, which make the operation of ax25_dev_list easier. We should do "dev->ax25_ptr = ax25_dev;" and "dev->ax25_ptr = NULL;" while holding the spinlock, otherwise the ax25_dev_device_up() and ax25_dev_device_down() could race. Suggested-by: Dan Carpenter Signed-off-by: Duoming Zhou Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/85bba3af651ca0e1a519da8d0d715b949891171c.1715247018.git.duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Stable-dep-of: b505e0319852 ("ax25: Fix reference count leak issues of ax25_dev") Signed-off-by: Sasha Levin commit 130be64399dd18a268e28207a1e7029fb6713234 Author: Eric Dumazet Date: Fri May 10 07:29:32 2024 +0000 inet: fix inet_fill_ifaddr() flags truncation [ Upstream commit 1af7f88af269c4e06a4dc3bc920ff6cdf7471124 ] I missed that (struct ifaddrmsg)->ifa_flags was only 8bits, while (struct in_ifaddr)->ifa_flags is 32bits. Use a temporary 32bit variable as I did in set_ifa_lifetime() and check_lifetime(). Fixes: 3ddc2231c810 ("inet: annotate data-races around ifa->ifa_flags") Reported-by: Yu Watanabe Dianosed-by: Yu Watanabe Closes: https://github.com/systemd/systemd/pull/32666#issuecomment-2103977928 Signed-off-by: Eric Dumazet Reviewed-by: Larysa Zaremba Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240510072932.2678952-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e2707bcf66f3e56bd84585c9ca20b328a4e51e1f Author: Puranjay Mohan Date: Sun May 5 20:16:33 2024 +0000 riscv, bpf: make some atomic operations fully ordered [ Upstream commit 20a759df3bba35bf5c3ddec0c02ad69b603b584c ] The BPF atomic operations with the BPF_FETCH modifier along with BPF_XCHG and BPF_CMPXCHG are fully ordered but the RISC-V JIT implements all atomic operations except BPF_CMPXCHG with relaxed ordering. Section 8.1 of the "The RISC-V Instruction Set Manual Volume I: Unprivileged ISA" [1], titled, "Specifying Ordering of Atomic Instructions" says: | To provide more efficient support for release consistency [5], each | atomic instruction has two bits, aq and rl, used to specify additional | memory ordering constraints as viewed by other RISC-V harts. and | If only the aq bit is set, the atomic memory operation is treated as | an acquire access. | If only the rl bit is set, the atomic memory operation is treated as a | release access. | | If both the aq and rl bits are set, the atomic memory operation is | sequentially consistent. Fix this by setting both aq and rl bits as 1 for operations with BPF_FETCH and BPF_XCHG. [1] https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2.pdf Fixes: dd642ccb45ec ("riscv, bpf: Implement more atomic operations for RV64") Signed-off-by: Puranjay Mohan Reviewed-by: Pu Lehui Link: https://lore.kernel.org/r/20240505201633.123115-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 193377faffac6beee700de1885a84639dc8d65a2 Author: Ilya Leoshkevich Date: Tue May 7 02:02:49 2024 +0200 s390/bpf: Emit a barrier for BPF_FETCH instructions [ Upstream commit 68378982f0b21de02ac3c6a11e2420badefcb4bc ] BPF_ATOMIC_OP() macro documentation states that "BPF_ADD | BPF_FETCH" should be the same as atomic_fetch_add(), which is currently not the case on s390x: the serialization instruction "bcr 14,0" is missing. This applies to "and", "or" and "xor" variants too. s390x is allowed to reorder stores with subsequent fetches from different addresses, so code relying on BPF_FETCH acting as a barrier, for example: stw [%r0], 1 afadd [%r1], %r2 ldxw %r3, [%r4] may be broken. Fix it by emitting "bcr 14,0". Note that a separate serialization instruction is not needed for BPF_XCHG and BPF_CMPXCHG, because COMPARE AND SWAP performs serialization itself. Fixes: ba3b86b9cef0 ("s390/bpf: Implement new atomic ops") Reported-by: Puranjay Mohan Closes: https://lore.kernel.org/bpf/mb61p34qvq3wf.fsf@kernel.org/ Signed-off-by: Ilya Leoshkevich Reviewed-by: Puranjay Mohan Link: https://lore.kernel.org/r/20240507000557.12048-1-iii@linux.ibm.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 7ac4c69c34240c6de820492c0a28a0bd1494265a Author: Akiva Goldberger Date: Thu May 9 14:29:51 2024 +0300 net/mlx5: Discard command completions in internal error [ Upstream commit db9b31aa9bc56ff0d15b78f7e827d61c4a096e40 ] Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually. Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 asm_common_interrupt+0x22/0x40 Fixes: 51d138c2610a ("net/mlx5: Fix health error state handling") Signed-off-by: Akiva Goldberger Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://lore.kernel.org/r/20240509112951.590184-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 94024332a129c6e4275569d85c0c1bfb2ae2d71b Author: Akiva Goldberger Date: Thu May 9 14:29:50 2024 +0300 net/mlx5: Add a timeout to acquire the command queue semaphore [ Upstream commit 485d65e1357123a697c591a5aeb773994b247ad7 ] Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion Fixes: 8e715cd613a1 ("net/mlx5: Set command entry semaphore up once got index free") Signed-off-by: Akiva Goldberger Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://lore.kernel.org/r/20240509112951.590184-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0f320f28f54b1b269a755be2e3fb3695e0b80b07 Author: Maher Sanalla Date: Thu May 9 14:29:49 2024 +0300 net/mlx5: Reload only IB representors upon lag disable/enable [ Upstream commit 0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4 ] On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded. In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock: Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180 Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above. While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design. Fixes: 598fe77df855 ("net/mlx5: Lag, Create shared FDB when in switchdev mode") Co-developed-by: Mark Bloch Signed-off-by: Mark Bloch Signed-off-by: Maher Sanalla Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240509112951.590184-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 05d9d7b66836d87c914f8fdd4b062b78e373458d Author: Shay Drory Date: Thu May 9 14:29:48 2024 +0300 net/mlx5: Fix peer devlink set for SF representor devlink port [ Upstream commit 3c453e8cc672de1f9c662948dba43176bc68d7f0 ] The cited patch change register devlink flow, and neglect to reflect the changes for peer devlink set logic. Peer devlink set is triggering a call trace if done after devl_register.[1] Hence, align peer devlink set logic with register devlink flow. [1] WARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180 CPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core] RIP: 0010:devlink_rel_nested_in_add+0x177/0x180 Call Trace: ? __warn+0x78/0x120 ? devlink_rel_nested_in_add+0x177/0x180 ? report_bug+0x16d/0x180 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? devlink_port_init+0x30/0x30 ? devlink_port_type_clear+0x50/0x50 ? devlink_rel_nested_in_add+0x177/0x180 ? devlink_rel_nested_in_add+0xdd/0x180 mlx5_sf_mdev_event+0x74/0xb0 [mlx5_core] notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_sf_dev_probe+0x185/0x3e0 [mlx5_core] auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc5/0x3a0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x64f/0x860 __auxiliary_device_add+0x3b/0xa0 mlx5_sf_dev_add+0x139/0x330 [mlx5_core] mlx5_sf_dev_state_change_handler+0x1e4/0x250 [mlx5_core] notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_vhca_state_work_handler+0x151/0x200 [mlx5_core] process_one_work+0x13f/0x2e0 worker_thread+0x2bd/0x3c0 ? rescuer_thread+0x410/0x410 kthread+0xc4/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x2d/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 Fixes: bf729988303a ("net/mlx5: Restore mistakenly dropped parts in register devlink flow") Fixes: c6e77aa9dd82 ("net/mlx5: Register devlink first under devlink lock") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240509112951.590184-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7e6cfb864a53af71c5cc904f1cc22215d68f5c6 Author: Shay Drory Date: Thu May 9 14:29:47 2024 +0300 net/mlx5e: Fix netif state handling [ Upstream commit 3d5918477f94e4c2f064567875c475468e264644 ] mlx5e_suspend cleans resources only if netif_device_present() returns true. However, mlx5e_resume changes the state of netif, via mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks: mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason. ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :( Hence, clean resources in this case as well. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- Fixes: 2c3b5beec46a ("net/mlx5e: More generic netdev management API") Signed-off-by: Shay Drory Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240509112951.590184-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c04d6a914e890ccea4a9d11233009a2ee7978bf4 Author: Hangbin Liu Date: Thu May 9 21:18:12 2024 +0800 ipv6: sr: fix invalid unregister error path [ Upstream commit 160e9d2752181fcf18c662e74022d77d3164cd45 ] The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. Fixes: 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support") Reported-by: Guillaume Nault Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240509131812.1662197-4-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50e53295d9d4f44b3552aced211392d622966e35 Author: Hangbin Liu Date: Thu May 9 21:18:11 2024 +0800 ipv6: sr: fix incorrect unregister order [ Upstream commit 6e370a771d2985107e82d0f6174381c1acb49c20 ] Commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") changed the register order in seg6_init(). But the unregister order in seg6_exit() is not updated. Fixes: 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240509131812.1662197-3-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 54a6fb69df5838495844476e07fa6b9dbdb252e9 Author: Hangbin Liu Date: Thu May 9 21:18:10 2024 +0800 ipv6: sr: add missing seg6_local_exit [ Upstream commit 3321687e321307629c71b664225b861ebf3e5753 ] Currently, we only call seg6_local_exit() in seg6_init() if seg6_local_init() failed. But forgot to call it in seg6_exit(). Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local lightweight tunnel") Signed-off-by: Hangbin Liu Reviewed-by: Sabrina Dubroca Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240509131812.1662197-2-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d73fb8bddf89503c9fae7c42e50d44c89909aad6 Author: Ilya Maximets Date: Thu May 9 11:38:05 2024 +0200 net: openvswitch: fix overwriting ct original tuple for ICMPv6 [ Upstream commit 7c988176b6c16c516474f6fceebe0f055af5eb56 ] OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. Fixes: 9dd7f8907c37 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Reported-by: Antonin Bas Closes: https://github.com/openvswitch/ovs-issues/issues/327 Signed-off-by: Ilya Maximets Acked-by: Aaron Conole Acked-by: Eelco Chaudron Link: https://lore.kernel.org/r/20240509094228.1035477-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8410a1b60cb12064b3e439d25d123f99bac3811d Author: Eric Dumazet Date: Thu May 9 08:33:13 2024 +0000 net: usb: smsc95xx: stop lying about skb->truesize [ Upstream commit d50729f1d60bca822ef6d9c1a5fb28d486bd7593 ] Some usb drivers try to set small skb->truesize and break core networking stacks. In this patch, I removed one of the skb->truesize override. I also replaced one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a: stop lying about skb->truesize") v3: also fix a sparse error ( https://lore.kernel.org/oe-kbuild-all/202405091310.KvncIecx-lkp@intel.com/ ) v2: leave the skb_trim() game because smsc95xx_rx_csum_offload() needs the csum part. (Jakub) While we are it, use get_unaligned() in smsc95xx_rx_csum_offload(). Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver") Signed-off-by: Eric Dumazet Cc: Steve Glendinning Cc: UNGLinuxDriver@microchip.com Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240509083313.2113832-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a52fa2addfcccc2c5a0217fd45562605088c018b Author: Breno Leitao Date: Thu May 9 01:14:46 2024 -0700 af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg [ Upstream commit 540bf24fba16b88c1b3b9353927204b4f1074e25 ] A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03 The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7"). Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in Link: https://lore.kernel.org/all/20240508173324.53565-1-kuniyu@amazon.com/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Breno Leitao Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240509081459.2807828-1-leitao@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7688fc597bb6613755fafb277c2ab1d60ae99579 Author: Linus Walleij Date: Thu May 9 09:44:54 2024 +0200 net: ethernet: cortina: Locking fixes [ Upstream commit 812552808f7ff71133fc59768cdc253c5b8ca1bf ] This fixes a probably long standing problem in the Cortina Gemini ethernet driver: there are some paths in the code where the IRQ registers are written without taking the proper locks. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Linus Walleij Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240509-gemini-ethernet-locking-v1-1-afd00a528b95@linaro.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 229a944eee346e383f3f9ed34e92a7d992b3fdba Author: Dan Nowlin Date: Wed May 8 10:19:07 2024 -0700 ice: Fix package download algorithm [ Upstream commit 6d51d44ecddb5c2962688ef06e55e4fbc949f04a ] Previously, the driver assumed that all signature segments would contain one or more buffers to download. In the future, there will be signature segments that will contain no buffers to download. Correct download flow to allow for signature segments that have zero download buffers and skip the download in this case. Fixes: 3cbdb0343022 ("ice: Add support for E830 DDP package segment") Reviewed-by: Przemek Kitszel Signed-off-by: Dan Nowlin Signed-off-by: Paul Greenwalt Reviewed-by: Paul Menzel Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20240508171908.2760776-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 18523fcfbae8ff7833da6c80879d8d4743d621f9 Author: Daniel Golle Date: Wed May 8 11:43:56 2024 +0100 net: ethernet: mediatek: use ADMAv1 instead of ADMAv2.0 on MT7981 and MT7986 [ Upstream commit 5e69ff84f3e6cc54502a902043847b37ed78afd4 ] ADMAv2.0 is plagued by RX hangs which can't easily detected and happen upon receival of a corrupted Ethernet frame. Use ADMAv1 instead which is also still present and usable, and doesn't suffer from that problem. Fixes: 197c9e9b17b1 ("net: ethernet: mtk_eth_soc: introduce support for mt7986 chipset") Co-developed-by: Lorenzo Bianconi Signed-off-by: Lorenzo Bianconi Signed-off-by: Daniel Golle Link: https://lore.kernel.org/r/57cef74bbd0c243366ad1ff4221e3f72f437ec80.1715164770.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 079ff14c52e09ae09a4a235ddda5aeeac221354b Author: Lorenzo Bianconi Date: Wed May 8 11:43:34 2024 +0100 net: ethernet: mediatek: split tx and rx fields in mtk_soc_data struct [ Upstream commit ecb51fa37ee22f137a87fa140b1e9f1759949f9a ] Split tx and rx fields in mtk_soc_data struct. This is a preliminary patch to roll back to ADMAv1 for MT7986 and MT7981 SoC in order to fix a hw hang if the device receives a corrupted packet when using ADMAv2.0. Fixes: 197c9e9b17b1 ("net: ethernet: mtk_eth_soc: introduce support for mt7986 chipset") Signed-off-by: Lorenzo Bianconi Signed-off-by: Daniel Golle Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/70a799b1f060ec2f57883e88ccb420ac0fb0abb5.1715164770.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 09fb14d234fa84af8d86cb11a2d1b928877d0fe0 Author: Jakub Kicinski Date: Thu May 9 09:19:52 2024 -0700 selftests: net: move amt to socat for better compatibility [ Upstream commit 4c639b6a7b9db236c0907aca8e92d1537076f2cd ] The test seems to expect that nc will exit after the first received message. This is not the case with Ncat 7.94. There are multiple versions of nc out there, switch to socat for better compatibility. Tell socat to exit after 128 bytes and pad the message. Since the test sets -e make sure we don't set exit code (|| true) and print the pass / fail rather then silently moving over the test and just setting non-zero exit code with no output indicating what failed. Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Acked-by: Paolo Abeni Tested-by: Taehee Yoo Link: https://lore.kernel.org/r/20240509161952.3940476-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8893b4310e6d02d2a5492918b4cd1e22209a9231 Author: Jakub Kicinski Date: Thu May 9 09:19:19 2024 -0700 selftests: net: add missing config for amt.sh [ Upstream commit c499fe96d3f75a5cf50de6089dd8f1cddd1301a9 ] Test needs IPv6 multicast. smcroute currently crashes when trying to install a route in a kernel without IPv6 multicast. Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Link: https://lore.kernel.org/r/20240509161919.3939966-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6400d205fbbcbcf9b8510157e1f379c1d7e2e937 Author: Jakub Kicinski Date: Wed May 8 06:45:04 2024 -0700 eth: sungem: remove .ndo_poll_controller to avoid deadlocks [ Upstream commit ac0a230f719b02432d8c7eba7615ebd691da86f4 ] Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly. Fixes: fe09bb619096 ("sungem: Spring cleaning and GRO support") Reported-and-tested-by: Erhard Furtner Link: https://lore.kernel.org/all/20240428125306.2c3080ef@legion Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240508134504.3560956-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fe61cf7d4e9bf2e9f34e320bc927f7ffec112e7 Author: gaoxingwang Date: Mon Apr 22 17:19:17 2024 +0800 net: ipv6: fix wrong start position when receive hop-by-hop fragment [ Upstream commit 1cd354fe1e4864eeaff62f66ee513080ec946f20 ] In IPv6, ipv6_rcv_core will parse the hop-by-hop type extension header and increase skb->transport_header by one extension header length. But if there are more other extension headers like fragment header at this time, the skb->transport_header points to the second extension header, not the transport layer header or the first extension header. This will result in the start and nexthdrp variable not pointing to the same position in ipv6frag_thdr_trunced, and ipv6_skip_exthdr returning incorrect offset and frag_off.Sometimes,the length of the last sharded packet is smaller than the calculated incorrect offset, resulting in packet loss. We can use network header to offset and calculate the correct position to solve this problem. Fixes: 9d9e937b1c8b (ipv6/netfilter: Discard first fragment not including all headers) Signed-off-by: Gao Xingwang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c243789992ada25286730eb650255371b4acaefc Author: Vadim Fedorenko Date: Wed May 8 13:21:11 2024 +0000 ptp: ocp: fix DPLL functions [ Upstream commit a2c78977950da00aca83a3f8865d1f54e715770d ] In ptp_ocp driver pin actions assume sma_nr starts with 1, but for DPLL subsystem callback 0-based index was used. Fix it providing proper index. Fixes: 09eeb3aecc6c ("ptp_ocp: implement DPLL ops") Signed-off-by: Vadim Fedorenko Link: https://lore.kernel.org/r/20240508132111.11545-1-vadim.fedorenko@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ff499d5a3fb15db07788c4d4d3e4199f21c78760 Author: Benjamin Marzinski Date: Mon May 6 17:55:44 2024 -0400 dm-delay: fix max_delay calculations [ Upstream commit 64eb88d6caee2c8eb806a68dab3f184f14f818a4 ] delay_ctr() pointlessly compared max_delay in cases where multiple delay classes were initialized identically. Also, when write delays were configured different than read delays, delay_ctr() never compared their value against max_delay. Fix these issues. Fixes: 70bbeb29fab0 ("dm delay: for short delays, use kthread instead of timers and wq") Signed-off-by: Benjamin Marzinski Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit aa9d9cbc69d60dc7505331354f99458537df278e Author: Joel Colledge Date: Mon May 6 09:25:23 2024 +0200 dm-delay: fix hung task introduced by kthread mode [ Upstream commit d14646f23300a5fc85be867bafdc0702c2002789 ] If the worker thread is not woken due to a bio, then it is not woken at all. This causes the hung task check to trigger. This occurs, for instance, when no bios are submitted. Also when a delay of 0 is configured, delay_bio() returns without waking the worker. Prevent the hung task check from triggering by creating the thread with kthread_run() instead of using kthread_create() directly. Fixes: 70bbeb29fab0 ("dm delay: for short delays, use kthread instead of timers and wq") Signed-off-by: Joel Colledge Reviewed-by: Benjamin Marzinski Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit d23afe03255dc5e3648c7da04da86237c961d740 Author: Benjamin Marzinski Date: Tue May 7 17:16:23 2024 -0400 dm-delay: fix workqueue delay_timer race [ Upstream commit 8d24790ed08ab4e619ce58ed4a1b353ab77ffdc5 ] delay_timer could be pending when delay_dtr() is called. It needs to be shut down before kdelayd_wq is destroyed, so it won't try queueing more work to kdelayd_wq while that's getting destroyed. Also the del_timer_sync() call in delay_presuspend() doesn't protect against the timer getting immediately rearmed by the queued call to flush_delayed_bios(), but there's no real harm if that does happen. timer_delete() is less work, and is basically just as likely to stop a pointless call to flush_delayed_bios(). Fixes: 26b9f228703f ("dm: delay target") Signed-off-by: Benjamin Marzinski Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit efc40e63687843fe525f1bd4c5eda854f53f33ce Author: Edward Liaw Date: Tue May 7 21:38:27 2024 +0000 selftests/sgx: Include KHDR_INCLUDES in Makefile [ Upstream commit 2c3b8f8f37c6c0c926d584cf4158db95e62b960c ] Add KHDR_INCLUDES to the CFLAGS to pull in the kselftest harness dependencies (-D_GNU_SOURCE). Also, remove redefinitions of _GNU_SOURCE in the source code. Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202404301040.3bea5782-oliver.sang@intel.com Signed-off-by: Edward Liaw Reviewed-by: Muhammad Usama Anjum Acked-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Reviewed-by: John Hubbard Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 0317af7a8fe64947169ea7ed5ad12e6805c05f0a Author: Edward Liaw Date: Tue May 7 21:38:26 2024 +0000 selftests: Compile kselftest headers with -D_GNU_SOURCE [ Upstream commit daef47b89efd0b745e8478d69a3ad724bd8b4dc6 ] Add the -D_GNU_SOURCE flag to KHDR_INCLUDES so that it is defined in a central location. Commit 809216233555 ("selftests/harness: remove use of LINE_MAX") introduced asprintf into kselftest_harness.h, which is a GNU extension and needs _GNU_SOURCE to either be defined prior to including headers or with the -D_GNU_SOURCE flag passed to the compiler. Fixed up commit log: Shuah Khan Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202404301040.3bea5782-oliver.sang@intel.com Signed-off-by: Edward Liaw Reviewed-by: Muhammad Usama Anjum Reviewed-by: Mark Brown Reviewed-by: John Hubbard Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 0b10da639b03d421bd1b2150edb98687a63aa739 Author: Geert Uytterhoeven Date: Mon May 6 09:06:41 2024 +0200 m68k: Move ARCH_HAS_CPU_CACHE_ALIASING [ Upstream commit c66b7b950bbf45eadcdee467e53f80568f4a0a7f ] Move the recently added ARCH_HAS_CPU_CACHE_ALIASING to restore alphabetical sort order. Fixes: 8690bbcf3b7010b3 ("Introduce cpu_dcache_is_aliasing() across all architectures") Signed-off-by: Geert Uytterhoeven Reviewed-by: Mathieu Desnoyers Link: https://lore.kernel.org/r/4574ad6cc1117e4b5d29812c165bf7f6e5b60773.1714978406.git.geert@linux-m68k.org Signed-off-by: Sasha Levin commit bde63834702c8f9ebd35094cd9d016da61a0084e Author: Finn Thain Date: Sat May 4 14:31:12 2024 +1000 m68k: mac: Fix reboot hang on Mac IIci [ Upstream commit 265a3b322df9a973ff1fc63da70af456ab6ae1d6 ] Calling mac_reset() on a Mac IIci does reset the system, but what follows is a POST failure that requires a manual reset to resolve. Avoid that by using the 68030 asm implementation instead of the C implementation. Apparently the SE/30 has a similar problem as it has used the asm implementation since before git. This patch extends that solution to other systems with a similar ROM. After this patch, the only systems still using the C implementation are 68040 systems where adb_type is either MAC_ADB_IOP or MAC_ADB_II. This implies a 1 MiB Quadra ROM. This now includes the Quadra 900/950, which previously fell through to the "should never get here" catch-all. Reported-and-tested-by: Stan Johnson Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/480ebd1249d229c6dc1f3f1c6d599b8505483fd8.1714797072.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 95f00caf767b5968c2c51083957b38be4748a78a Author: Michael Schmitz Date: Thu Apr 11 15:36:31 2024 +1200 m68k: Fix spinlock race in kernel thread creation [ Upstream commit da89ce46f02470ef08f0f580755d14d547da59ed ] Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch. This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register. The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()). A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck. As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit. Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume(). Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed. Tested on ARAnyM and qemu (Quadra 800 emulation). Fixes: 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/all/07811b26-677c-4d05-aeb4-996cd880b789@roeck-us.net Signed-off-by: Michael Schmitz Tested-by: Guenter Roeck Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240411033631.16335-1-schmitzmic@gmail.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit c21d6d26ddb1a1e0879f92ca02c65dc4d83526b6 Author: Eric Dumazet Date: Mon May 6 14:39:39 2024 +0000 net: usb: sr9700: stop lying about skb->truesize [ Upstream commit 05417aa9c0c038da2464a0c504b9d4f99814a23b ] Some usb drivers set small skb->truesize and break core networking stacks. In this patch, I removed one of the skb->truesize override. I also replaced one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a: stop lying about skb->truesize") Fixes: c9b37458e956 ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support") Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20240506143939.3673865-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 17a562c5c8509d29521d4f607a7943b848632553 Author: Eric Dumazet Date: Mon May 6 13:55:46 2024 +0000 usb: aqc111: stop lying about skb->truesize [ Upstream commit 9aad6e45c4e7d16b2bb7c3794154b828fb4384b4 ] Some usb drivers try to set small skb->truesize and break core networking stacks. I replace one skb_clone() by an allocation of a fresh and small skb, to get minimally sized skbs, like we did in commit 1e2c61172342 ("net: cdc_ncm: reduce skb truesize in rx path") and 4ce62d5b2f7a ("net: usb: ax88179_178a: stop lying about skb->truesize") Fixes: 361459cd9642 ("net: usb: aqc111: Implement RX data path") Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20240506135546.3641185-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 381abc4b0990c046cb5bef85a6e497e1785cd3a6 Author: Josef Bacik Date: Sun Apr 14 05:42:43 2024 +0000 btrfs: set start on clone before calling copy_extent_buffer_full [ Upstream commit 53e24158684b527d013b5b2204ccb34d1f94c248 ] Our subpage testing started hanging on generic/560 and I bisected it down to 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations"). This is subtle because we use eb->start to figure out where in the folio we're copying to when we're subpage, as our ->start may refer to an area inside of the folio. For example, assume a 16K page size machine with a 4K node size, and assume that we already have a cloned extent buffer when we cloned the previous search. copy_extent_buffer_full() will do the following when copying the extent buffer path->nodes[0] (src) into cloned (dest): src->start = 8k; // this is the new leaf we're cloning cloned->start = 4k; // this is left over from the previous clone src_addr = folio_address(src->folios[0]); dest_addr = folio_address(dest->folios[0]); memcpy(dest_addr + get_eb_offset_in_folio(dst, 0), src_addr + get_eb_offset_in_folio(src, 0), src->len); Now get_eb_offset_in_folio() is where the problems occur, because for sub-pagesize blocksize we can have multiple eb's per folio, the code for this is as follows size_t get_eb_offset_in_folio(eb, offset) { return (eb->start + offset & (folio_size(eb->folio[0]) - 1)); } So in the above example we are copying into offset 4K inside the folio. However once we update cloned->start to 8K to match the src the math for get_eb_offset_in_folio() changes, and any subsequent reads (i.e. btrfs_item_key_to_cpu()) will start reading from the offset 8K instead of 4K where we copied to, giving us garbage. Fix this by setting start before we co copy_extent_buffer_full() to make sure that we're copying into the same offset inside of the folio that we will read from later. All other sites of copy_extent_buffer_full() are correct because we either set ->start beforehand or we simply don't change it in the case of the tree-log usage. With this fix we now pass generic/560 on our subpage tests. Fixes: 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") Reviewed-by: Filipe Manana Reviewed-by: Qu Wenruo Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit f8eadc97a17c927b845209438dae7d3c69df72c5 Author: Basavaraj Natikar Date: Tue May 7 12:40:44 2024 +0530 HID: amd_sfh: Handle "no sensors" in PM operations [ Upstream commit 077e3e3bc84a51891e732507bbbd9acf6e0e4c8b ] Resume or suspend each sensor device based on the num_hid_devices. Therefore, add a check to handle the special case where no sensors are present. Fixes: 93ce5e0231d7 ("HID: amd_sfh: Implement SFH1.1 functionality") Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2abef3e89e6c5e98461ef7fa852644537a8b0aeb Author: Dan Carpenter Date: Sat May 4 14:38:15 2024 +0300 wifi: mwl8k: initialize cmd->addr[] properly [ Upstream commit 1d60eabb82694e58543e2b6366dae3e7465892a5 ] This loop is supposed to copy the mac address to cmd->addr but the i++ increment is missing so it copies everything to cmd->addr[0] and only the last address is recorded. Fixes: 22bedad3ce11 ("net: convert multicast list to list_head") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://msgid.link/b788be9a-15f5-4cca-a3fe-79df4c8ce7b2@moroto.mountain Signed-off-by: Sasha Levin commit b6ab0282b50c8a502fc0d230c4738936807ba23a Author: Robert Richter Date: Thu May 2 15:10:09 2024 +0200 x86/numa: Fix SRAT lookup of CFMWS ranges with numa_fill_memblks() [ Upstream commit f9f67e5adc8dc2e1cc51ab2d3d6382fa97f074d4 ] For configurations that have the kconfig option NUMA_KEEP_MEMINFO disabled, numa_fill_memblks() only returns with NUMA_NO_MEMBLK (-1). SRAT lookup fails then because an existing SRAT memory range cannot be found for a CFMWS address range. This causes the addition of a duplicate numa_memblk with a different node id and a subsequent page fault and kernel crash during boot. Fix this by making numa_fill_memblks() always available regardless of NUMA_KEEP_MEMINFO. As Dan suggested, the fix is implemented to remove numa_fill_memblks() from sparsemem.h and alos using __weak for the function. Note that the issue was initially introduced with [1]. But since phys_to_target_node() was originally used that returned the valid node 0, an additional numa_memblk was not added. Though, the node id was wrong too, a message is seen then in the logs: kernel/numa.c: pr_info_once("Unknown target node for memory at 0x%llx, assuming node 0\n", [1] commit fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT") Suggested-by: Dan Williams Link: https://lore.kernel.org/all/66271b0072317_69102944c@dwillia2-xfh.jf.intel.com.notmuch/ Fixes: 8f1004679987 ("ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window") Reviewed-by: Jonathan Cameron Reviewed-by: Alison Schofield Reviewed-by: Dan Williams Signed-off-by: Robert Richter Acked-by: Borislav Petkov (AMD) Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6408024744948aa4dccf5cb780b59803f5d5dbf6 Author: Jim Liu Date: Mon May 6 14:42:44 2024 +0800 gpio: nuvoton: Fix sgpio irq handle error [ Upstream commit 7f45fe2ea3b8c85787976293126a4a7133b107de ] The generic_handle_domain_irq() function calls irq_resolve_mapping(). Thus delete a duplicative irq_find_mapping() call so that a stack trace and an RCU stall will be avoided. Fixes: c4f8457d17ce ("gpio: nuvoton: Add Nuvoton NPCM sgpio driver") Signed-off-by: Jim Liu Reviewed-by: Linus Walleij Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20240506064244.1645922-1-JJLIU0@nuvoton.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit ed9dc4d8b3e5bcf62aa7804729a7974bc385ebb0 Author: Himanshu Madhani Date: Fri Apr 26 02:00:56 2024 +0000 scsi: qla2xxx: Fix debugfs output for fw_resource_count [ Upstream commit 998d09c5ef6183bd8137d1a892ba255b15978bb4 ] DebugFS output for fw_resource_count shows: estimate exchange used[0] high water limit [1945] n estimate iocb2 used [0] high water limit [5141] estimate exchange2 used[0] high water limit [1945] Which shows incorrect display due to missing newline in seq_print(). [mkp: fix checkpatch warning about space before newline] Fixes: 5f63a163ed2f ("scsi: qla2xxx: Fix exchange oversubscription for management commands") Signed-off-by: Himanshu Madhani Link: https://lore.kernel.org/r/20240426020056.3639406-1-himanshu.madhani@oracle.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 177f43c6892e6055de6541fe9391a8a3d1f95fc9 Author: Bui Quang Minh Date: Wed Apr 24 21:44:21 2024 +0700 scsi: qedf: Ensure the copied buf is NUL terminated [ Upstream commit d0184a375ee797eb657d74861ba0935b6e405c62 ] Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Signed-off-by: Bui Quang Minh Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-4-f1f1b53a10f4@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ecb76200f5557a2886888aaa53702da1ab9e6cdf Author: Bui Quang Minh Date: Wed Apr 24 21:44:20 2024 +0700 scsi: bfa: Ensure the copied buf is NUL terminated [ Upstream commit 13d0cecb4626fae67c00c84d3c7851f6b62f7df3 ] Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user. Fixes: 9f30b674759b ("bfa: replace 2 kzalloc/copy_from_user by memdup_user") Signed-off-by: Bui Quang Minh Link: https://lore.kernel.org/r/20240424-fix-oob-read-v2-3-f1f1b53a10f4@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 64123660f9bce5ca9febf096ad7c1b94168fe507 Author: Chen Ni Date: Mon Apr 29 16:54:22 2024 +0800 HID: intel-ish-hid: ipc: Add check for pci_alloc_irq_vectors [ Upstream commit 6baa4524027fd64d7ca524e1717c88c91a354b93 ] Add a check for the return value of pci_alloc_irq_vectors() and return error if it fails. [jkosina@suse.com: reworded changelog based on Srinivas' suggestion] Fixes: 74fbc7d371d9 ("HID: intel-ish-hid: add MSI interrupt support") Signed-off-by: Chen Ni Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6dfbf7077473498b9de586be434c78e1d722dc40 Author: Michal Schmidt Date: Mon May 6 16:50:22 2024 +0200 selftests/bpf: Fix pointer arithmetic in test_xdp_do_redirect [ Upstream commit e549b39a0ab8880d7ae6c6495b00fc1cb8f36174 ] Cast operation has a higher precedence than addition. The code here wants to zero the 2nd half of the 64-bit metadata, but due to a pointer arithmetic mistake, it writes the zero at offset 16 instead. Just adding parentheses around "data + 4" would fix this, but I think this will be slightly better readable with array syntax. I was unable to test this with tools/testing/selftests/bpf/vmtest.sh, because my glibc is newer than glibc in the provided VM image. So I just checked the difference in the compiled code. objdump -S tools/testing/selftests/bpf/xdp_do_redirect.test.o: - *((__u32 *)data) = 0x42; /* metadata test value */ + ((__u32 *)data)[0] = 0x42; /* metadata test value */ be7: 48 8d 85 30 fc ff ff lea -0x3d0(%rbp),%rax bee: c7 00 42 00 00 00 movl $0x42,(%rax) - *((__u32 *)data + 4) = 0; + ((__u32 *)data)[1] = 0; bf4: 48 8d 85 30 fc ff ff lea -0x3d0(%rbp),%rax - bfb: 48 83 c0 10 add $0x10,%rax + bfb: 48 83 c0 04 add $0x4,%rax bff: c7 00 00 00 00 00 movl $0x0,(%rax) Fixes: 5640b6d89434 ("selftests/bpf: fix "metadata marker" getting overwritten by the netstack") Signed-off-by: Michal Schmidt Signed-off-by: Andrii Nakryiko Reviewed-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/bpf/20240506145023.214248-1-mschmidt@redhat.com Signed-off-by: Sasha Levin commit 107bbcb5d37d08c14f5648b64fff63ce0e5247ea Author: Scott Mayhew Date: Thu Mar 21 10:32:00 2024 -0400 kunit: bail out early in __kunit_test_suites_init() if there are no suites to test [ Upstream commit 5496b9b77d7420652202b73cf036e69760be5deb ] Commit c72a870926c2 added a mutex to prevent kunit tests from running concurrently. Unfortunately that mutex gets locked during module load regardless of whether the module actually has any kunit tests. This causes a problem for kunit tests that might need to load other kernel modules (e.g. gss_krb5_test loading the camellia module). So check to see if there are actually any tests to run before locking the kunit_run_lock mutex. Fixes: c72a870926c2 ("kunit: add ability to run tests after boot using debugfs") Reported-by: Nico Pache Signed-off-by: Scott Mayhew Reviewed-by: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit dfd7f89a395cf89245590b3c65b56326d86ec466 Author: Wander Lairson Costa Date: Fri Apr 19 10:25:01 2024 -0300 kunit: unregister the device on error [ Upstream commit fabd480b721eb30aa4e2c89507b53933069f9f6e ] kunit_init_device() should unregister the device on bus register error, but mistakenly it tries to unregister the bus. Unregister the device instead of the bus. Signed-off-by: Wander Lairson Costa Fixes: d03c720e03bd ("kunit: Add APIs for managing devices") Reviewed-by: Greg Kroah-Hartman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b0b755cb5a5e0d7168c3ab1b3814b0d3cad9f017 Author: Mickaël Salaün Date: Mon Apr 8 09:46:20 2024 +0200 kunit: Fix kthread reference [ Upstream commit f8aa1b98ce40184521ed95ec26cc115a255183b2 ] There is a race condition when a kthread finishes after the deadline and before the call to kthread_stop(), which may lead to use after free. Cc: Brendan Higgins Cc: Shuah Khan Reviewed-by: Kees Cook Fixes: adf505457032 ("kunit: fix UAF when run kfence test case test_gfpzero") Reviewed-by: David Gow Reviewed-by: Rae Moar Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20240408074625.65017-3-mic@digikod.net Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit a9b783a886c71db86aa051e2ee164340db026355 Author: Valentin Obst Date: Fri Mar 29 11:49:43 2024 +0100 selftests: default to host arch for LLVM builds [ Upstream commit d4e6fbd245c48b272cc591d1c5e7c07aedd7f071 ] Align the behavior for gcc and clang builds by interpreting unset `ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the user wants to build for the host architecture. This patch preserves the properties that setting the `ARCH` variable to an unknown value will trigger an error that complains about insufficient information, and that a set `CROSS_COMPILE` variable will override the target triple that is determined based on presence/absence of `ARCH`. When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable in combination with an unset `CROSS_COMPILE` variable, i.e., compiling for the host architecture, leads to compilation failures since `lib.mk` can not determine the clang target triple. In this case, the following error message is displayed for each subsystem that does not set `ARCH` in its own Makefile before including `lib.mk` (lines wrapped at 75 chrs): make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/ sysctl' ../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=' option to lib.mk. Stop. make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/ sysctl' In the same scenario a gcc build would default to the host architecture, i.e., it would use plain `gcc`. Fixes: 795285ef2425 ("selftests: Fix clang cross compilation") Reviewed-by: Mark Brown Signed-off-by: Valentin Obst Reviewed-by: John Hubbard Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 28ec68cb4392b581291194424d9eb49f8b2dbeb9 Author: John Hubbard Date: Thu May 2 19:17:12 2024 -0700 selftests/resctrl: fix clang build failure: use LOCAL_HDRS [ Upstream commit d8171aa4ca72f1a67bf3c14c59441d63c1d2585f ] First of all, in order to build with clang at all, one must first apply Valentin Obst's build fix for LLVM [1]. Once that is done, then when building with clang, via: make LLVM=1 -C tools/testing/selftests ...the following error occurs: clang: error: cannot specify -o when generating multiple output files This is because clang, unlike gcc, won't accept invocations of this form: clang file1.c header2.h Fix this by using selftests/lib.mk facilities for tracking local header file dependencies: add them to LOCAL_HDRS, leaving only the .c files to be passed to the compiler. [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/ Fixes: 8e289f454289 ("selftests/resctrl: Add resctrl.h into build deps") Cc: Ilpo Järvinen Signed-off-by: John Hubbard Acked-by: Reinette Chatre Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit de5f9bab9f2b45922577041b4ed9fd1c40c0b522 Author: John Hubbard Date: Thu May 2 18:58:20 2024 -0700 selftests/binderfs: use the Makefile's rules, not Make's implicit rules [ Upstream commit 019baf635eb6ffe8d6c1343f81788f02a7e0ed98 ] First of all, in order to build with clang at all, one must first apply Valentin Obst's build fix for LLVM [1]. Once that is done, then when building with clang, via: make LLVM=1 -C tools/testing/selftests ...the following error occurs: clang: error: cannot specify -o when generating multiple output files This is because clang, unlike gcc, won't accept invocations of this form: clang file1.c header2.h While trying to fix this, I noticed that: a) selftests/lib.mk already avoids the problem, and b) The binderfs Makefile indavertently bypasses the selftests/lib.mk build system, and quitely uses Make's implicit build rules for .c files instead. The Makefile attempts to set up both a dependency and a source file, neither of which was needed, because lib.mk is able to automatically handle both. This line: binderfs_test: binderfs_test.c ...causes Make's implicit rules to run, which builds binderfs_test without ever looking at lib.mk. Fix this by simply deleting the "binderfs_test:" Makefile target and letting lib.mk handle it instead. [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/ Fixes: 6e29225af902 ("binderfs: port tests to test harness infrastructure") Cc: Christian Brauner Signed-off-by: John Hubbard Reviewed-by: Christian Brauner Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 21ed1bbfa7db314e24926f88ffb55bbd59d24be7 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 11:32:16 2024 -0400 selftests: power_supply: Make it POSIX-compliant [ Upstream commit 5b1c8b1e56ff8b5e9c1a09606af3627bb55933cf ] There is one use of bash specific syntax in the script. Change it to the equivalent POSIX syntax. This doesn't change functionality and allows the test to be run on shells other than bash. Reported-by: Mike Looijmans Closes: https://lore.kernel.org/all/efae4037-c22a-40be-8ba9-7c1c12ece042@topic.nl/ Fixes: 4a679c5afca0 ("selftests: Add test to verify power supply properties") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Muhammad Usama Anjum Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit f0e783064f91694f88ee8b06d46f3321cce42ec1 Author: Nícolas F. R. A. Prado Date: Mon Apr 15 11:32:15 2024 -0400 selftests: ktap_helpers: Make it POSIX-compliant [ Upstream commit 45d5a2b1886a3ff0fe5627ebee84c089db7ff5f2 ] There are a couple uses of bash specific syntax in the script. Change them to the equivalent POSIX syntax. This doesn't change functionality and allows non-bash test scripts to make use of these helpers. Reported-by: Mike Looijmans Closes: https://lore.kernel.org/all/efae4037-c22a-40be-8ba9-7c1c12ece042@topic.nl/ Fixes: 2dd0b5a8fcc4 ("selftests: ktap_helpers: Add a helper to finish the test") Fixes: 14571ab1ad21 ("kselftest: Add new test for detecting unprobed Devicetree devices") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: Muhammad Usama Anjum Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit ee9afd6046f90e222dbe67af7ae8eea15f6dd36f Author: Chih-Kang Chang Date: Thu May 2 10:24:55 2024 +0800 wifi: rtw89: wow: refine WoWLAN flows of HCI interrupts and low power mode [ Upstream commit baaf806e4632a259cc959fd1c516c2d9ed48df6d ] After enabling packet offload, the TX will be stuck after resume from WoWLAN mode. And the 8852c gets error messages like rtw89_8852ce 0000:04:00.0: No busy txwd pages available rtw89_8852ce 0000:04:00.0: queue 0 txwd 100 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 101 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 102 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 103 is not idle If suspend/resume many times that firmware will download failed and disconnection. To fix these issues, We removed the rtw89_hci_disable_intr() and rtw89_hci_enable_intr() during rtw89_wow_swap_fw() to prevent add packet offload can't receive c2h back due to interrupt disable. Only 8852C and 8922A needs to disable interrupt before downloading fw. Furthermore, we avoid using low power HCI mode on WoWLAN mode, to prevent interrupt enabled, then get interrupt and calculate RXBD mismatched due to software RXBD index already reset but hardware RXBD index not yet. Fixes: 5c12bb66b79d ("wifi: rtw89: refine packet offload flow") Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Link: https://msgid.link/20240502022505.28966-3-pkshih@realtek.com Signed-off-by: Sasha Levin commit 8fa4d56564ee7cc2ee348258d88efe191d70dd7f Author: Kees Cook Date: Wed Apr 24 15:01:01 2024 -0700 wifi: nl80211: Avoid address calculations via out of bounds array indexing [ Upstream commit 838c7b8f1f278404d9d684c34a8cb26dc41aaaa1 ] Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning. Reported-by: Nathan Chancellor Fixes: e3eac9f32ec0 ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Kees Cook Tested-by: Nathan Chancellor Link: https://msgid.link/20240424220057.work.819-kees@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e1a825cafedeb69f7340c3ca09a17f30263b013c Author: Jiri Olsa Date: Thu May 2 09:55:41 2024 +0200 libbpf: Fix error message in attach_kprobe_multi [ Upstream commit 7c13ef16e87ac2e44d16c0468b1191bceb06f95c ] We just failed to retrieve pattern, so we need to print spec instead. Fixes: ddc6b04989eb ("libbpf: Add bpf_program__attach_kprobe_multi_opts function") Reported-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240502075541.1425761-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit 11b5c4d590b998cabbb5a7b22ee962544b671101 Author: Felix Fietkau Date: Wed Apr 3 13:01:01 2024 +0200 wifi: mt76: connac: use muar idx 0xe for non-mt799x as well [ Upstream commit 64bfcdbe025699d3d81ec11af24bd4895c0f6ddd ] This is expected by the firmware of older chipsets as well, though it may not have been as strongly required as on mt799x Fixes: 098428c400ff ("wifi: mt76: connac: set correct muar_idx for mt799x chipsets") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ef46dbb93fc9279fb7de883aac22abffe214e6b5 Author: Howard Hsu Date: Wed Mar 20 19:09:14 2024 +0800 wifi: mt76: mt7996: fix potential memory leakage when reading chip temperature [ Upstream commit 474b9412f33be87076b40a49756662594598a85e ] Without this commit, reading chip temperature will cause memory leakage. Fixes: 6879b2e94172 ("wifi: mt76: mt7996: add thermal sensor device support") Reported-by: Ryder Lee Signed-off-by: Howard Hsu Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 4bbb2040194413ea73c289e8d25862807651e6ac Author: Lorenzo Bianconi Date: Tue Mar 19 13:05:36 2024 +0100 wifi: mt76: mt7996: fix uninitialized variable in mt7996_irq_tasklet() [ Upstream commit 1ac710a6e8545c6df7a292f167dd088880a74c05 ] Set intr1 to 0 in mt7996_irq_tasklet() in order to avoid possible uninitialized variable usage if wed is not active for hif2. Fixes: 83eafc9251d6 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 99e504272523ca29e2b23e8d214bc4f00cf6fc75 Author: Ming Yen Hsieh Date: Thu Mar 7 19:08:15 2024 +0800 wifi: mt76: mt7925: ensure 4-byte alignment for suspend & wow command [ Upstream commit fa46bd62c9a8ab195d9c5108a91abf0680fec10e ] Before sending suspend & wow command to FW, its length should be 4-bytes alignd. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e55e743830cf9a62d1b99f9ba3c1a99285865229 Author: Chad Monroe Date: Tue Mar 5 17:55:35 2024 +0000 wifi: mt76: mt7996: fix size of txpower MCU command [ Upstream commit 66ffcb9abae68625c704b247c7d15cbbc7837391 ] Fixes issues with scanning and low power output at some rates. Fixes: f75e4779d215 ("wifi: mt76: mt7996: add txpower setting support") Signed-off-by: Chad Monroe Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e469218765b2781fb968778bd13595acec181a0e Author: Muhammad Usama Anjum Date: Fri Mar 1 19:44:06 2024 +0500 wifi: mt76: connac: check for null before dereferencing [ Upstream commit cb47c7be0e93dd5acda078163799401ac3a78e10 ] The wcid can be NULL. It should be checked for validity before dereferencing it to avoid crash. Fixes: 098428c400ff ("wifi: mt76: connac: set correct muar_idx for mt799x chipsets") Signed-off-by: Muhammad Usama Anjum Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ef22ea3405527ab167fe1ca0bd4dd62e9926c393 Author: Felix Fietkau Date: Wed Apr 3 11:11:54 2024 +0200 wifi: mt76: mt7603: add wpdma tx eof flag for PSE client reset [ Upstream commit 21de5f72260b4246e2415bc900c18139bc52ea80 ] This flag is needed for the PSE client reset. Fixes watchdog reset issues. Fixes: c677dda16523 ("wifi: mt76: mt7603: improve watchdog reset reliablity") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit be7f3a092cecba8166fa34d17ca066feda3da81f Author: Felix Fietkau Date: Tue Apr 2 20:14:34 2024 +0200 wifi: mt76: mt7603: fix tx queue of loopback packets [ Upstream commit b473c0e47f04d3b4ee9d05d2e79234134aad14d5 ] Use the correct WMM AC queue instead of the MGMT one to fix potential issues with aggregation sequence number tracking. Drop non-bufferable packets. Fixes: fca9615f1a43 ("mt76: mt7603: fix up hardware queue index for PS filtered packets") Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 360a2b969b3175270ed41e86dd1951cfec28a588 Author: Guenter Roeck Date: Sun Mar 24 16:18:04 2024 -0700 Revert "sh: Handle calling csum_partial with misaligned data" [ Upstream commit b5319c96292ff877f6b58d349acf0a9dc8d3b454 ] This reverts commit cadc4e1a2b4d20d0cc0e81f2c6ba0588775e54e5. Commit cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned data") causes bad checksum calculations on unaligned data. Reverting it fixes the problem. # Subtest: checksum # module: checksum_kunit 1..5 # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500 Expected ( u64)result == ( u64)expec, but ( u64)result == 53378 (0xd082) ( u64)expec == 33488 (0x82d0) # test_csum_fixed_random_inputs: pass:0 fail:1 skip:0 total:1 not ok 1 test_csum_fixed_random_inputs # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525 Expected ( u64)result == ( u64)expec, but ( u64)result == 65281 (0xff01) ( u64)expec == 65280 (0xff00) # test_csum_all_carry_inputs: pass:0 fail:1 skip:0 total:1 not ok 2 test_csum_all_carry_inputs # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573 Expected ( u64)result == ( u64)expec, but ( u64)result == 65535 (0xffff) ( u64)expec == 65534 (0xfffe) # test_csum_no_carry_inputs: pass:0 fail:1 skip:0 total:1 not ok 3 test_csum_no_carry_inputs # test_ip_fast_csum: pass:1 fail:0 skip:0 total:1 ok 4 test_ip_fast_csum # test_csum_ipv6_magic: pass:1 fail:0 skip:0 total:1 ok 5 test_csum_ipv6_magic # checksum: pass:2 fail:3 skip:0 total:5 # Totals: pass:2 fail:3 skip:0 total:5 not ok 22 checksum Fixes: cadc4e1a2b4d ("sh: Handle calling csum_partial with misaligned data") Signed-off-by: Guenter Roeck Tested-by: Geert Uytterhoeven Reviewed-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/20240324231804.841099-1-linux@roeck-us.net Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit 5d39204c7262266a99038ae23526db24ed8b6254 Author: Geert Uytterhoeven Date: Fri Mar 1 22:02:30 2024 +0100 sh: kprobes: Merge arch_copy_kprobe() into arch_prepare_kprobe() [ Upstream commit 1422ae080b66134fe192082d9b721ab7bd93fcc5 ] arch/sh/kernel/kprobes.c:52:16: warning: no previous prototype for 'arch_copy_kprobe' [-Wmissing-prototypes] Although SH kprobes support was only merged in v2.6.28, it missed the earlier removal of the arch_copy_kprobe() callback in v2.6.15. Based on the powerpc part of commit 49a2a1b83ba6fa40 ("[PATCH] kprobes: changed from using spinlock to mutex"). Fixes: d39f5450146ff39f ("sh: Add kprobes support.") Signed-off-by: Geert Uytterhoeven Reviewed-by: John Paul Adrian Glaubitz Link: https://lore.kernel.org/r/717d47a19689cc944fae6e981a1ad7cae1642c89.1709326528.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit b34bbc76651065a5eafad8ddff1eb8d1f8473172 Author: Stanislav Fomichev Date: Fri Apr 26 16:16:18 2024 -0700 bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE [ Upstream commit 543576ec15b17c0c93301ac8297333c7b6e84ac7 ] bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Link: https://lore.kernel.org/bpf/0000000000004792a90615a1dde0@google.com/ Reported-by: syzbot+838346b979830606c854@syzkaller.appspotmail.com Signed-off-by: Stanislav Fomichev Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240426231621.2716876-2-sdf@google.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 132fe6c1ee248cbc0e03197d417f7d40bcf07c49 Author: George Stark Date: Thu Apr 25 20:12:53 2024 +0300 pwm: meson: Use mul_u64_u64_div_u64() for frequency calculating [ Upstream commit 32c44e1fa921aebf8a5ef9f778534a30aab39313 ] While calculating frequency for the given period u64 numbers are multiplied before division what can lead to overflow in theory so use secure mul_u64_u64_div_u64() which handles overflow correctly. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Suggested-by: Uwe Kleine-König Signed-off-by: George Stark Link: https://lore.kernel.org/r/20240425171253.2752877-4-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 513202bfe4dafa086e94d80b8a68e6ab7041a35b Author: George Stark Date: Thu Apr 25 20:12:52 2024 +0300 pwm: meson: Add check for error from clk_round_rate() [ Upstream commit 3e551115aee079931b82e1ec78c05f3d5033473f ] clk_round_rate() can return not only zero if requested frequency can not be provided but also negative error code so add check for it too. Also change type of variable holding clk_round_rate() result from unsigned long to long. It's safe due to clk_round_rate() returns long. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Signed-off-by: Dmitry Rokosov Signed-off-by: George Stark Link: https://lore.kernel.org/r/20240425171253.2752877-3-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 7bbf76c9bb2c58375e183074e44f9712483f0603 Author: Nikita Zhandarovich Date: Mon Apr 8 05:14:25 2024 -0700 wifi: ar5523: enable proper endpoint verification [ Upstream commit e120b6388d7d88635d67dcae6483f39c37111850 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 Reported-and-tested-by: syzbot+1bc2c2afd44f820a669f@syzkaller.appspotmail.com Fixes: b7d572e1871d ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich Signed-off-by: Kalle Valo Link: https://msgid.link/20240408121425.29392-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin commit 2ee884b84ccd5489983725b3eebf81f63f6d3062 Author: Viktor Malik Date: Mon Apr 29 13:23:11 2024 +0200 selftests/bpf: Run cgroup1_hierarchy test in own mount namespace [ Upstream commit 19468ed51488dae19254e8a67c75d583b05fa5e3 ] The cgroup1_hierarchy test uses setup_classid_environment to setup cgroupv1 environment. The problem is that the environment is set in /sys/fs/cgroup and therefore, if not run under an own mount namespace, effectively deletes all system cgroups: $ ls /sys/fs/cgroup | wc -l 27 $ sudo ./test_progs -t cgroup1_hierarchy #41/1 cgroup1_hierarchy/test_cgroup1_hierarchy:OK #41/2 cgroup1_hierarchy/test_root_cgid:OK #41/3 cgroup1_hierarchy/test_invalid_level:OK #41/4 cgroup1_hierarchy/test_invalid_cgid:OK #41/5 cgroup1_hierarchy/test_invalid_hid:OK #41/6 cgroup1_hierarchy/test_invalid_cgrp_name:OK #41/7 cgroup1_hierarchy/test_invalid_cgrp_name2:OK #41/8 cgroup1_hierarchy/test_sleepable_prog:OK #41 cgroup1_hierarchy:OK Summary: 1/8 PASSED, 0 SKIPPED, 0 FAILED $ ls /sys/fs/cgroup | wc -l 1 To avoid this, run setup_cgroup_environment first which will create an own mount namespace. This only affects the cgroupv1_hierarchy test as all other cgroup1 test progs already run setup_cgroup_environment prior to running setup_classid_environment. Also add a comment to the header of setup_classid_environment to warn against this invalid usage in future. Fixes: 360769233cc9 ("selftests/bpf: Add selftests for cgroup1 hierarchy") Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240429112311.402497-1-vmalik@redhat.com Signed-off-by: Sasha Levin commit c58ccdd2483a1d990748cdaf94206b5d5986a001 Author: Alexei Starovoitov Date: Fri Apr 26 17:25:44 2024 -0700 bpf: Fix verifier assumptions about socket->sk [ Upstream commit 0db63c0b86e981a1e97d2596d64ceceba1a5470e ] The verifier assumes that 'sk' field in 'struct socket' is valid and non-NULL when 'socket' pointer itself is trusted and non-NULL. That may not be the case when socket was just created and passed to LSM socket_accept hook. Fix this verifier assumption and adjust tests. Reported-by: Liam Wisehart Acked-by: Kumar Kartikeya Dwivedi Fixes: 6fcd486b3a0a ("bpf: Refactor RCU enforcement in the verifier.") Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20240427002544.68803-1-alexei.starovoitov@gmail.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 0fa08a55201ab9be72bacb8ea93cf752d338184f Author: Nikita Zhandarovich Date: Mon Apr 22 11:33:55 2024 -0700 wifi: carl9170: add a proper sanity check for endpoints [ Upstream commit b6dd09b3dac89b45d1ea3e3bd035a3859c0369a0 ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: syzbot+0ae4804973be759fa420@syzkaller.appspotmail.com Fixes: a84fab3cbfdc ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich Acked-By: Christian Lamparter Signed-off-by: Kalle Valo Link: https://msgid.link/20240422183355.3785-1-n.zhandarovich@fintech.ru Signed-off-by: Sasha Levin commit 2907d409ce5946390f513976f0454888d37d1058 Author: Finn Thain Date: Wed Mar 13 13:53:41 2024 +1100 macintosh/via-macii: Fix "BUG: sleeping function called from invalid context" [ Upstream commit d301a71c76ee4c384b4e03cdc320a55f5cf1df05 ] The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.1710298421.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit e06cc14cff5df23b665220c6c41b2cf8c1a53209 Author: Eric Dumazet Date: Fri Apr 26 06:42:22 2024 +0000 net: give more chances to rcu in netdev_wait_allrefs_any() [ Upstream commit cd42ba1c8ac9deb9032add6adf491110e7442040 ] This came while reviewing commit c4e86b4363ac ("net: add two more call_rcu_hurry()"). Paolo asked if adding one synchronize_rcu() would help. While synchronize_rcu() does not help, making sure to call rcu_barrier() before msleep(wait) is definitely helping to make sure lazy call_rcu() are completed. Instead of waiting ~100 seconds in my tests, the ref_tracker splats occurs one time only, and netdev_wait_allrefs_any() latency is reduced to the strict minimum. Ideally we should audit our call_rcu() users to make sure no refcount (or cascading call_rcu()) is held too long, because rcu_barrier() is quite expensive. Fixes: 0e4be9e57e8c ("net: use exponential backoff in netdev_wait_allrefs") Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/all/28bbf698-befb-42f6-b561-851c67f464aa@kernel.org/T/#m76d73ed6b03cd930778ac4d20a777f22a08d6824 Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b1e86f1ef8fa796f8935be392457639f3a907d91 Author: Hao Chen Date: Thu Apr 25 20:46:27 2024 +0800 drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset() [ Upstream commit 582c1aeee0a9e73010cf1c4cef338709860deeb0 ] pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Hao Chen Signed-off-by: Junhao He Reviewed-by: Jijie Shao Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240425124627.13764-4-hejunhao3@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit aa2d3d678895c8eedd003f1473f87d3f06fe6ec7 Author: Junhao He Date: Thu Apr 25 20:46:26 2024 +0800 drivers/perf: hisi: hns3: Fix out-of-bound access when valid event group [ Upstream commit 81bdd60a3d1d3b05e6cc6674845afb1694dd3a0e ] The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/} Fixes: 66637ab137b4 ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Junhao He Signed-off-by: Hao Chen Acked-by: Jonathan Cameron Reviewed-by: Jijie Shao Link: https://lore.kernel.org/r/20240425124627.13764-3-hejunhao3@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ff48247144d13a3a0817127703724256008efa78 Author: Junhao He Date: Thu Apr 25 20:46:25 2024 +0800 drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group [ Upstream commit 77fce82678ea5fd51442e62febec2004f79e041b ] The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs. Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds. There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}' Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU") Signed-off-by: Junhao He Reviewed-by: Jijie Shao Acked-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240425124627.13764-2-hejunhao3@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f38d98652a2d1ef09f1e6205383535a04c0f16b9 Author: Uwe Kleine-König Date: Sun Mar 10 12:00:54 2024 +0100 pwm: sti: Simplify probe function using devm functions [ Upstream commit 5bb0b194aeee5d5da6881232f4e9989b35957c25 ] Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has several advantages: - Combines getting the clock and a call to clk_prepare(). The latter can be dropped from sti_pwm_probe() accordingly. - Cares for calling clk_put() which is missing in both probe's error path and the remove function. - Cares for calling clk_unprepare() which can be dropped from the error paths and the remove function. (Note that not all error path got this right.) With additionally using devm_pwmchip_add() instead of pwmchip_add() the remove callback can be dropped completely. With it the last user of platform_get_drvdata() goes away and so platform_set_drvdata() can be dropped from the probe function, too. Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP") Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin commit 91ae48dee39f0b3ee9f9775f115eeab40d3ccbdf Author: Rafael J. Wysocki Date: Thu Apr 25 14:24:20 2024 +0200 thermal/debugfs: Pass cooling device state to thermal_debug_cdev_add() [ Upstream commit 31a0fa0019b022024cc082ae292951a596b06f8c ] If cdev_dt_seq_show() runs before the first state transition of a cooling device, it will not print any state residency information for it, even though it might be reasonably expected to print residency information for the initial state of the cooling device. For this reason, rearrange the code to get the initial state of a cooling device at the registration time and pass it to thermal_debug_cdev_add(), so that the latter can create a duration record for that state which will allow cdev_dt_seq_show() to print its residency information. Fixes: 755113d76786 ("thermal/debugfs: Add thermal cooling device debugfs information") Reported-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Signed-off-by: Sasha Levin commit aeb1c06b6f7c1dc07dd63661e524790efed50fa1 Author: Rafael J. Wysocki Date: Thu Apr 25 14:24:10 2024 +0200 thermal/debugfs: Create records for cdev states as they get used [ Upstream commit f4ae18fcb652c6cccc834ded525ac37f91d5cdb1 ] Because thermal_debug_cdev_state_update() only creates a duration record for the old state of a cooling device, if its new state is used for the first time, there will be no record for it and cdev_dt_seq_show() will not print the duration information for it even though it contains code to compute the duration value in that case. Address this by making thermal_debug_cdev_state_update() create a duration record for the new state if there is none. Fixes: 755113d76786 ("thermal/debugfs: Add thermal cooling device debugfs information") Reported-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Signed-off-by: Sasha Levin commit 0cf2192060b067875c8b640f0827aaebf4539601 Author: Eric Dumazet Date: Tue Apr 23 12:56:20 2024 +0000 tcp: avoid premature drops in tcp_add_backlog() [ Upstream commit ec00ed472bdb7d0af840da68c8c11bff9f4d9caa ] While testing TCP performance with latest trees, I saw suspect SOCKET_BACKLOG drops. tcp_add_backlog() computes its limit with : limit = (u32)READ_ONCE(sk->sk_rcvbuf) + (u32)(READ_ONCE(sk->sk_sndbuf) >> 1); limit += 64 * 1024; This does not take into account that sk->sk_backlog.len is reset only at the very end of __release_sock(). Both sk->sk_backlog.len and sk->sk_rmem_alloc could reach sk_rcvbuf in normal conditions. We should double sk->sk_rcvbuf contribution in the formula to absorb bubbles in the backlog, which happen more often for very fast flows. This change maintains decent protection against abuses. Fixes: c377411f2494 ("net: sk_add_backlog() take rmem_alloc into account") Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20240423125620.3309458-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f0ff34c5110b69bd5595740f5ff3fe60c51b7bce Author: Matthias Schiffer Date: Tue Apr 23 09:47:49 2024 +0200 net: dsa: mv88e6xxx: Avoid EEPROM timeout without EEPROM on 88E6250-family switches [ Upstream commit e44894e2aa4eb311ceda134de8b6f51ff979211b ] 88E6250-family switches have the quirk that the EEPROM Running flag can get stuck at 1 when no EEPROM is connected, causing mv88e6xxx_g2_eeprom_wait() to time out. We still want to wait for the EEPROM however, to avoid interrupting a transfer and leaving the EEPROM in an invalid state. The condition to wait for recommended by the hardware spec is the EEInt flag, however this flag is cleared on read, so before the hardware reset, is may have been cleared already even though the EEPROM has been read successfully. For this reason, we revive the mv88e6xxx_g1_wait_eeprom_done() function that was removed in commit 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") in a slightly refactored form, and introduce a new mv88e6xxx_g1_wait_eeprom_done_prereset() that additionally handles this case by triggering another EEPROM reload that can be waited on. On other switch models without this quirk, mv88e6xxx_g2_eeprom_wait() is kept, as it avoids the additional reload. Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72a9068c570ca74b9d76c9d1868e45742acb6ef0 Author: Matthias Schiffer Date: Tue Apr 23 09:47:48 2024 +0200 net: dsa: mv88e6xxx: Add support for model-specific pre- and post-reset handlers [ Upstream commit 0fdd27b9d6d7c60bd319d3497ad797934bab13cb ] Instead of calling mv88e6xxx_g2_eeprom_wait() directly from mv88e6xxx_hardware_reset(), add configurable pre- and post-reset hard reset handlers. Initially, the handlers are set to mv88e6xxx_g2_eeprom_wait() for all families that have get/set_eeprom() to match the existing behavior. No functional change intended (except for additional error messages on failure). Fixes: 6ccf50d4d474 ("net: dsa: mv88e6xxx: Avoid EEPROM timeout when EEPROM is absent") Signed-off-by: Matthias Schiffer Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e5bf850895844ec89e304be32f43911aa15fc038 Author: Dmitry Baryshkov Date: Tue Jan 30 08:47:06 2024 +0200 wifi: ath10k: populate board data for WCN3990 [ Upstream commit f1f1b5b055c9f27a2f90fd0f0521f5920e9b3c18 ] Specify board data size (and board.bin filename) for the WCN3990 platform. Reported-by: Yongqin Liu Fixes: 03a72288c546 ("ath10k: wmi: add hw params entry for wcn3990") Signed-off-by: Dmitry Baryshkov Signed-off-by: Kalle Valo Link: https://msgid.link/20240130-wcn3990-board-fw-v1-1-738f7c19a8c8@linaro.org Signed-off-by: Sasha Levin commit 5a46a72deed600e462f720a1976d079e91bb8ddb Author: Portia Stephens Date: Wed Apr 24 15:02:20 2024 +1000 cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations [ Upstream commit fa7bd98f3c8b33fb68c6b2bc69cff32b63db69f8 ] There is a compile warning because a NULL pointer check was added before a struct was declared. This moves the NULL pointer check to after the struct is declared and moves the struct assignment to after the NULL pointer check. Fixes: f661017e6d32 ("cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value") Signed-off-by: Portia Stephens Acked-by: Florian Fainelli Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 566738d0b4270a0f4db30ca25f58d29c6e7d5ce9 Author: Bart Van Assche Date: Tue Apr 9 17:07:45 2024 -0700 scsi: ufs: core: mcq: Fix ufshcd_mcq_sqe_search() [ Upstream commit 3c5d0dce8ce0a2781ac306b9ad1492b005ecbab5 ] Fix the calculation of the utrd pointer. This patch addresses the following Coverity complaint: CID 1538170: (#1 of 1): Extra sizeof expression (SIZEOF_MISMATCH) suspicious_pointer_arithmetic: Adding sq_head_slot * 32UL /* sizeof (struct utp_transfer_req_desc) */ to pointer hwq->sqe_base_addr of type struct utp_transfer_req_desc * is suspicious because adding an integral value to this pointer automatically scales that value by the size, 32 bytes, of the pointed-to type, struct utp_transfer_req_desc. Most likely, the multiplication by sizeof (struct utp_transfer_req_desc) in this expression is extraneous and should be eliminated. Cc: Bao D. Nguyen Cc: Stanley Chu Cc: Can Guo Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20240410000751.1047758-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 75ba8031fe04565a40698731261eed92ce3a6e99 Author: Geliang Tang Date: Tue Apr 23 18:35:27 2024 +0800 selftests/bpf: Fix a fd leak in error paths in open_netns [ Upstream commit 151f7442436658ee84076681d8f52e987fe147ea ] As Martin mentioned in review comment, there is an existing bug that orig_netns_fd will be leaked in the later "goto fail;" case after open("/proc/self/ns/net") in open_netns() in network_helpers.c. This patch adds "close(token->orig_netns_fd);" before "free(token);" to fix it. Fixes: a30338840fa5 ("selftests/bpf: Move open_netns() and close_netns() into network_helpers.c") Signed-off-by: Geliang Tang Link: https://lore.kernel.org/r/a104040b47c3c34c67f3f125cdfdde244a870d3c.1713868264.git.tanggeliang@kylinos.cn Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit df4df18bd02a7a7d479567de609bbc37ef7cbe69 Author: Rafael J. Wysocki Date: Wed Apr 17 15:09:46 2024 +0200 thermal/debugfs: Avoid excessive updates of trip point statistics [ Upstream commit 0a293c77580581c4b058eb40287acadac6ffd14a ] Since thermal_debug_update_temp() is called before invoking thermal_debug_tz_trip_down() for the trips that were crossed by the zone temperature on the way up, it updates the statistics for them as though the current zone temperature was above the low temperature of each of them. However, if a given trip has just been crossed on the way down, the zone temperature is in fact below its low temperature, but this is handled by thermal_debug_tz_trip_down() running after the update of the trip statistics. The remedy is to call thermal_debug_update_temp() after thermal_debug_tz_trip_down() has been invoked for all of the trips in question, but then thermal_debug_tz_trip_up() needs to be adjusted, so it does not update the statistics for the trips that has just been crossed on the way up, as that will be taken care of by thermal_debug_update_temp() down the road. Modify the code accordingly. Fixes: 7ef01f228c9f ("thermal/debugfs: Add thermal debugfs information for mitigation episodes") Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Acked-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 7eea020b07b821a156425262d04824457a901ccc Author: Andreas Gruenbacher Date: Mon Apr 15 11:23:04 2024 +0200 gfs2: do_xmote fixes [ Upstream commit 9947a06d29c0a30da88cdc6376ca5fd87083e130 ] Function do_xmote() is called with the glock spinlock held. Commit 86934198eefa added a 'goto skip_inval' statement at the beginning of the function to further below where the glock spinlock is expected not to be held anymore. Then it added code there that requires the glock spinlock to be held. This doesn't make sense; fix this up by dropping and retaking the spinlock where needed. In addition, when ->lm_lock() returned an error, do_xmote() didn't fail the locking operation, and simply left the glock hanging; fix that as well. (This is a much older error.) Fixes: 86934198eefa ("gfs2: Clear flags when withdraw prevents xmote") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 71667e7f8183de19492aaa84e8480c33048c9096 Author: Andreas Gruenbacher Date: Fri Apr 12 19:16:58 2024 +0200 gfs2: finish_xmote cleanup [ Upstream commit 1cd28e15864054f3c48baee9eecda1c0441c48ac ] Currently, function finish_xmote() takes and releases the glock spinlock. However, all of its callers immediately take that spinlock again, so it makes more sense to take the spin lock before calling finish_xmote() already. With that, thaw_glock() is the only place that sets the GLF_HAVE_REPLY flag outside of the glock spinlock, but it also takes that spinlock immediately thereafter. Change that to set the bit when the spinlock is already held. This allows to switch from test_and_clear_bit() to test_bit() and clear_bit() in glock_work_func(). Signed-off-by: Andreas Gruenbacher Stable-dep-of: 9947a06d29c0 ("gfs2: do_xmote fixes") Signed-off-by: Sasha Levin commit 501cd8fabf621d10bd4893e37f6ce6c20523c8ca Author: Andreas Gruenbacher Date: Wed Apr 10 04:50:18 2024 +0200 gfs2: Fix potential glock use-after-free on unmount [ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ] When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead. Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher Cc: David Teigland Signed-off-by: Sasha Levin commit 666a7a9b6ddafe7802ae6a53f513d17e790056a0 Author: Andreas Gruenbacher Date: Wed Apr 10 04:24:56 2024 +0200 gfs2: Remove ill-placed consistency check [ Upstream commit 59f60005797b4018d7b46620037e0c53d690795e ] This consistency check was originally added by commit 9287c6452d2b1 ("gfs2: Fix occasional glock use-after-free"). It is ill-placed in gfs2_glock_free() because if it holds there, it must equally hold in __gfs2_glock_put() already. Either way, the check doesn't seem necessary anymore. Signed-off-by: Andreas Gruenbacher Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin commit 5df1708bd3ca423a19b473e4477a61f493793639 Author: Su Hui Date: Mon Apr 22 11:42:44 2024 +0800 wifi: ath10k: Fix an error code problem in ath10k_dbg_sta_write_peer_debug_trigger() [ Upstream commit c511a9c12674d246916bb16c479d496b76983193 ] Clang Static Checker (scan-build) warns: drivers/net/wireless/ath/ath10k/debugfs_sta.c:line 429, column 3 Value stored to 'ret' is never read. Return 'ret' rather than 'count' when 'ret' stores an error code. Fixes: ee8b08a1be82 ("ath10k: add debugfs support to get per peer tids log via tracing") Signed-off-by: Su Hui Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240422034243.938962-1-suhui@nfschina.com Signed-off-by: Sasha Levin commit d0878ba4de043860bec6605cf3bdec237763ee70 Author: Binbin Zhou Date: Tue Apr 23 09:59:02 2024 +0800 dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition [ Upstream commit c8c4353685778e75e186103411e9d01a4a3f2b90 ] The temperature output register of the Loongson-2K2000 is defined in the chip configuration domain, which is different from the Loongson-2K1000, so it can't be fallbacked. We need to use two groups of registers to describe it: the first group is the high and low temperature threshold setting register; the second group is the temperature output register. It is true that this fix will cause ABI corruption, but it is necessary otherwise the Loongson-2K2000 temperature sensor will not work properly. Fixes: 72684d99a854 ("thermal: dt-bindings: add loongson-2 thermal") Cc: Yinbo Zhu Signed-off-by: Binbin Zhou Reviewed-by: Krzysztof Kozlowski Acked-by: Huacai Chen Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/5198999d679f1a1c3457385acb9fadfc85da1f1e.1713837379.git.zhoubinbin@loongson.cn Signed-off-by: Sasha Levin commit 491ae4b4edfe1217bb2003260ec42d4263206f6b Author: Binbin Zhou Date: Tue Apr 23 09:59:01 2024 +0800 dt-bindings: thermal: loongson,ls2k-thermal: Add Loongson-2K0500 compatible [ Upstream commit 25c7d8472f6e90390931e93f59135478af3e5d86 ] The thermal on the Loongson-2K0500 shares the design with the Loongson-2K1000. Define corresponding compatible string, having the loongson,ls2k1000-thermal as a fallback. Signed-off-by: Binbin Zhou Acked-by: Rob Herring Acked-by: Huacai Chen Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/26524a63abd2d032e4c45efe6ce3fedb46841768.1713837379.git.zhoubinbin@loongson.cn Stable-dep-of: c8c435368577 ("dt-bindings: thermal: loongson,ls2k-thermal: Fix incorrect compatible definition") Signed-off-by: Sasha Levin commit fcf5f1b5f308f2eb422f6aca55d295b25890906b Author: Aleksandr Mishin Date: Thu Apr 11 14:40:21 2024 +0300 thermal/drivers/tsens: Fix null pointer dereference [ Upstream commit d998ddc86a27c92140b9f7984ff41e3d1d07a48f ] compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set). Fix this bug by adding null pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: dfc1193d4dbd ("thermal/drivers/tsens: Replace custom 8960 apis with generic apis") Signed-off-by: Aleksandr Mishin Reviewed-by: Konrad Dybcio Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240411114021.12203-1-amishin@t-argos.ru Signed-off-by: Sasha Levin commit daccb3479f62e56eed048eae0e104a80f0de345f Author: Hsin-Te Yuan Date: Tue Apr 16 07:35:47 2024 +0000 thermal/drivers/mediatek/lvts_thermal: Add coeff for mt8192 [ Upstream commit 7954c92ede882b0dfd52a5db90291a4151b44c1a ] In order for lvts_raw_to_temp to function properly on mt8192, temperature coefficients for mt8192 need to be added. Fixes: 288732242db4 ("thermal/drivers/mediatek/lvts_thermal: Add mt8192 support") Signed-off-by: Hsin-Te Yuan Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240416-lvts_thermal-v2-1-f8a36882cc53@chromium.org Signed-off-by: Sasha Levin commit a1abdb63628b04855a929850772de97435ed1555 Author: Karthikeyan Kathirvel Date: Thu Apr 18 18:30:25 2024 +0300 wifi: ath12k: fix out-of-bound access of qmi_invoke_handler() [ Upstream commit e1bdff48a1bb4a4ac660c19c55a820968c48b3f2 ] Currently, there is no terminator entry for ath12k_qmi_msg_handlers hence facing below KASAN warning, ================================================================== BUG: KASAN: global-out-of-bounds in qmi_invoke_handler+0xa4/0x148 Read of size 8 at addr ffffffd00a6428d8 by task kworker/u8:2/1273 CPU: 0 PID: 1273 Comm: kworker/u8:2 Not tainted 5.4.213 #0 Workqueue: qmi_msg_handler qmi_data_ready_work Call trace: dump_backtrace+0x0/0x20c show_stack+0x14/0x1c dump_stack+0xe0/0x138 print_address_description.isra.5+0x30/0x330 __kasan_report+0x16c/0x1bc kasan_report+0xc/0x14 __asan_load8+0xa8/0xb0 qmi_invoke_handler+0xa4/0x148 qmi_handle_message+0x18c/0x1bc qmi_data_ready_work+0x4ec/0x528 process_one_work+0x2c0/0x440 worker_thread+0x324/0x4b8 kthread+0x210/0x228 ret_from_fork+0x10/0x18 The address belongs to the variable: ath12k_mac_mon_status_filter_default+0x4bd8/0xfffffffffffe2300 [ath12k] [...] ================================================================== Add a dummy terminator entry at the end to assist the qmi_invoke_handler() in traversing up to the terminator entry without accessing an out-of-boundary index. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Reviewed-by: Jeff Johnson Signed-off-by: Karthikeyan Kathirvel Signed-off-by: Kalle Valo Link: https://msgid.link/20240416080234.2882725-1-quic_kathirve@quicinc.com Signed-off-by: Sasha Levin commit 54b68a19c06393b838ab3fd50addb0bd2f84f25b Author: Ard Biesheuvel Date: Thu Apr 18 22:17:06 2024 +0200 x86/purgatory: Switch to the position-independent small code model [ Upstream commit cba786af84a0f9716204e09f518ce3b7ada8555e ] On x86, the ordinary, position dependent small and kernel code models only support placement of the executable in 32-bit addressable memory, due to the use of 32-bit signed immediates to generate references to global variables. For the kernel, this implies that all global variables must reside in the top 2 GiB of the kernel virtual address space, where the implicit address bits 63:32 are equal to sign bit 31. This means the kernel code model is not suitable for other bare metal executables such as the kexec purgatory, which can be placed arbitrarily in the physical address space, where its address may no longer be representable as a sign extended 32-bit quantity. For this reason, commit e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors") switched to the large code model, which uses 64-bit immediates for all symbol references, including function calls, in order to avoid relying on any assumptions regarding proximity of symbols in the final executable. The large code model is rarely used, clunky and the least likely to operate in a similar fashion when comparing GCC and Clang, so it is best avoided. This is especially true now that Clang 18 has started to emit executable code in two separate sections (.text and .ltext), which triggers an issue in the kexec loading code at runtime. The SUSE bugzilla fixes tag points to gcc 13 having issues with the large model too and that perhaps the large model should simply not be used at all. Instead, use the position independent small code model, which makes no assumptions about placement but only about proximity, where all referenced symbols must be within -/+ 2 GiB, i.e., in range for a RIP-relative reference. Use hidden visibility to suppress the use of a GOT, which carries absolute addresses that are not covered by static ELF relocations, and is therefore incompatible with the kexec loader's relocation logic. [ bp: Massage commit message. ] Fixes: e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors") Fixes: https://bugzilla.suse.com/show_bug.cgi?id=1211853 Closes: https://github.com/ClangBuiltLinux/linux/issues/2016 Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nathan Chancellor Reviewed-by: Fangrui Song Acked-by: Nick Desaulniers Tested-by: Nathan Chancellor Link: https://lore.kernel.org/all/20240417-x86-fix-kexec-with-llvm-18-v1-0-5383121e8fb7@kernel.org/ Signed-off-by: Sasha Levin commit 96593b17c598f03ae744a0e972970ba9c0053315 Author: Yuri Karpov Date: Tue Mar 12 20:04:47 2024 +0300 scsi: hpsa: Fix allocation size for Scsi_Host private data [ Upstream commit 504e2bed5d50610c1836046c0c195b0a6dba9c72 ] struct Scsi_Host private data contains pointer to struct ctlr_info. Restore allocation of only 8 bytes to store pointer in struct Scsi_Host private data area. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bbbd25499100 ("scsi: hpsa: Fix allocation size for scsi_host_alloc()") Signed-off-by: Yuri Karpov Link: https://lore.kernel.org/r/20240312170447.743709-1-YKarpov@ispras.ru Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 17e42338cc13fb925c9ce2e5fbff03b3c036317e Author: Xingui Yang Date: Tue Mar 12 14:11:03 2024 +0000 scsi: libsas: Fix the failure of adding phy with zero-address to port [ Upstream commit 06036a0a5db34642c5dbe22021a767141f010b7a ] As of commit 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions"), reset the phy->entacted_sas_addr address to a zero-address when the link rate is less than 1.5G. Currently we find that when a new device is attached, and the link rate is less than 1.5G, but the device type is not NO_DEVICE, for example: the link rate is SAS_PHY_RESET_IN_PROGRESS and the device type is stp. After setting the phy->entacted_sas_addr address to the zero address, the port will continue to be created for the phy with the zero-address, and other phys with the zero-address will be tried to be added to the new port: [562240.051197] sas: ex 500e004aaaaaaa1f phy19:U:0 attached: 0000000000000000 (no device) // phy19 is deleted but still on the parent port's phy_list [562240.062536] sas: ex 500e004aaaaaaa1f phy0 new device attached [562240.062616] sas: ex 500e004aaaaaaa1f phy00:U:5 attached: 0000000000000000 (stp) [562240.062680] port-7:7:0: trying to add phy phy-7:7:19 fails: it's already part of another port Therefore, it should be the same as sas_get_phy_attached_dev(). Only when device_type is SAS_PHY_UNUSED, sas_address is set to the 0 address. Fixes: 7d1d86518118 ("[SCSI] libsas: fix false positive 'device attached' conditions") Signed-off-by: Xingui Yang Link: https://lore.kernel.org/r/20240312141103.31358-5-yangxingui@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 66b4be30c0f678f0db5cb6a035e4c8b663403f14 Author: Johannes Berg Date: Tue Apr 16 13:54:05 2024 +0300 wifi: iwlwifi: mvm: init vif works only once [ Upstream commit 0bcc2155983e03c41b21a356af87ae839a6b3ead ] It's dangerous to re-initialize works repeatedly, especially delayed ones that have an associated timer, and even more so if they're not necessarily canceled inbetween. This can be the case for these workers here during FW restart scenarios, so make sure to initialize it only once. While at it, also ensure it is cancelled correctly. Fixes: f67806140220 ("iwlwifi: mvm: disconnect in case of bad channel switch parameters") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240416134215.ddf8eece5eac.I4164f5c9c444b64a9abbaab14c23858713778e35@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 17b131627d1818f21e6921feeb11d825efa3bb77 Author: Miri Korenblit Date: Tue Apr 16 13:54:00 2024 +0300 wifi: iwlwifi: mvm: don't always disable EMLSR due to BT coex [ Upstream commit 585ba158233f97da05d9bcc59d13ddf45135c8c9 ] 2.4 GHz/LB (low band) link can't be used in an EMLSR links pair when BT is on. But EMLSR is still allowed for a pair of links which none of them operates in LB. In the existing code, EMLSR will always be disabled if one of the usable links is in LB (and BT is on). Move this check to the code that verifies a specific pair of links, and only if one of these links operates on LB - disable EMLSR. Fixes: 10159a45666b ("wifi: iwlwifi: disable eSR when BT is active") Signed-off-by: Miri Korenblit Link: https://msgid.link/20240416134215.2841006b5cc4.I45ffd583f593daa950322852ceb9454cbf497e24@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 54114e42d9cb095e62d39d99d9c2cb01732bad4c Author: Miri Korenblit Date: Tue Apr 16 13:53:59 2024 +0300 wifi: iwlwifi: mvm: calculate EMLSR mode after connection [ Upstream commit 9c6921121961cc0cecccb95652be6d98116f854b ] The function iwl_mvm_can_enter_esr() is (among others) calculating if EMLSR mode is disabled due to BT coex by calling iwl_mvm_bt_coex_calculate_esr_mode(), then stores the decision in mvmvif::esr_disable_reason. But there is no need to calculate this every time iwl_mvm_can_enter_esr is called. Fix this by calculating it once after authorization, and in iwl_mvm_can_enter_esr only check mvmvif::esr_disable_reason. Signed-off-by: Miri Korenblit Link: https://msgid.link/20240416134215.a767e243366e.I3b32d36cda23f67dc103a28a9bdccb0039d22574@changeid Signed-off-by: Johannes Berg Stable-dep-of: 585ba158233f ("wifi: iwlwifi: mvm: don't always disable EMLSR due to BT coex") Signed-off-by: Sasha Levin commit e63e1096f5c950f44896822014da148ccff98974 Author: Emmanuel Grumbach Date: Tue Apr 16 13:53:56 2024 +0300 wifi: iwlwifi: mvm: introduce esr_disable_reason [ Upstream commit 76f9864d7ac6d04036ba85a8616e2361f2d2d06c ] This will maintain a bitmap of reasons for which we want to avoid enabling EMLSR. For now, we have a single reason: BT coexistence, but we will add soon more reasons. Make it a bitmap to make it easier to manage. Since we'll impact the parameters that impact the enablement / disablement of EMLSR from several places, introduce a generic function that takes into account the current state and execute the decision that must be taken. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://msgid.link/20240416134215.94c3590c6f27.I6a190da5025d0523ef483ffac0c64e26675041e6@changeid Signed-off-by: Johannes Berg Stable-dep-of: 585ba158233f ("wifi: iwlwifi: mvm: don't always disable EMLSR due to BT coex") Signed-off-by: Sasha Levin commit d835d51f432b3c7dd991ae2dfbff57e232f296b6 Author: Johannes Berg Date: Mon Apr 15 11:27:12 2024 +0300 wifi: mac80211: transmit deauth only if link is available [ Upstream commit 570944a094c24ee3a09b2cb5e580063cfde64d7a ] There's an issue in that when we disconnect from an AP due to the AP switching to an unsupported channel, we might not tell the driver about this before we try to send the deauth. If the underlying implementation has detected the quiet CSA, this may cause issues if this is the only active link. Avoid this by transmitting (and flushing) the deauth only when there's an active link available that's not affected by quiet CSA. Since this introduces link->u.mgd.csa_blocked_tx and we no longer check sdata->csa_blocked_tx for the TX itself also rename the latter to csa_blocked_queues. Fixes: 6f0107d195a8 ("wifi: mac80211: introduce a feature flag for quiet in CSA") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240415112355.1d91db5e95aa.Iad3a5df3367f305dff48cd61776abfd6cf0fd4ab@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit dfec15222529d22b15e5b0d63572a9e39570cab4 Author: Aleksandr Mishin Date: Mon Apr 8 12:35:36 2024 +0300 cppc_cpufreq: Fix possible null pointer dereference [ Upstream commit cf7de25878a1f4508c69dc9f6819c21ba177dbfe ] cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Signed-off-by: Aleksandr Mishin Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit cea9d0015c140af39477dd5eeb9b20233a45daa9 Author: Stafford Horne Date: Sat Mar 30 14:42:49 2024 +0000 openrisc: traps: Don't send signals to kernel mode threads [ Upstream commit c88cfb5cea5f8f9868ef02cc9ce9183a26dcf20f ] OpenRISC exception handling sends signals to user processes on floating point exceptions and trap instructions (for debugging) among others. There is a bug where the trap handling logic may send signals to kernel threads, we should not send these signals to kernel threads, if that happens we treat it as an error. This patch adds conditions to die if the kernel receives these exceptions in kernel mode code. Fixes: 27267655c531 ("openrisc: Support floating point user api") Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 92a2343b25c27be34597e6432fb0be09402eba41 Author: Stafford Horne Date: Sat Mar 30 16:29:08 2024 +0000 openrisc: Use do_kernel_power_off() [ Upstream commit c94195a34e09dacfe2feef03602c911e82f49994 ] After commit 14c5678720bd ("power: reset: syscon-poweroff: Use devm_register_sys_off_handler(POWER_OFF)") setting up of pm_power_off was removed from the driver, this causes OpenRISC platforms using syscon-poweroff to no longer shutdown. The kernel now supports chained power-off handlers. Use do_kernel_power_off() that invokes chained power-off handlers. All architectures have moved away from using pm_power_off except OpenRISC. This patch migrates openrisc to use do_kernel_power_off() instead of the legacy pm_power_off(). Fixes: 14c5678720bd ("power: reset: syscon-poweroff: Use devm_register_sys_off_handler(POWER_OFF)") Signed-off-by: Stafford Horne Reviewed-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 5cec72c3c59c6e0b0a40b7ae029a6b1a4c7f10f4 Author: Gabriel Krisman Bertazi Date: Fri Apr 12 17:20:04 2024 -0400 udp: Avoid call to compute_score on multiple sites [ Upstream commit 50aee97d15113b95a68848db1f0cb2a6c09f753a ] We've observed a 7-12% performance regression in iperf3 UDP ipv4 and ipv6 tests with multiple sockets on Zen3 cpus, which we traced back to commit f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present"). The failing tests were those that would spawn UDP sockets per-cpu on systems that have a high number of cpus. Unsurprisingly, it is not caused by the extra re-scoring of the reused socket, but due to the compiler no longer inlining compute_score, once it has the extra call site in udp4_lib_lookup2. This is augmented by the "Safe RET" mitigation for SRSO, needed in our Zen3 cpus. We could just explicitly inline it, but compute_score() is quite a large function, around 300b. Inlining in two sites would almost double udp4_lib_lookup2, which is a silly thing to do just to workaround a mitigation. Instead, this patch shuffles the code a bit to avoid the multiple calls to compute_score. Since it is a static function used in one spot, the compiler can safely fold it in, as it did before, without increasing the text size. With this patch applied I ran my original iperf3 testcases. The failing cases all looked like this (ipv4): iperf3 -c 127.0.0.1 --udp -4 -f K -b $R -l 8920 -t 30 -i 5 -P 64 -O 2 where $R is either 1G/10G/0 (max, unlimited). I ran 3 times each. baseline is v6.9-rc3. harmean == harmonic mean; CV == coefficient of variation. ipv4: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 1743852.66(0.0208) 1725933.02(0.0167) 1705203.78(0.0386) patched 1968727.61(0.0035) 1962283.22(0.0195) 1923853.50(0.0256) ipv6: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 1729020.03(0.0028) 1691704.49(0.0243) 1692251.34(0.0083) patched 1900422.19(0.0067) 1900968.01(0.0067) 1568532.72(0.1519) This restores the performance we had before the change above with this benchmark. We obviously don't expect any real impact when mitigations are disabled, but just to be sure it also doesn't regresses: mitigations=off ipv4: 1G 10G MAX HARMEAN (CV) HARMEAN (CV) HARMEAN (CV) baseline 3230279.97(0.0066) 3229320.91(0.0060) 2605693.19(0.0697) patched 3242802.36(0.0073) 3239310.71(0.0035) 2502427.19(0.0882) Cc: Lorenz Bauer Fixes: f0ea27e7bfe1 ("udp: re-score reuseport groups when connected sockets are present") Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 049ae0459a67d7afae68237f0e2ce8517d1b188c Author: Juergen Gross Date: Fri Apr 12 17:12:58 2024 +0200 x86/pat: Fix W^X violation false-positives when running as Xen PV guest [ Upstream commit 5bc8b0f5dac04cd4ebe47f8090a5942f2f2647ef ] When running as Xen PV guest in some cases W^X violation WARN()s have been observed. Those WARN()s are produced by verify_rwx(), which looks into the PTE to verify that writable kernel pages have the NX bit set in order to avoid code modifications of the kernel by rogue code. As the NX bits of all levels of translation entries are or-ed and the RW bits of all levels are and-ed, looking just into the PTE isn't enough for the decision that a writable page is executable, too. When running as a Xen PV guest, the direct map PMDs and kernel high map PMDs share the same set of PTEs. Xen kernel initialization will set the NX bit in the direct map PMD entries, and not the shared PTEs. Fixes: 652c5bf380ad ("x86/mm: Refuse W^X violations") Reported-by: Jason Andryuk Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240412151258.9171-5-jgross@suse.com Signed-off-by: Sasha Levin commit d126173b9642f5f05a2bc952128e5a6871eaca96 Author: Juergen Gross Date: Fri Apr 12 17:12:57 2024 +0200 x86/pat: Restructure _lookup_address_cpa() [ Upstream commit 02eac06b820c3eae73e5736ae62f986d37fed991 ] Modify _lookup_address_cpa() to no longer use lookup_address(), but only lookup_address_in_pgd(). This is done in preparation of using lookup_address_in_pgd_attr(). No functional change intended. Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240412151258.9171-4-jgross@suse.com Stable-dep-of: 5bc8b0f5dac0 ("x86/pat: Fix W^X violation false-positives when running as Xen PV guest") Signed-off-by: Sasha Levin commit e77e497bc58463c08e61f086698b2cca225a1cd4 Author: Juergen Gross Date: Fri Apr 12 17:12:55 2024 +0200 x86/pat: Introduce lookup_address_in_pgd_attr() [ Upstream commit ceb647b4b529fdeca9021cd34486f5a170746bda ] Add lookup_address_in_pgd_attr() doing the same as the already existing lookup_address_in_pgd(), but returning the effective settings of the NX and RW bits of all walked page table levels, too. This will be needed in order to match hardware behavior when looking for effective access rights, especially for detecting writable code pages. In order to avoid code duplication, let lookup_address_in_pgd() call lookup_address_in_pgd_attr() with dummy parameters. Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240412151258.9171-2-jgross@suse.com Stable-dep-of: 5bc8b0f5dac0 ("x86/pat: Fix W^X violation false-positives when running as Xen PV guest") Signed-off-by: Sasha Levin commit a8204d1b6ff762d2171d365c2c8560285d0a233d Author: Viresh Kumar Date: Fri Apr 12 11:19:20 2024 +0530 cpufreq: exit() callback is optional [ Upstream commit b8f85833c05730d631576008daaa34096bc7f3ce ] The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present. Signed-off-by: Viresh Kumar Fixes: 91a12e91dc39 ("cpufreq: Allow light-weight tear down and bring up of CPUs") Fixes: f339f3541701 ("cpufreq: Rearrange locking in cpufreq_remove_dev()") Reported-by: Lizhe Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 43bfd1952216d240d22810e4adc323c32cf64223 Author: Hechao Li Date: Tue Apr 9 09:43:55 2024 -0700 tcp: increase the default TCP scaling ratio [ Upstream commit 697a6c8cec03c2299f850fa50322641a8bf6b915 ] After commit dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale"), we noticed an application-level timeout due to reduced throughput. Before the commit, for a client that sets SO_RCVBUF to 65k, it takes around 22 seconds to transfer 10M data. After the commit, it takes 40 seconds. Because our application has a 30-second timeout, this regression broke the application. The reason that it takes longer to transfer data is that tp->scaling_ratio is initialized to a value that results in ~0.25 of rcvbuf. In our case, SO_RCVBUF is set to 65536 by the application, which translates to 2 * 65536 = 131,072 bytes in rcvbuf and hence a ~28k initial receive window. Later, even though the scaling_ratio is updated to a more accurate skb->len/skb->truesize, which is ~0.66 in our environment, the window stays at ~0.25 * rcvbuf. This is because tp->window_clamp does not change together with the tp->scaling_ratio update when autotuning is disabled due to SO_RCVBUF. As a result, the window size is capped at the initial window_clamp, which is also ~0.25 * rcvbuf, and never grows bigger. Most modern applications let the kernel do autotuning, and benefit from the increased scaling_ratio. But there are applications such as kafka that has a default setting of SO_RCVBUF=64k. This patch increases the initial scaling_ratio from ~25% to 50% in order to make it backward compatible with the original default sysctl_tcp_adv_win_scale for applications setting SO_RCVBUF. Fixes: dfa2f0483360 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by: Hechao Li Reviewed-by: Tycho Andersen Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/netdev/20240402215405.432863-1-hli@netflix.com/ Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 989b8f3104c2fbc747d497c0c2424ef0c2916a42 Author: Geliang Tang Date: Tue Apr 9 13:18:40 2024 +0800 selftests/bpf: Fix umount cgroup2 error in test_sockmap [ Upstream commit d75142dbeb2bd1587b9cc19f841578f541275a64 ] This patch fixes the following "umount cgroup2" error in test_sockmap.c: (cgroup_helpers.c:353: errno: Device or resource busy) umount cgroup2 Cgroup fd cg_fd should be closed before cleanup_cgroup_environment(). Fixes: 13a5f3ffd202 ("bpf: Selftests, sockmap test prog run without setting cgroup") Signed-off-by: Geliang Tang Acked-by: Yonghong Song Link: https://lore.kernel.org/r/0399983bde729708773416b8488bac2cd5e022b8.1712639568.git.tanggeliang@kylinos.cn Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 2e27dfa021d46fe1bbf427d12f0ac396cc8fc405 Author: Ard Biesheuvel Date: Wed Apr 10 17:13:55 2024 +0200 x86/boot/64: Clear most of CR4 in startup_64(), except PAE, MCE and LA57 [ Upstream commit a0025f587c685e5ff842fb0194036f2ca0b6eaf4 ] The early 64-bit boot code must be entered with a 1:1 mapping of the bootable image, but it cannot operate without a 1:1 mapping of all the assets in memory that it accesses, and therefore, it creates such mappings for all known assets upfront, and additional ones on demand when a page fault happens on a memory address. These mappings are created with the global bit G set, as the flags used to create page table descriptors are based on __PAGE_KERNEL_LARGE_EXEC defined by the core kernel, even though the context where these mappings are used is very different. This means that the TLB maintenance carried out by the decompressor is not sufficient if it is entered with CR4.PGE enabled, which has been observed to happen with the stage0 bootloader of project Oak. While this is a dubious practice if no global mappings are being used to begin with, the decompressor is clearly at fault here for creating global mappings and not performing the appropriate TLB maintenance. Since commit: f97b67a773cd84b ("x86/decompressor: Only call the trampoline when changing paging levels") CR4 is no longer modified by the decompressor if no change in the number of paging levels is needed. Before that, CR4 would always be set to a consistent value with PGE cleared. So let's reinstate a simplified version of the original logic to put CR4 into a known state, and preserve the PAE, MCE and LA57 bits, none of which can be modified freely at this point (PAE and LA57 cannot be changed while running in long mode, and MCE cannot be cleared when running under some hypervisors). This effectively clears PGE and works around the project Oak bug. Fixes: f97b67a773cd84b ("x86/decompressor: Only call the trampoline when ...") Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: "H. Peter Anvin" Link: https://lore.kernel.org/r/20240410151354.506098-2-ardb+git@google.com Signed-off-by: Sasha Levin commit 45c120fc66a268c5df665bc4dc27a3422509d697 Author: Jinjie Ruan Date: Thu Mar 14 14:38:19 2024 +0800 arm64: Remove unnecessary irqflags alternative.h include [ Upstream commit 98631c4904bf6380834c8585ce50451f00eb5389 ] Since commit 20af807d806d ("arm64: Avoid cpus_have_const_cap() for ARM64_HAS_GIC_PRIO_MASKING"), the alternative.h include is not used, so remove it. Fixes: 20af807d806d ("arm64: Avoid cpus_have_const_cap() for ARM64_HAS_GIC_PRIO_MASKING") Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/r/20240314063819.2636445-1-ruanjinjie@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit df3603b477b3a174672c28a4b747901d50f2426a Author: Andreas Gruenbacher Date: Fri Apr 5 13:47:51 2024 +0200 gfs2: Fix "ignore unlock failures after withdraw" [ Upstream commit 5d9231111966b6c5a65016d58dcbeab91055bc91 ] Commit 3e11e53041502 tries to suppress dlm_lock() lock conversion errors that occur when the lockspace has already been released. It does that by setting and checking the SDF_SKIP_DLM_UNLOCK flag. This conflicts with the intended meaning of the SDF_SKIP_DLM_UNLOCK flag, so check whether the lockspace is still allocated instead. (Given the current DLM API, checking for this kind of error after the fact seems easier that than to make sure that the lockspace is still allocated before calling dlm_lock(). Changing the DLM API so that users maintain the lockspace references themselves would be an option.) Fixes: 3e11e53041502 ("GFS2: ignore unlock failures after withdraw") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 902ec3be35398777bcf88db10e0b51efe346d249 Author: Andreas Gruenbacher Date: Fri Jan 26 11:49:44 2024 +0100 gfs2: Don't forget to complete delayed withdraw [ Upstream commit b01189333ee91c1ae6cd96dfd1e3a3c2e69202f0 ] Commit fffe9bee14b0 ("gfs2: Delay withdraw from atomic context") switched from gfs2_withdraw() to gfs2_withdraw_delayed() in gfs2_ail_error(), but failed to then check if a delayed withdraw had occurred. Fix that by adding the missing check in __gfs2_ail_flush(), where the spin locks are already dropped and a withdraw is possible. Fixes: fffe9bee14b0 ("gfs2: Delay withdraw from atomic context") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit cb0d788d2c407edef0a2974037af5ed7e1ce1e23 Author: Arnd Bergmann Date: Tue Apr 9 16:00:55 2024 +0200 ACPI: disable -Wstringop-truncation [ Upstream commit a3403d304708f60565582d60af4316289d0316a0 ] gcc -Wstringop-truncation warns about copying a string that results in a missing nul termination: drivers/acpi/acpica/tbfind.c: In function 'acpi_tb_find_table': drivers/acpi/acpica/tbfind.c:60:9: error: 'strncpy' specified bound 6 equals destination size [-Werror=stringop-truncation] 60 | strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/acpi/acpica/tbfind.c:61:9: error: 'strncpy' specified bound 8 equals destination size [-Werror=stringop-truncation] 61 | strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The code works as intended, and the warning could be addressed by using a memcpy(), but turning the warning off for this file works equally well and may be easier to merge. Fixes: 47c08729bf1c ("ACPICA: Fix for LoadTable operator, input strings") Link: https://lore.kernel.org/lkml/CAJZ5v0hoUfv54KW7y4223Mn9E7D4xvR7whRFNLTBqCZMUxT50Q@mail.gmail.com/#t Signed-off-by: Arnd Bergmann Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6eae4f148bbb8ed8b5f01d2bc2af6b83702722e0 Author: Zenghui Yu Date: Wed Mar 27 22:23:34 2024 +0800 irqchip/loongson-pch-msi: Fix off-by-one on allocation error path [ Upstream commit b327708798809328f21da8dc14cc8883d1e8a4b3 ] When pch_msi_parent_domain_alloc() returns an error, there is an off-by-one in the number of interrupts to be freed. Fix it by passing the number of successfully allocated interrupts, instead of the relative index of the last allocated one. Fixes: 632dcc2c75ef ("irqchip: Add Loongson PCH MSI controller") Signed-off-by: Zenghui Yu Signed-off-by: Thomas Gleixner Reviewed-by: Jiaxun Yang Link: https://lore.kernel.org/r/20240327142334.1098-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 4c4ffb49cf15ad69ed08310451c3c550ce978380 Author: Zenghui Yu Date: Wed Mar 27 22:23:05 2024 +0800 irqchip/alpine-msi: Fix off-by-one in allocation error path [ Upstream commit ff3669a71afa06208de58d6bea1cc49d5e3fcbd1 ] When alpine_msix_gic_domain_alloc() fails, there is an off-by-one in the number of interrupts to be freed. Fix it by passing the number of successfully allocated interrupts, instead of the relative index of the last allocated one. Fixes: 3841245e8498 ("irqchip/alpine-msi: Fix freeing of interrupts on allocation error path") Signed-off-by: Zenghui Yu Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20240327142305.1048-1-yuzenghui@huawei.com Signed-off-by: Sasha Levin commit 9945fc09ed0a8ed0f170ffbf37bce97dbb6198b2 Author: Uros Bizjak Date: Mon Apr 8 11:13:56 2024 +0200 locking/atomic/x86: Correct the definition of __arch_try_cmpxchg128() [ Upstream commit 929ad065ba2967be238dfdc0895b79fda62c7f16 ] Correct the definition of __arch_try_cmpxchg128(), introduced by: b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()") Fixes: b23e139d0b66 ("arch: Introduce arch_{,try_}_cmpxchg128{,_local}()") Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Cc: Linus Torvalds Cc: "H. Peter Anvin" Link: https://lore.kernel.org/r/20240408091547.90111-2-ubizjak@gmail.com Signed-off-by: Sasha Levin commit 5f87c3011120d5120a96c6223b183eb63801b5c7 Author: Qiuxu Zhuo Date: Mon Apr 8 20:04:19 2024 +0800 EDAC/skx_common: Allow decoding of SGX addresses [ Upstream commit e0d335077831196bffe6a634ffe385fc684192ca ] There are no "struct page" associations with SGX pages, causing the check pfn_to_online_page() to fail. This results in the inability to decode the SGX addresses and warning messages like: Invalid address 0x34cc9a98840 in IA32_MC17_ADDR Add an additional check to allow the decoding of the error address and to skip the warning message, if the error address is an SGX address. Fixes: 1e92af09fab1 ("EDAC/skx_common: Filter out the invalid address") Signed-off-by: Qiuxu Zhuo Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20240408120419.50234-1-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin commit 61d46a8355a9f6a1909c802fd9d3e975b0395840 Author: Andy Shevchenko Date: Thu Apr 4 15:06:58 2024 +0300 ACPI: LPSS: Advertise number of chip selects via property [ Upstream commit 07b73ee599428b41d0240f2f7b31b524eba07dd0 ] Advertise number of chip selects via property for Intel Braswell. Fixes: 620c803f42de ("ACPI: LPSS: Provide an SSP type to the driver") Signed-off-by: Andy Shevchenko Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e81ef65303ea8c1bcaaf95709d4dad0084629366 Author: Andrew Halaney Date: Fri Mar 29 15:46:51 2024 -0500 scsi: ufs: core: Perform read back after disabling UIC_COMMAND_COMPL [ Upstream commit 4bf3855497b60765ca03b983d064b25e99b97657 ] Currently, the UIC_COMMAND_COMPL interrupt is disabled and a wmb() is used to complete the register write before any following writes. wmb() ensures the writes complete in that order, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the wmb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: d75f7fe495cf ("scsi: ufs: reduce the interrupts for power mode change requests") Reviewed-by: Bart Van Assche Reviewed-by: Can Guo Reviewed-by: Manivannan Sadhasivam Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-9-181252004586@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 75e749f3df865bb4cbce93125f08bc4dfc3355c5 Author: Andrew Halaney Date: Fri Mar 29 15:46:50 2024 -0500 scsi: ufs: core: Perform read back after disabling interrupts [ Upstream commit e4a628877119bd40164a651d20321247b6f94a8b ] Currently, interrupts are cleared and disabled prior to registering the interrupt. An mb() is used to complete the clear/disable writes before the interrupt is registered. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring these bits have taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure these bits hit the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: 199ef13cac7d ("scsi: ufs: avoid spurious UFS host controller interrupts") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Bart Van Assche Reviewed-by: Can Guo Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-8-181252004586@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2206e5bc18ce1a28e0d2dee08c91a99466fd73f0 Author: Andrew Halaney Date: Fri Mar 29 15:46:49 2024 -0500 scsi: ufs: core: Perform read back after writing UTP_TASK_REQ_LIST_BASE_H [ Upstream commit 408e28086f1c7a6423efc79926a43d7001902fae ] Currently, the UTP_TASK_REQ_LIST_BASE_L/UTP_TASK_REQ_LIST_BASE_H regs are written to and then completed with an mb(). mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring these bits have taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bits hit the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: 88441a8d355d ("scsi: ufs: core: Add hibernation callbacks") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Bart Van Assche Reviewed-by: Can Guo Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-7-181252004586@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4bfc22dbf7bd2d707be1bb1511b4722c11423508 Author: Andrew Halaney Date: Fri Mar 29 15:46:48 2024 -0500 scsi: ufs: cdns-pltfrm: Perform read back after writing HCLKDIV [ Upstream commit b715c55daf598aac8fa339048e4ca8a0916b332e ] Currently, HCLKDIV is written to and then completed with an mb(). mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: d90996dae8e4 ("scsi: ufs: Add UFS platform driver for Cadence UFS") Reviewed-by: Manivannan Sadhasivam Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-6-181252004586@redhat.com Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bb5f55793df6e9ea007c5e8fcbe91d49ced371ed Author: Andrew Halaney Date: Fri Mar 29 15:46:47 2024 -0500 scsi: ufs: qcom: Perform read back after writing CGC enable [ Upstream commit d9488511b3ac7eb48a91bc5eded7027525525e03 ] Currently, the CGC enable bit is written and then an mb() is used to ensure that completes before continuing. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Reviewed-by: Manivannan Sadhasivam Reviewed-by: Can Guo Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms") Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-5-181252004586@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e216cf5d0fc857eb1c1c6a4f7b90c62c29cc7410 Author: Andrew Halaney Date: Fri Mar 29 15:46:46 2024 -0500 scsi: ufs: qcom: Perform read back after writing unipro mode [ Upstream commit 823150ecf04f958213cf3bf162187cd1a91c885c ] Currently, the QUNIPRO_SEL bit is written to and then an mb() is used to ensure that completes before continuing. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 But, there's really no reason to even ensure completion before continuing. The only requirement here is that this write is ordered to this endpoint (which readl()/writel() guarantees already). For that reason the mb() can be dropped altogether without anything forcing completion. Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-4-181252004586@redhat.com Reviewed-by: Manivannan Sadhasivam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d0ae42c1574ed3c69770491560921895fb43e32d Author: Andrew Halaney Date: Fri Mar 29 15:46:44 2024 -0500 scsi: ufs: qcom: Perform read back after writing REG_UFS_SYS1CLK_1US [ Upstream commit a862fafa263aea0f427d51aca6ff7fd9eeaaa8bd ] Currently after writing to REG_UFS_SYS1CLK_1US a mb() is used to ensure that write has gone through to the device. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. Because the mb()'s purpose wasn't to add extra ordering (on top of the ordering guaranteed by writel()/readl()), it can safely be removed. Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Reviewed-by: Can Guo Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-2-181252004586@redhat.com Reviewed-by: Manivannan Sadhasivam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 658314c8aff605d052b05379501d92c26594d46f Author: Andrew Halaney Date: Fri Mar 29 15:46:43 2024 -0500 scsi: ufs: qcom: Perform read back after writing reset bit [ Upstream commit c4d28e06b0c94636f6e35d003fa9ebac0a94e1ae ] Currently, the reset bit for the UFS provided reset controller (used by its phy) is written to, and then a mb() happens to try and ensure that hit the device. Immediately afterwards a usleep_range() occurs. mb() ensures that the write completes, but completion doesn't mean that it isn't stored in a buffer somewhere. The recommendation for ensuring this bit has taken effect on the device is to perform a read back to force it to make it all the way to the device. This is documented in device-io.rst and a talk by Will Deacon on this can be seen over here: https://youtu.be/i6DayghhA8Q?si=MiyxB5cKJXSaoc01&t=1678 Let's do that to ensure the bit hits the device. By doing so and guaranteeing the ordering against the immediately following usleep_range(), the mb() can safely be removed. Fixes: 81c0fc51b7a7 ("ufs-qcom: add support for Qualcomm Technologies Inc platforms") Reviewed-by: Manivannan Sadhasivam Reviewed-by: Can Guo Signed-off-by: Andrew Halaney Link: https://lore.kernel.org/r/20240329-ufs-reset-ensure-effect-before-delay-v5-1-181252004586@redhat.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a6aacd8924b8cf98af3aa272264646afb60bc22b Author: Arnd Bergmann Date: Fri Apr 5 22:49:07 2024 +0200 x86/microcode/AMD: Avoid -Wformat warning with clang-15 [ Upstream commit 9e11fc78e2df7a2649764413029441a0c897fb11 ] Older versions of clang show a warning for amd.c after a fix for a gcc warning: arch/x86/kernel/cpu/microcode/amd.c:478:47: error: format specifies type \ 'unsigned char' but the argument has type 'u16' (aka 'unsigned short') [-Werror,-Wformat] "amd-ucode/microcode_amd_fam%02hhxh.bin", family); ~~~~~~ ^~~~~~ %02hx In clang-16 and higher, this warning is disabled by default, but clang-15 is still supported, and it's trivial to avoid by adapting the types according to the range of the passed data and the format string. [ bp: Massage commit message. ] Fixes: 2e9064faccd1 ("x86/microcode/amd: Fix snprintf() format string warning in W=1 build") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240405204919.1003409-1-arnd@kernel.org Signed-off-by: Sasha Levin commit cf2134c1e2e04c2169dd586cc8488d9fd85e00ba Author: Andrii Nakryiko Date: Thu Apr 4 14:45:35 2024 -0700 bpf: prevent r10 register from being marked as precise [ Upstream commit 1f2a74b41ea8b902687eb97c4e7e3f558801865b ] r10 is a special register that is not under BPF program's control and is always effectively precise. The rest of precision logic assumes that only r0-r9 SCALAR registers are marked as precise, so prevent r10 from being marked precise. This can happen due to signed cast instruction allowing to do something like `r0 = (s8)r10;`, which later, if r0 needs to be precise, would lead to an attempt to mark r10 as precise. Prevent this with an extra check during instruction backtracking. Fixes: 8100928c8814 ("bpf: Support new sign-extension mov insns") Reported-by: syzbot+148110ee7cf72f39f33e@syzkaller.appspotmail.com Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20240404214536.3551295-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit ab47b81d50ec0d02d23802f65dc106dc485c5ac6 Author: Anton Protopopov Date: Wed Apr 3 14:33:03 2024 +0200 bpf: Pack struct bpf_fib_lookup [ Upstream commit f91717007217d975aa975ddabd91ae1a107b9bff ] The struct bpf_fib_lookup is supposed to be of size 64. A recent commit 59b418c7063d ("bpf: Add a check for struct bpf_fib_lookup size") added a static assertion to check this property so that future changes to the structure will not accidentally break this assumption. As it immediately turned out, on some 32-bit arm systems, when AEABI=n, the total size of the structure was equal to 68, see [1]. This happened because the bpf_fib_lookup structure contains a union of two 16-bit fields: union { __u16 tot_len; __u16 mtu_result; }; which was supposed to compile to a 16-bit-aligned 16-bit field. On the aforementioned setups it was instead both aligned and padded to 32-bits. Declare this inner union as __attribute__((packed, aligned(2))) such that it always is of size 2 and is aligned to 16 bits. [1] https://lore.kernel.org/all/CA+G9fYtsoP51f-oP_Sp5MOq-Ffv8La2RztNpwvE6+R1VtFiLrw@mail.gmail.com/#t Reported-by: Naresh Kamboju Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up") Signed-off-by: Anton Protopopov Signed-off-by: Andrii Nakryiko Reviewed-by: Alexander Lobakin Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240403123303.1452184-1-aspsk@isovalent.com Signed-off-by: Sasha Levin commit 547b2ce14d015ced2494a94edded8eb16afc4f33 Author: Sahil Siddiq Date: Fri Apr 5 00:52:19 2024 +0530 bpftool: Mount bpffs on provided dir instead of parent dir [ Upstream commit 478a535ae54ad3831371904d93b5dfc403222e17 ] When pinning programs/objects under PATH (eg: during "bpftool prog loadall") the bpffs is mounted on the parent dir of PATH in the following situations: - the given dir exists but it is not bpffs. - the given dir doesn't exist and the parent dir is not bpffs. Mounting on the parent dir can also have the unintentional side- effect of hiding other files located under the parent dir. If the given dir exists but is not bpffs, then the bpffs should be mounted on the given dir and not its parent dir. Similarly, if the given dir doesn't exist and its parent dir is not bpffs, then the given dir should be created and the bpffs should be mounted on this new dir. Fixes: 2a36c26fe3b8 ("bpftool: Support bpffs mountpoint as pin path for prog loadall") Signed-off-by: Sahil Siddiq Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/2da44d24-74ae-a564-1764-afccf395eeec@isovalent.com/T/#t Link: https://lore.kernel.org/bpf/20240404192219.52373-1-icegambit91@gmail.com Closes: https://github.com/libbpf/bpftool/issues/100 Changes since v1: - Split "mount_bpffs_for_pin" into two functions. This is done to improve maintainability and readability. Changes since v2: - mount_bpffs_for_pin: rename to "create_and_mount_bpffs_dir". - mount_bpffs_given_file: rename to "mount_bpffs_given_file". - create_and_mount_bpffs_dir: - introduce "dir_exists" boolean. - remove new dir if "mnt_fs" fails. - improve error handling and error messages. Changes since v3: - Rectify function name. - Improve error messages and formatting. - mount_bpffs_for_file: - Check if dir exists before block_mount check. Changes since v4: - Use strdup instead of strcpy. - create_and_mount_bpffs_dir: - Use S_IRWXU instead of 0700. - Improve error handling and formatting. Signed-off-by: Sasha Levin commit 042a39bb8e0812466327a5102606e88a5a4f8c02 Author: Arnd Bergmann Date: Thu Apr 4 09:35:58 2024 +0300 wifi: carl9170: re-fix fortified-memset warning [ Upstream commit 066afafc10c9476ee36c47c9062527a17e763901 ] The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though. Fixes: fb5f6a0e8063b ("mac80211: Use memset_after() to clear tx status") Link: https://lore.kernel.org/lkml/20230623152443.2296825-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Acked-by: Christian Lamparter Signed-off-by: Kalle Valo Link: https://msgid.link/20240328135509.3755090-2-arnd@kernel.org Signed-off-by: Sasha Levin commit ed7f28043b685e30d209e319b87e2a1134c2a5fa Author: Alexander Aring Date: Thu Mar 28 11:48:33 2024 -0400 dlm: fix user space lock decision to copy lvb [ Upstream commit ad191e0eeebf64a60ca2d16ca01a223d2b1dd25e ] This patch fixes the copy lvb decision for user space lock requests. Checking dlm_lvb_operations is done earlier, where granted/requested lock modes are available to use in the matrix. The decision had been moved to the wrong location, where granted mode and requested mode where the same, which causes the dlm_lvb_operations matix to produce the wrong copy decision. For PW or EX requests, the caller could get invalid lvb data. Fixes: 61bed0baa4db ("fs: dlm: use a non-static queue for callbacks") Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 21e40f848417f52a154e86a6d345a4eaf619ba23 Author: Alexander Lobakin Date: Wed Mar 27 16:23:41 2024 +0100 bitops: add missing prototype check [ Upstream commit 72cc1980a0ef3ccad0d539e7dace63d0d7d432a4 ] Commit 8238b4579866 ("wait_on_bit: add an acquire memory barrier") added a new bitop, test_bit_acquire(), with proper wrapping in order to try to optimize it at compile-time, but missed the list of bitops used for checking their prototypes a bit below. The functions added have consistent prototypes, so that no more changes are required and no functional changes take place. Fixes: 8238b4579866 ("wait_on_bit: add an acquire memory barrier") Reviewed-by: Przemek Kitszel Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 050556a827aeeec66931806f872d2a51d31f5987 Author: Arnd Bergmann Date: Thu Mar 28 15:30:46 2024 +0100 mlx5: stop warning for 64KB pages [ Upstream commit a5535e5336943b33689f558199366102387b7bbf ] When building with 64KB pages, clang points out that xsk->chunk_size can never be PAGE_SIZE: drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c:19:22: error: result of comparison of constant 65536 with expression of type 'u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (xsk->chunk_size > PAGE_SIZE || ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~ In older versions of this code, using PAGE_SIZE was the only possibility, so this would have never worked on 64KB page kernels, but the patch apparently did not address this case completely. As Maxim Mikityanskiy suggested, 64KB chunks are really not all that useful, so just shut up the warning by adding a cast. Fixes: 282c0c798f8e ("net/mlx5e: Allow XSK frames smaller than a page") Link: https://lore.kernel.org/netdev/20211013150232.2942146-1-arnd@kernel.org/ Link: https://lore.kernel.org/lkml/a7b27541-0ebb-4f2d-bd06-270a4d404613@app.fastmail.com/ Signed-off-by: Arnd Bergmann Acked-by: Maxim Mikityanskiy Reviewed-by: Justin Stitt Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/20240328143051.1069575-9-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f1c2867b7e21a6f071ee93c3732ac8a49d93c46b Author: Arnd Bergmann Date: Tue Mar 26 23:38:03 2024 +0100 mlx5: avoid truncating error message [ Upstream commit b324a960354b872431d25959ad384ab66a7116ec ] clang warns that one error message is too long for its destination buffer: drivers/net/ethernet/mellanox/mlx5/core/esw/bridge.c:1876:4: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 94 [-Werror,-Wformat-truncation-non-kprintf] Reword it to be a bit shorter so it always fits. Fixes: 70f0302b3f20 ("net/mlx5: Bridge, implement mdb offload") Signed-off-by: Arnd Bergmann Reviewed-by: Subbaraya Sundeep Link: https://lore.kernel.org/r/20240326223825.4084412-5-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 16182aa5d328ac7730049b8e911f7e069e7dd033 Author: Arnd Bergmann Date: Tue Mar 26 23:38:02 2024 +0100 qed: avoid truncating work queue length [ Upstream commit 954fd908f177604d4cce77e2a88cc50b29bad5ff ] clang complains that the temporary string for the name passed into alloc_workqueue() is too short for its contents: drivers/net/ethernet/qlogic/qed/qed_main.c:1218:3: error: 'snprintf' will always be truncated; specified size is 16, but format string expands to at least 18 [-Werror,-Wformat-truncation] There is no need for a temporary buffer, and the actual name of a workqueue is 32 bytes (WQ_NAME_LEN), so just use the interface as intended to avoid the truncation. Fixes: 59ccf86fe69a ("qed: Add driver infrastucture for handling mfw requests.") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240326223825.4084412-4-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a77db9cdf58170763fd61138e56f3e46ec68917a Author: Arnd Bergmann Date: Tue Mar 26 23:38:01 2024 +0100 enetc: avoid truncating error message [ Upstream commit 9046d581ed586f3c715357638ca12c0e84402002 ] As clang points out, the error message in enetc_setup_xdp_prog() still does not fit in the buffer and will be truncated: drivers/net/ethernet/freescale/enetc/enetc.c:2771:3: error: 'snprintf' will always be truncated; specified size is 80, but format string expands to at least 87 [-Werror,-Wformat-truncation] Replace it with an even shorter message that should fit. Fixes: f968c56417f0 ("net: enetc: shorten enetc_setup_xdp_prog() error message to fit NETLINK_MAX_FMTMSG_LEN") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240326223825.4084412-3-arnd@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 380e7bdce1d56fe35c095625c136421de70e9bd7 Author: Armin Wolf Date: Sat Mar 9 21:13:10 2024 +0100 ACPI: bus: Indicate support for IRQ ResourceSource thru _OSC [ Upstream commit 403ad17c06509794fdf6e4d4b3070bd5b56e2a8e ] The ACPI IRQ mapping code supports parsing of ResourceSource, but this is not reported thru _OSC. Fix this by setting bit 13 ("Interrupt ResourceSource support") when evaluating _OSC. Fixes: d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ domain mapping") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4b5e3d1b565aa1cf8e42540acb9487bd78bc58e6 Author: Armin Wolf Date: Sat Mar 9 21:13:09 2024 +0100 ACPI: Fix Generic Initiator Affinity _OSC bit [ Upstream commit d0d4f1474e36b195eaad477373127ae621334c01 ] The ACPI spec says bit 17 should be used to indicate support for Generic Initiator Affinity Structure in SRAT, but we currently set bit 13 ("Interrupt ResourceSource support"). Fix this by actually setting bit 17 when evaluating _OSC. Fixes: 01aabca2fd54 ("ACPI: Let ACPI know we support Generic Initiator Affinity Structures") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 36144e3478594bd4e1e1b97b065fd44e9e06112e Author: Armin Wolf Date: Sat Mar 9 21:13:08 2024 +0100 ACPI: bus: Indicate support for the Generic Event Device thru _OSC [ Upstream commit a8a967a243d71dd635ede076020f665a4df51c63 ] A device driver for the Generic Event Device (ACPI0013) already exists for quite some time, but support for it was never reported thru _OSC. Fix this by setting bit 11 ("Generic Event Device support") when evaluating _OSC. Fixes: 3db80c230da1 ("ACPI: implement Generic Event Device") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ae7638b5bf3e697962124e5eb9622f1e6f08584a Author: Armin Wolf Date: Sat Mar 9 21:13:07 2024 +0100 ACPI: bus: Indicate support for more than 16 p-states thru _OSC [ Upstream commit 6e8345f23ca37d6d41bb76be5d6a705ddf542817 ] The code responsible for parsing the available p-states should have no problems handling more than 16 p-states. Indicate this by setting bit 10 ("Greater Than 16 p-state support") when evaluating _OSC. Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Stable-dep-of: a8a967a243d7 ("ACPI: bus: Indicate support for the Generic Event Device thru _OSC") Signed-off-by: Sasha Levin commit 6bcbaff076499c4b438e7c3deaccd7e8217da33e Author: Armin Wolf Date: Sat Mar 9 21:13:06 2024 +0100 ACPI: bus: Indicate support for _TFP thru _OSC [ Upstream commit 95d43290f1e476b3be782dd17642e452d0436266 ] The ACPI thermal driver already uses the _TPF ACPI method to retrieve precise sampling time values, but this is not reported thru _OSC. Fix this by setting bit 9 ("Fast Thermal Sampling support") when evaluating _OSC. Fixes: a2ee7581afd5 ("ACPI: thermal: Add Thermal fast Sampling Period (_TFP) support") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ec9b366b687f4bd144953e1079f763061e2ef560 Author: Shrikanth Hegde Date: Thu Mar 7 14:27:23 2024 +0530 sched/fair: Add EAS checks before updating root_domain::overutilized [ Upstream commit be3a51e68f2f1b17250ce40d8872c7645b7a2991 ] root_domain::overutilized is only used for EAS(energy aware scheduler) to decide whether to do load balance or not. It is not used if EAS not possible. Currently enqueue_task_fair and task_tick_fair accesses, sometime updates this field. In update_sd_lb_stats it is updated often. This causes cache contention due to true sharing and burns a lot of cycles. ::overload and ::overutilized are part of the same cacheline. Updating it often invalidates the cacheline. That causes access to ::overload to slow down due to false sharing. Hence add EAS check before accessing/updating this field. EAS check is optimized at compile time or it is a static branch. Hence it shouldn't cost much. With the patch, both enqueue_task_fair and newidle_balance don't show up as hot routines in perf profile. 6.8-rc4: 7.18% swapper [kernel.vmlinux] [k] enqueue_task_fair 6.78% s [kernel.vmlinux] [k] newidle_balance +patch: 0.14% swapper [kernel.vmlinux] [k] enqueue_task_fair 0.00% swapper [kernel.vmlinux] [k] newidle_balance While at it: trace_sched_overutilized_tp expect that second argument to be bool. So do a int to bool conversion for that. Fixes: 2802bf3cd936 ("sched/fair: Add over-utilization/tipping point indicator") Signed-off-by: Shrikanth Hegde Signed-off-by: Ingo Molnar Reviewed-by: Qais Yousef Reviewed-by: Srikar Dronamraju Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20240307085725.444486-2-sshegde@linux.ibm.com Signed-off-by: Sasha Levin commit f60e3ede2d8e636d4b33abe27ab36f82d5121bbc Author: Johannes Berg Date: Mon Mar 25 18:08:51 2024 +0100 wifi: iwlwifi: mvm: fix check in iwl_mvm_sta_fw_id_mask [ Upstream commit d69aef8084cc72df7b0f2583096d9b037c647ec8 ] In the previous commit, I renamed the variable to differentiate mac80211/mvm link STA, but forgot to adjust the check. The one from mac80211 is already non-NULL anyway, but the mvm one can be NULL when the mac80211 isn't during link switch conditions. Fix the check. Fixes: 2783ab506eaa ("wifi: iwlwifi: mvm: select STA mask only for active links") Reviewed-by: Daniel Gabay Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240325180850.e95b442bafe9.I8c0119fce7b00cb4f65782930d2c167ed5dd0a6e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 007cc385828b590a9724ceb1ea4d87afa55b90bd Author: Johannes Berg Date: Wed Mar 20 23:26:38 2024 +0200 wifi: iwlwifi: reconfigure TLC during HW restart [ Upstream commit 96833fb3c7abfd57bb3ee2de2534c5a3f52b0838 ] Since the HW restart flow with multi-link is very similar to the initial association, we do need to reconfigure TLC there. Remove the check that prevented that. Fixes: d2d0468f60cd ("wifi: iwlwifi: mvm: configure TLC on link activation") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320232419.a00adcfe381a.Ic798beccbb7b7d852dc976d539205353588853b0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 092fec764af3adb6872cb9bb60cc33aa4338a2cf Author: Johannes Berg Date: Wed Mar 20 23:26:36 2024 +0200 wifi: iwlwifi: mvm: select STA mask only for active links [ Upstream commit 2783ab506eaa36dbef40bda0f96eb49fe149790e ] During reconfig, we might send keys, but those should be only sent to already active link stations. Iterate only active ones to fix that issue. Fixes: aea99650f731 ("wifi: iwlwifi: mvm: set STA mask for keys in MLO") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320232419.c6818d1c6033.I6357f05c55ef111002ddc169287eb356ca0c1b21@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 527eeac69e6508723e15a5d14fd84ff06f4a5903 Author: Johannes Berg Date: Wed Mar 20 23:26:35 2024 +0200 wifi: iwlwifi: mvm: set wider BW OFDMA ignore correctly [ Upstream commit b97b0c04f895003ec60b08879180068889d19c9e ] Clearly, I put this flag into the wrong place: devices using the code in mac80211.c only do not support EHT, so this isn't even relevant. Fix this by moving the code to the right function. Fixes: 32a5690e9acb ("wifi: iwlwifi: mvm: support wider-bandwidth OFDMA") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320232419.0d5fb0e971e4.I3b67c5e0ddcbe6e58143ec0bc4e40dd6dba4f863@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 180e204e2db2f571402b2dff29cf54d5f6d1f8e2 Author: Benjamin Berg Date: Wed Mar 20 23:26:25 2024 +0200 wifi: iwlwifi: mvm: fix active link counting during recovery [ Upstream commit 9737da2f00d6409ae48a79d4dddd9362b230aa31 ] During recovery, the chanctx_conf in mac80211 is still non-NULL even though the channel context has not yet been assigned again. In that case, the real count is actually lower. Switch to instead count the phy_ctx assignment and ensure that the assignment is cleared at the start of recovery. Fixes: 12bacfc2c065 ("wifi: iwlwifi: handle eSR transitions") Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320232419.55f37339e7d1.I57006568a90ffb7a1232def1b2f3264dea711ba6@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d9802144efb6b033316b00246c978c92e8cf43c2 Author: Ayala Beker Date: Wed Mar 20 09:14:02 2024 +0200 wifi: mac80211: don't select link ID if not provided in scan request [ Upstream commit 80b0aacd1ad046b46d471cf8ed6203bbd777f988 ] If scan request doesn't include a link ID to be used for TSF reporting, don't select it as it might become inactive before scan is actually started by the driver. Instead, let the driver select one of the active links. Fixes: cbde0b49f276 ("wifi: mac80211: Extend support for scanning while MLO connected") Signed-off-by: Ayala Beker Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240320091155.a6b643a15755.Ic28ed9a611432387b7f85e9ca9a97a4ce34a6e0f@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6db5441c7c7b3ac3b42e904c4d4ea5f08b26a294 Author: Johannes Berg Date: Tue Mar 19 10:10:27 2024 +0200 wifi: iwlwifi: mvm: allocate STA links only for active links [ Upstream commit 62bdd97598f8be82a24f556f78336b05d1c3e84b ] For the mvm driver, data structures match what's in the firmware, we allocate FW IDs for them already etc. During link switch we already allocate/free the STA links appropriately, but initially we'd allocate them always. Fix this to allocate memory, a STA ID, etc. only for active links. Fixes: 57974a55d995 ("wifi: iwlwifi: mvm: refactor iwl_mvm_mac_sta_state_common()") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240319100755.f2093ff73465.Ie891e1cc9c9df09ae22be6aad5c143e376f40f0e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit edf74d0f56e4e84c594cb1e88ece7f5d7320ab71 Author: Ilan Peer Date: Tue Mar 19 10:10:25 2024 +0200 wifi: iwlwifi: mvm: Do not warn on invalid link on scan complete [ Upstream commit 1c78d39f4ede227e50e36165b3a76bc7c37ead02 ] As it is possible that by the time the scan is completed the link was already removed. Fixes: 3a5a5cb06700 ("wifi: iwlwifi: mvm: Correctly report TSF data in scan complete") Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240319100755.619d3574a757.I0523e92547f0288c8b0119b1fdc5e967a5a8956e@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 4330bb6cf080b4f2fad2baf0fb2480375c9411f9 Author: Benjamin Berg Date: Mon Mar 18 18:53:29 2024 +0200 wifi: cfg80211: ignore non-TX BSSs in per-STA profile [ Upstream commit 97f8df4db4c8ef50b659d8b228c1f42fe111e7c8 ] If a non-TX BSS is included in a per-STA profile, then we cannot set transmitted_bss for it. Even worse, if we do things properly we should be configuring both bssid_index and max_bssid_indicator correctly. We do not actually have both pieces of information (and, some APs currently do not include either). So, ignore any per-STA profile where the RNR says that the BSS is not transmitted. Also fix transmitted_bss to never be set for per-STA profiles. This fixes issues where mac80211 was setting the reference BSSID to an incorrect value. Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses") Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240318184907.6a0babed655a.Iad447fea417c63f683da793556b97c31d07a4aab@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c3c83d287739f67cd3dc444e2ddb17e4293bc7a9 Author: Johannes Berg Date: Mon Mar 18 18:53:18 2024 +0200 wifi: ieee80211: fix ieee80211_mle_basic_sta_prof_size_ok() [ Upstream commit c121514df0daa800cc500dc2738e0b8a1c54af98 ] If there was a possibility of an MLE basic STA profile without subelements, we might reject it because we account for the one octet for sta_info_len twice (it's part of itself, and in the fixed portion). Like in ieee80211_mle_reconf_sta_prof_size_ok, subtract 1 to adjust that. When reading the elements we did take this into account, and since there are always elements, this never really mattered. Fixes: 7b6f08771bf6 ("wifi: ieee80211: Support validating ML station profile length") Signed-off-by: Johannes Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240318184907.00bb0b20ed60.I8c41dd6fc14c4b187ab901dea15ade73c79fb98c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e7412128581d85c49e8fd546c540c9e69df3a8b9 Author: Paul Menzel Date: Tue Mar 12 17:19:58 2024 +0100 x86/fred: Fix typo in Kconfig description [ Upstream commit 3c41786cab885f9c542e89f624bcdb71187dbb75 ] Fixes: 2cce95918d63 ("x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED)") Signed-off-by: Paul Menzel Signed-off-by: Ingo Molnar Acked-by: H. Peter Anvin (Intel) Link: https://lore.kernel.org/r/20240312161958.102927-2-pmenzel@molgen.mpg.de arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Signed-off-by: Sasha Levin commit 34b691c3083c06c252ef1474bbdc4598ab5b6bb7 Author: Guixiong Wei Date: Sun Mar 17 23:05:47 2024 +0800 x86/boot: Ignore relocations in .notes sections in walk_relocs() too [ Upstream commit 76e9762d66373354b45c33b60e9a53ef2a3c5ff2 ] Commit: aaa8736370db ("x86, relocs: Ignore relocations in .notes section") ... only started ignoring the .notes sections in print_absolute_relocs(), but the same logic should also by applied in walk_relocs() to avoid such relocations. [ mingo: Fixed various typos in the changelog, removed extra curly braces from the code. ] Fixes: aaa8736370db ("x86, relocs: Ignore relocations in .notes section") Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Signed-off-by: Guixiong Wei Signed-off-by: Ingo Molnar Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20240317150547.24910-1-weiguixiong@bytedance.com Signed-off-by: Sasha Levin commit 62a2f960891030d9391afadb52d1422aceb3076b Author: Lorenzo Bianconi Date: Tue Mar 19 16:12:47 2024 +0100 wifi: mt76: mt7915: workaround too long expansion sparse warnings [ Upstream commit 2d5cde1143eca31c72547dfd589702c6b4a7e684 ] Fix the following sparse warnings: drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:1133:29: error: too long token expansion drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:1133:29: error: too long token expansion drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:1133:29: error: too long token expansion drivers/net/wireless/mediatek/mt76/mt7915/debugfs.c:1133:29: error: too long token expansion No functional changes, compile tested only. Fixes: e3296759f347 ("wifi: mt76: mt7915: enable per bandwidth power limit support") Signed-off-by: Lorenzo Bianconi Acked-by: Felix Fietkau Signed-off-by: Kalle Valo Link: https://msgid.link/5457b92e41909dd75ab3db7a0e9ec372b917a386.1710858172.git.lorenzo@kernel.org Signed-off-by: Sasha Levin commit 29f6afc095d9a1a389362afd84d6cac79d06d079 Author: Aloka Dixit Date: Thu Mar 14 13:46:51 2024 -0700 wifi: ath12k: use correct flag field for 320 MHz channels [ Upstream commit 020e08ae5e68cbc0791e8d842443a86eb6aa99f6 ] Due to an error during rebasing the patchset 320 MHz channel support got broken. ath12k was setting the QoS bit instead of the correct flag. WMI_PEER_EXT_320MHZ (0x2) is defined as an extended flag, replace peer_flags by peer_flags_ext while sending peer data. This affected both QCN9274 and WCN7850 which use the same flag. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: 6734cf9b4cc7 ("wifi: ath12k: peer assoc for 320 MHz") Signed-off-by: Aloka Dixit Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240314204651.11075-1-quic_alokad@quicinc.com Signed-off-by: Sasha Levin commit 1fd91360a75833b7110af9834ae26c977e1273e0 Author: Quentin Monnet Date: Thu Mar 14 15:04:38 2024 +0000 libbpf: Prevent null-pointer dereference when prog to load has no BTF [ Upstream commit 9bf48fa19a4b1d186e08b20bf7e5de26a15644fb ] In bpf_objec_load_prog(), there's no guarantee that obj->btf is non-NULL when passing it to btf__fd(), and this function does not perform any check before dereferencing its argument (as bpf_object__btf_fd() used to do). As a consequence, we get segmentation fault errors in bpftool (for example) when trying to load programs that come without BTF information. v2: Keep btf__fd() in the fix instead of reverting to bpf_object__btf_fd(). Fixes: df7c3f7d3a3d ("libbpf: make uniform use of btf__fd() accessor inside libbpf") Suggested-by: Andrii Nakryiko Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240314150438.232462-1-qmo@kernel.org Signed-off-by: Sasha Levin commit 95aa4299fc7a3688391a3e1df95b23bbb5315e55 Author: Yonghong Song Date: Mon Mar 11 19:32:49 2024 -0700 bpftool: Fix missing pids during link show [ Upstream commit fe879bb42f8a6513ed18e9d22efb99cb35590201 ] Current 'bpftool link' command does not show pids, e.g., $ tools/build/bpftool/bpftool link ... 4: tracing prog 23 prog_type lsm attach_type lsm_mac target_obj_id 1 target_btf_id 31320 Hack the following change to enable normal libbpf debug output, # --- a/tools/bpf/bpftool/pids.c # +++ b/tools/bpf/bpftool/pids.c # @@ -121,9 +121,9 @@ int build_obj_refs_table(struct hashmap **map, enum bpf_obj_type type) # /* we don't want output polluted with libbpf errors if bpf_iter is not # * supported # */ # - default_print = libbpf_set_print(libbpf_print_none); # + /* default_print = libbpf_set_print(libbpf_print_none); */ # err = pid_iter_bpf__load(skel); # - libbpf_set_print(default_print); # + /* libbpf_set_print(default_print); */ Rerun the above bpftool command: $ tools/build/bpftool/bpftool link libbpf: prog 'iter': BPF program load failed: Permission denied libbpf: prog 'iter': -- BEGIN PROG LOAD LOG -- 0: R1=ctx() R10=fp0 ; struct task_struct *task = ctx->task; @ pid_iter.bpf.c:69 0: (79) r6 = *(u64 *)(r1 +8) ; R1=ctx() R6_w=ptr_or_null_task_struct(id=1) ; struct file *file = ctx->file; @ pid_iter.bpf.c:68 ... ; struct bpf_link *link = (struct bpf_link *) file->private_data; @ pid_iter.bpf.c:103 80: (79) r3 = *(u64 *)(r8 +432) ; R3_w=scalar() R8=ptr_file() ; if (link->type == bpf_core_enum_value(enum bpf_link_type___local, @ pid_iter.bpf.c:105 81: (61) r1 = *(u32 *)(r3 +12) R3 invalid mem access 'scalar' processed 39 insns (limit 1000000) max_states_per_insn 0 total_states 3 peak_states 3 mark_read 2 -- END PROG LOAD LOG -- libbpf: prog 'iter': failed to load: -13 ... The 'file->private_data' returns a 'void' type and this caused subsequent 'link->type' (insn #81) failed in verification. To fix the issue, restore the previous BPF_CORE_READ so old kernels can also work. With this patch, the 'bpftool link' runs successfully with 'pids'. $ tools/build/bpftool/bpftool link ... 4: tracing prog 23 prog_type lsm attach_type lsm_mac target_obj_id 1 target_btf_id 31320 pids systemd(1) Fixes: 44ba7b30e84f ("bpftool: Use a local copy of BPF_LINK_TYPE_PERF_EVENT in pid_iter.bpf.c") Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Tested-by: Quentin Monnet Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240312023249.3776718-1-yonghong.song@linux.dev Signed-off-by: Sasha Levin commit d880238e77efe5ecb91bfca12191d5237b91866c Author: Baochen Qiang Date: Sat Mar 9 19:31:15 2024 +0800 wifi: ath11k: don't force enable power save on non-running vdevs [ Upstream commit 01296b39d3515f20a1db64d3c421c592b1e264a0 ] Currently we force enable power save on non-running vdevs, this results in unexpected ping latency in below scenarios: 1. disable power save from userspace. 2. trigger suspend/resume. With step 1 power save is disabled successfully and we get a good latency: PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=5.13 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=5.45 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=5.99 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=6.34 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=4.47 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=6.45 ms While after step 2, the latency becomes much larger: PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=17.7 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=15.0 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=14.3 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=16.5 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=20.1 ms The reason is, with step 2, power save is force enabled due to vdev not running, although mac80211 was trying to disable it to honor userspace configuration: ath11k_pci 0000:03:00.0: wmi cmd sta powersave mode psmode 1 vdev id 0 Call Trace: ath11k_wmi_pdev_set_ps_mode ath11k_mac_op_bss_info_changed ieee80211_bss_info_change_notify ieee80211_reconfig ieee80211_resume wiphy_resume This logic is taken from ath10k where it was added due to below comment: Firmware doesn't behave nicely and consumes more power than necessary if PS is disabled on a non-started vdev. However we don't know whether such an issue also occurs to ath11k firmware or not. But even if it does, it's not appropriate because it goes against userspace, even cfg/mac80211 don't know we have enabled it in fact. Remove it to fix this issue. In this way we not only get a better latency, but also, and the most important, keeps the consistency between userspace and kernel/driver. The biggest price for that would be the power consumption, which is not that important, compared with the consistency. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Fixes: b2beffa7d9a6 ("ath11k: enable 802.11 power save mode in station mode") Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://msgid.link/20240309113115.11498-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 3729ca9e48d19a03ae049e2bde510e161c2f3720 Author: Duoming Zhou Date: Wed Mar 6 22:04:37 2024 +0800 wifi: brcmfmac: pcie: handle randbuf allocation failure [ Upstream commit 316f790ebcf94bdf59f794b7cdea4068dc676d4c ] The kzalloc() in brcmf_pcie_download_fw_nvram() will return null if the physical memory has run out. As a result, if we use get_random_bytes() to generate random bytes in the randbuf, the null pointer dereference bug will happen. In order to prevent allocation failure, this patch adds a separate function using buffer on kernel stack to generate random bytes in the randbuf, which could prevent the kernel stack from overflow. Fixes: 91918ce88d9f ("wifi: brcmfmac: pcie: Provide a buffer of random bytes to the device") Suggested-by: Arnd Bergmann Signed-off-by: Duoming Zhou Signed-off-by: Kalle Valo Link: https://msgid.link/20240306140437.18177-1-duoming@zju.edu.cn Signed-off-by: Sasha Levin commit 45d4c3bce3b178dadb4c68a7f41fbaca65073be1 Author: Baochen Qiang Date: Wed Mar 6 07:15:14 2024 +0200 wifi: ath10k: poll service ready message before failing [ Upstream commit e57b7d62a1b2f496caf0beba81cec3c90fad80d5 ] Currently host relies on CE interrupts to get notified that the service ready message is ready. This results in timeout issue if the interrupt is not fired, due to some unknown reasons. See below logs: [76321.937866] ath10k_pci 0000:02:00.0: wmi service ready event not received ... [76322.016738] ath10k_pci 0000:02:00.0: Could not init core: -110 And finally it causes WLAN interface bring up failure. Change to give it one more chance here by polling CE rings, before failing directly. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00157-QCARMSWPZ-1 Fixes: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices") Reported-by: James Prestwood Tested-By: James Prestwood # on QCA6174 hw3.2 Link: https://lore.kernel.org/linux-wireless/304ce305-fbe6-420e-ac2a-d61ae5e6ca1a@gmail.com/ Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240227030409.89702-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit db542a8a908a753d9a145f0e5831a05e3e8f6e33 Author: Yu Kuai Date: Thu May 9 20:37:16 2024 +0800 block: support to account io_ticks precisely [ Upstream commit 99dc422335d8b2bd4d105797241d3e715bae90e9 ] Currently, io_ticks is accounted based on sampling, specifically update_io_ticks() will always account io_ticks by 1 jiffies from bdev_start_io_acct()/blk_account_io_start(), and the result can be inaccurate, for example(HZ is 250): Test script: fio -filename=/dev/sda -bs=4k -rw=write -direct=1 -name=test -thinktime=4ms Test result: util is about 90%, while the disk is really idle. This behaviour is introduced by commit 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting"), however, there was a key point that is missed that this patch also improve performance a lot: Before the commit: part_round_stats: if (part->stamp != now) stats |= 1; part_in_flight() -> there can be lots of task here in 1 jiffies. part_round_stats_single() __part_stat_add() part->stamp = now; After the commit: update_io_ticks: stamp = part->bd_stamp; if (time_after(now, stamp)) if (try_cmpxchg()) __part_stat_add() -> only one task can reach here in 1 jiffies. Hence in order to account io_ticks precisely, we only need to know if there are IO inflight at most once in one jiffies. Noted that for rq-based device, iterating tags should not be used here because 'tags->lock' is grabbed in blk_mq_find_and_get_req(), hence part_stat_lock_inc/dec() and part_in_flight() is used to trace inflight. The additional overhead is quite little: - per cpu add/dec for each IO for rq-based device; - per cpu sum for each jiffies; And it's verified by null-blk that there are no performance degration under heavy IO pressure. Fixes: 5b18b5a73760 ("block: delete part_round_stats and switch to less precise counting") Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20240509123717.3223892-2-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c9a34b55d1bbdd9971650125b6b49ffc88d4c810 Author: INAGAKI Hiroshi Date: Sun Apr 21 16:39:52 2024 +0900 block: fix and simplify blkdevparts= cmdline parsing [ Upstream commit bc2e07dfd2c49aaa4b52302cf7b55cf94e025f79 ] Fix the cmdline parsing of the "blkdevparts=" parameter using strsep(), which makes the code simpler. Before commit 146afeb235cc ("block: use strscpy() to instead of strncpy()"), we used a strncpy() to copy a block device name and partition names. The commit simply replaced a strncpy() and NULL termination with a strscpy(). It did not update calculations of length passed to strscpy(). While the length passed to strncpy() is just a length of valid characters without NULL termination ('\0'), strscpy() takes it as a length of the destination buffer, including a NULL termination. Since the source buffer is not necessarily NULL terminated, the current code copies "length - 1" characters and puts a NULL character in the destination buffer. It replaces the last character with NULL and breaks the parsing. As an example, that buffer will be passed to parse_parts() and breaks parsing sub-partitions due to the missing ')' at the end, like the following. example (Check Point V-80 & OpenWrt): - Linux Kernel 6.6 [ 0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4 ... [ 0.884016] mmc1: new HS200 MMC card at address 0001 [ 0.889951] mmcblk1: mmc1:0001 004GA0 3.69 GiB [ 0.895043] cmdline partition format is invalid. [ 0.895704] mmcblk1: p1 [ 0.903447] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB [ 0.908667] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB [ 0.913765] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0) 1. "48M@10M(kernel-1),..." is passed to strscpy() with length=17 from parse_parts() 2. strscpy() returns -E2BIG and the destination buffer has "48M@10M(kernel-1\0" 3. "48M@10M(kernel-1\0" is passed to parse_subpart() 4. parse_subpart() fails to find ')' when parsing a partition name, and returns error - Linux Kernel 6.1 [ 0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000 crashkernel=30M mvpp2x.queue_mode=1 blkdevparts=mmcblk1:48M@10M(kernel-1),1M(dtb-1),720M(rootfs-1),48M(kernel-2),1M(dtb-2),720M(rootfs-2),300M(default_sw),650M(logs),1M(preset_cfg),1M(adsl),-(storage) maxcpus=4 ... [ 0.953142] mmc1: new HS200 MMC card at address 0001 [ 0.959114] mmcblk1: mmc1:0001 004GA0 3.69 GiB [ 0.964259] mmcblk1: p1(kernel-1) p2(dtb-1) p3(rootfs-1) p4(kernel-2) p5(dtb-2) 6(rootfs-2) p7(default_sw) p8(logs) p9(preset_cfg) p10(adsl) p11(storage) [ 0.979174] mmcblk1boot0: mmc1:0001 004GA0 2.00 MiB [ 0.984674] mmcblk1boot1: mmc1:0001 004GA0 2.00 MiB [ 0.989926] mmcblk1rpmb: mmc1:0001 004GA0 512 KiB, chardev (248:0 By the way, strscpy() takes a length of destination buffer and it is often confusing when copying characters with a specified length. Using strsep() helps to separate the string by the specified character. Then, we can use strscpy() naturally with the size of the destination buffer. Separating the string on the fly is also useful to omit the redundant string copy, reducing memory usage and improve the code readability. Fixes: 146afeb235cc ("block: use strscpy() to instead of strncpy()") Suggested-by: Naohiro Aota Signed-off-by: INAGAKI Hiroshi Reviewed-by: Daniel Golle Link: https://lore.kernel.org/r/20240421074005.565-1-musashino.open@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 10b723bcba8986537a484aa94dbfc9093fd776a1 Author: Christoph Hellwig Date: Fri May 3 10:10:42 2024 +0200 block: refine the EOF check in blkdev_iomap_begin [ Upstream commit 0c12028aec837f5a002009bbf68d179d506510e8 ] blkdev_iomap_begin rounds down the offset to the logical block size before stashing it in iomap->offset and checking that it still is inside the inode size. Check the i_size check to the raw pos value so that we don't try a zero size write if iter->pos is unaligned. Fixes: 487c607df790 ("block: use iomap for writes to block devices") Reported-by: syzbot+0a3683a0a6fecf909244@syzkaller.appspotmail.com Signed-off-by: Christoph Hellwig Tested-by: syzbot+0a3683a0a6fecf909244@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20240503081042.2078062-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1fe1a8d627fa98eb72a920e5f26f03a2feccdbf4 Author: Giovanni Cabiddu Date: Mon Apr 22 15:13:17 2024 +0100 crypto: qat - specify firmware files for 402xx [ Upstream commit a3dc1f2b6b932a13f139d3be3c765155542c1070 ] The 4xxx driver can probe 4xxx and 402xx devices. However, the driver only specifies the firmware images required for 4xxx. This might result in external tools missing these binaries, if required, in the initramfs. Specify the firmware image used by 402xx with the MODULE_FIRMWARE() macros in the 4xxx driver. Fixes: a3e8c919b993 ("crypto: qat - add support for 402xx devices") Signed-off-by: Giovanni Cabiddu Reviewed-by: Damian Muszynski Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8bbc71315e0ae4bb7e37f8d43b915e1cb01a481b Author: Yu Kuai Date: Mon Apr 22 14:58:24 2024 +0800 md: fix resync softlockup when bitmap size is less than array size [ Upstream commit f0e729af2eb6bee9eb58c4df1087f14ebaefe26b ] Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed. Fixes: 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") Reported-and-tested-by: Nigel Croxon Closes: https://lore.kernel.org/all/71ba5272-ab07-43ba-8232-d2da642acb4e@redhat.com/ Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20240422065824.2516-1-yukuai1@huaweicloud.com Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit b10acb9f0ed761fe0853fa15b06cf793598e230e Author: Kees Cook Date: Wed May 1 16:29:48 2024 -0700 kunit/fortify: Fix replaced failure path to unbreak __alloc_size [ Upstream commit 74df22453c51392476117d7330bf02cee6e987cf ] The __alloc_size annotation for kmemdup() was getting disabled under KUnit testing because the replaced fortify_panic macro implementation was using "return NULL" as a way to survive the sanity checking. But having the chance to return NULL invalidated __alloc_size, so kmemdup was not passing the __builtin_dynamic_object_size() tests any more: [23:26:18] [PASSED] fortify_test_alloc_size_kmalloc_const [23:26:19] # fortify_test_alloc_size_kmalloc_dynamic: EXPECTATION FAILED at lib/fortify_kunit.c:265 [23:26:19] Expected __builtin_dynamic_object_size(p, 1) == expected, but [23:26:19] __builtin_dynamic_object_size(p, 1) == -1 (0xffffffffffffffff) [23:26:19] expected == 11 (0xb) [23:26:19] __alloc_size() not working with __bdos on kmemdup("hello there", len, gfp) [23:26:19] [FAILED] fortify_test_alloc_size_kmalloc_dynamic Normal builds were not affected: __alloc_size continued to work there. Use a zero-sized allocation instead, which allows __alloc_size to behave. Fixes: 4ce615e798a7 ("fortify: Provide KUnit counters for failure testing") Fixes: fa4a3f86d498 ("fortify: Add KUnit tests for runtime overflows") Link: https://lore.kernel.org/r/20240501232937.work.532-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 17b2772368349acb94f22d44a977a8132009d7a1 Author: Kees Cook Date: Tue Apr 30 16:49:57 2024 -0700 lkdtm: Disable CFI checking for perms functions [ Upstream commit fb28a8862dc4b5bf8e44578338f35d9c6c68339d ] The EXEC_RODATA test plays a lot of tricks to live in the .rodata section, and once again ran into objtool's (completely reasonable) assumptions that executable code should live in an executable section. However, this manifested only under CONFIG_CFI_CLANG=y, as one of the .cfi_sites was pointing into the .rodata section. Since we're testing non-CFI execution properties in perms.c (and rodata.c), we can disable CFI for the involved functions, and remove the CFI arguments from rodata.c entirely. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202308301532.d7acf63e-oliver.sang@intel.com Fixes: 6342a20efbd8 ("objtool: Add elf_create_section_pair()") Link: https://lore.kernel.org/r/20240430234953.work.760-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit bd54d7c8e76d235b4a70be3a545eb13f5ac531e4 Author: Bjorn Andersson Date: Tue Apr 30 20:38:57 2024 -0700 soc: qcom: pmic_glink: Make client-lock non-sleeping [ Upstream commit 9329933699b32d467a99befa20415c4b2172389a ] The recently introduced commit '635ce0db8956 ("soc: qcom: pmic_glink: don't traverse clients list without a lock")' ensured that the clients list is not modified while traversed. But the callback is made from the GLINK IRQ handler and as such this mutual exclusion can not be provided by a (sleepable) mutex. Replace the mutex with a spinlock. Fixes: 635ce0db8956 ("soc: qcom: pmic_glink: don't traverse clients list without a lock") Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240430-pmic-glink-sleep-while-atomic-v1-1-88fb493e8545@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 47add3b61943c5d636cb70d5578c5d88648840eb Author: Pavel Begunkov Date: Tue Apr 30 16:42:30 2024 +0100 io_uring/net: fix sendzc lazy wake polling [ Upstream commit ef42b85a5609cd822ca0a68dd2bef2b12b5d1ca3 ] SEND[MSG]_ZC produces multiple CQEs via notifications, LAZY_WAKE doesn't handle it and so disable LAZY_WAKE for sendzc polling. It should be fine, sends are not likely to be polled in the first place. Fixes: 6ce4a93dbb5b ("io_uring/poll: use IOU_F_TWQ_LAZY_WAKE for wakeups") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/5b360fb352d91e3aec751d75c87dfb4753a084ee.1714488419.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bd0f510fa393c2206fabd4ac36692d0afd0990e7 Author: Sumanth Korikkar Date: Thu Apr 25 16:59:30 2024 +0200 s390: vmlinux.lds.S: Drop .hash and .gnu.hash for !CONFIG_PIE_BUILD [ Upstream commit 5f90003f09042b504d90ee38618cfd380ce16f4a ] Sections .hash and .gnu.hash are only created when CONFIG_PIE_BUILD option is enabled. Drop these for the case CONFIG_PIE_BUILD is disabled. [ agordeev: Reworded the commit message ] Fixes: 778666df60f0 ("s390: compile relocatable kernel without -fPIE") Suggested-by: Alexander Gordeev Signed-off-by: Sumanth Korikkar Reviewed-by: Alexander Gordeev Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 03758d5a0932016b6d5f5bfbca580177e6bc937a Author: Kees Cook Date: Thu Apr 25 16:06:22 2024 -0700 kunit/fortify: Fix mismatched kvalloc()/vfree() usage [ Upstream commit 998b18072ceb0613629c256b409f4d299829c7ec ] The kv*() family of tests were accidentally freeing with vfree() instead of kvfree(). Use kvfree() instead. Fixes: 9124a2640148 ("kunit/fortify: Validate __alloc_size attribute results") Link: https://lore.kernel.org/r/20240425230619.work.299-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 49ea3b6a54716dc4f2e2a26208b803f4b7609173 Author: Marek Vasut Date: Fri Apr 19 07:01:14 2024 +0200 hwrng: stm32 - repair clock handling [ Upstream commit c819d7b836c5dfca0854d3e56664293601f2176d ] The clock management in this driver does not seem to be correct. The struct hwrng .init callback enables the clock, but there is no matching .cleanup callback to disable the clock. The clock get disabled as some later point by runtime PM suspend callback. Furthermore, both runtime PM and sleep suspend callbacks access registers first and disable clock which are used for register access second. If the IP is already in RPM suspend and the system enters sleep state, the sleep callback will attempt to access registers while the register clock are already disabled. This bug has been fixed once before already in commit 9bae54942b13 ("hwrng: stm32 - fix pm_suspend issue"), and regressed in commit ff4e46104f2e ("hwrng: stm32 - rework power management sequences") . Fix this slightly differently, disable register clock at the end of .init callback, this way the IP is disabled after .init. On every access to the IP, which really is only stm32_rng_read(), do pm_runtime_get_sync() which is already done in stm32_rng_read() to bring the IP from RPM suspend, and pm_runtime_mark_last_busy()/pm_runtime_put_sync_autosuspend() to put it back into RPM suspend. Change sleep suspend/resume callbacks to enable and disable register clock around register access, as those cannot use the RPM suspend/resume callbacks due to slightly different initialization in those sleep callbacks. This way, the register access should always be performed with clock surely enabled. Fixes: ff4e46104f2e ("hwrng: stm32 - rework power management sequences") Signed-off-by: Marek Vasut Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6eff7c35a14c484fbcb411359df76298a6c78b80 Author: Marek Vasut Date: Fri Apr 19 07:01:13 2024 +0200 hwrng: stm32 - put IP into RPM suspend on failure [ Upstream commit da62ed5c019cc48648f37c7a07e6a56cf637a795 ] In case of an irrecoverable failure, put the IP into RPM suspend to avoid RPM imbalance. I did not trigger this case, but it seems it should be done based on reading the code. Fixes: b17bc6eb7c2b ("hwrng: stm32 - rework error handling in stm32_rng_read()") Signed-off-by: Marek Vasut Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4d93bb0769df3f4ded2d2a8f5ce6bb64da0ace41 Author: Marek Vasut Date: Fri Apr 19 07:01:12 2024 +0200 hwrng: stm32 - use logical OR in conditional [ Upstream commit 31b57788a5024d3a114b28dad224a93831b90b5f ] The conditional is used to check whether err is non-zero OR whether reg variable is non-zero after clearing bits from it. This should be done using logical OR, not bitwise OR, fix it. Fixes: 6b85a7e141cb ("hwrng: stm32 - implement STM32MP13x support") Signed-off-by: Marek Vasut Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9b284b915e2a5e63ca133353f8c456eff4446f82 Author: Lucas Segarra Fernandez Date: Tue Apr 16 12:33:37 2024 +0200 crypto: qat - validate slices count returned by FW [ Upstream commit 483fd65ce29317044d1d00757e3fd23503b6b04c ] The function adf_send_admin_tl_start() enables the telemetry (TL) feature on a QAT device by sending the ICP_QAT_FW_TL_START message to the firmware. This triggers the FW to start writing TL data to a DMA buffer in memory and returns an array containing the number of accelerators of each type (slices) supported by this HW. The pointer to this array is stored in the adf_tl_hw_data data structure called slice_cnt. The array slice_cnt is then used in the function tl_print_dev_data() to report in debugfs only statistics about the supported accelerators. An incorrect value of the elements in slice_cnt might lead to an out of bounds memory read. At the moment, there isn't an implementation of FW that returns a wrong value, but for robustness validate the slice count array returned by FW. Fixes: 69e7649f7cc2 ("crypto: qat - add support for device telemetry") Signed-off-by: Lucas Segarra Fernandez Reviewed-by: Damian Muszynski Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e61b07f5b41661ee04bd085d6518a51611357eee Author: Zhu Yanjun Date: Thu Apr 25 19:16:35 2024 +0200 null_blk: Fix missing mutex_destroy() at module removal [ Upstream commit 07d1b99825f40f9c0d93e6b99d79a08d0717bac1 ] When a mutex lock is not used any more, the function mutex_destroy should be called to mark the mutex lock uninitialized. Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver") Signed-off-by: Zhu Yanjun Link: https://lore.kernel.org/r/20240425171635.4227-1-yanjun.zhu@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a8d8cd3d90104e5a822a6c70cc9b8d0ddaff894d Author: Chun-Kuang Hu Date: Thu Feb 22 15:41:09 2024 +0000 soc: mediatek: cmdq: Fix typo of CMDQ_JUMP_RELATIVE [ Upstream commit ed4d5ab179b9f0a60da87c650a31f1816db9b4b4 ] For cmdq jump command, offset 0 means relative jump and offset 1 means absolute jump. cmdq_pkt_jump() is absolute jump, so fix the typo of CMDQ_JUMP_RELATIVE in cmdq_pkt_jump(). Fixes: 946f1792d3d7 ("soc: mediatek: cmdq: add jump function") Signed-off-by: Chun-Kuang Hu Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240222154120.16959-2-chunkuang.hu@kernel.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin commit 986065fab4c1d1202b832906e700b583eb26ce1c Author: Mukesh Ojha Date: Thu Mar 21 20:54:02 2024 +0530 firmware: qcom: scm: Fix __scm and waitq completion variable initialization [ Upstream commit 2e4955167ec5c04534cebea9e8273a907e7a75e1 ] It is possible qcom_scm_is_available() gives wrong indication that if __scm is initialized while __scm->dev is not and similar issue is also possible with __scm->waitq_comp. Fix this appropriately by the use of release barrier and read barrier that will make sure if __scm is initialized so, is all of its field variable. Fixes: d0f6fa7ba2d6 ("firmware: qcom: scm: Convert SCM to platform driver") Fixes: 6bf325992236 ("firmware: qcom: scm: Add wait-queue handling logic") Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/1711034642-22860-4-git-send-email-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bd8fad5e1884f94a2550e35699bc494df6f581f7 Author: Dmitry Baryshkov Date: Wed Apr 3 06:10:58 2024 +0300 soc: qcom: pmic_glink: notify clients about the current state [ Upstream commit d6cbce2cd354c9a37a558f290a8f1dfd20584f99 ] In case the client is registered after the pmic-glink recived a response from the Protection Domain mapper, it is going to miss the notification about the state. Notify clients about the current state upon registration. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Reviewed-by: Andrew Halaney Signed-off-by: Dmitry Baryshkov Reviewed-by: Mukesh Ojha Tested-by: Xilin Wu # on QCS8550 AYN Odin 2 Link: https://lore.kernel.org/r/20240403-pmic-glink-fix-clients-v2-2-aed4e02baacc@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5bc8621bbb88b6cdddd83861f81e7271ac633ebd Author: Dmitry Baryshkov Date: Wed Apr 3 06:10:57 2024 +0300 soc: qcom: pmic_glink: don't traverse clients list without a lock [ Upstream commit 635ce0db89567ba62f64b79e8c6664ba3eff6516 ] Take the client_lock before traversing the clients list at the pmic_glink_state_notify_clients() function. This is required to keep the list traversal safe from concurrent modification. Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver") Signed-off-by: Dmitry Baryshkov Reviewed-by: Andrew Halaney Reviewed-by: Mukesh Ojha Tested-by: Xilin Wu # on QCS8550 AYN Odin 2 Link: https://lore.kernel.org/r/20240403-pmic-glink-fix-clients-v2-1-aed4e02baacc@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 268e10ca748732fca24eff07061e8c3908df8617 Author: Adam Guerin Date: Fri Apr 12 13:24:03 2024 +0100 crypto: qat - improve error logging to be consistent across features [ Upstream commit d281a28bd2a94d72c440457e05a2f04a52f15947 ] Improve error logging in rate limiting feature. Staying consistent with the error logging found in the telemetry feature. Fixes: d9fb8408376e ("crypto: qat - add rate limiting feature to qat_4xxx") Signed-off-by: Adam Guerin Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7e07141d6453f6e2a1674c7c04a2d10314824090 Author: Adam Guerin Date: Fri Apr 12 13:24:02 2024 +0100 crypto: qat - improve error message in adf_get_arbiter_mapping() [ Upstream commit 4a4fc6c0c7fe29f2538013a57ebd7813ec6c12a8 ] Improve error message to be more readable. Fixes: 5da6a2d5353e ("crypto: qat - generate dynamically arbiter mappings") Signed-off-by: Adam Guerin Reviewed-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b1e82d4fc198de04f7201c8f2e6010f3192a26ba Author: Chen Ni Date: Mon Apr 8 01:59:14 2024 +0000 crypto: octeontx2 - add missing check for dma_map_single [ Upstream commit 6a6d6a3a328a59ed0d8ae2e65696ef38e49133a0 ] Add check for dma_map_single() and return error if it fails in order to avoid invalid dma address. Fixes: e92971117c2c ("crypto: octeontx2 - add ctx_val workaround") Signed-off-by: Chen Ni Reviewed-by: Bharat Bhushan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 80a6f175f9a2266453269d282f1aada0143b89fb Author: David Hildenbrand Date: Thu Apr 11 18:14:41 2024 +0200 s390/mm: Re-enable the shared zeropage for !PV and !skeys KVM guests [ Upstream commit 06201e00ee3e4beacac48aab2b83eff64ebf0bc0 ] commit fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs") introduced an undesired side effect when combined with memory ballooning and VM migration: memory part of the inflated memory balloon will consume memory. Assuming we have a 100GiB VM and inflated the balloon to 40GiB. Our VM will consume ~60GiB of memory. If we now trigger a VM migration, hypervisors like QEMU will read all VM memory. As s390x does not support the shared zeropage, we'll end up allocating for all previously-inflated memory part of the memory balloon: 50 GiB. So we might easily (unexpectedly) crash the VM on the migration source. Even worse, hypervisors like QEMU optimize for zeropage migration to not consume memory on the migration destination: when migrating a "page full of zeroes", on the migration destination they check whether the target memory is already zero (by reading the destination memory) and avoid writing to the memory to not allocate memory: however, s390x will also allocate memory here, implying that also on the migration destination, we will end up allocating all previously-inflated memory part of the memory balloon. This is especially bad if actual memory overcommit was not desired, when memory ballooning is used for dynamic VM memory resizing, setting aside some memory during boot that can be added later on demand. Alternatives like virtio-mem that would avoid this issue are not yet available on s390x. There could be ways to optimize some cases in user space: before reading memory in an anonymous private mapping on the migration source, check via /proc/self/pagemap if anything is already populated. Similarly check on the migration destination before reading. While that would avoid populating tables full of shared zeropages on all architectures, it's harder to get right and performant, and requires user space changes. Further, with posctopy live migration we must place a page, so there, "avoid touching memory to avoid allocating memory" is not really possible. (Note that a previously we would have falsely inserted shared zeropages into processes using UFFDIO_ZEROPAGE where mm_forbids_zeropage() would have actually forbidden it) PV is currently incompatible with memory ballooning, and in the common case, KVM guests don't make use of storage keys. Instead of zapping zeropages when enabling storage keys / PV, that turned out to be problematic in the past, let's do exactly the same we do with KSM pages: trigger unsharing faults to replace the shared zeropages by proper anonymous folios. What about added latency when enabling storage kes? Having a lot of zeropages in applicable environments (PV, legacy guests, unittests) is unexpected. Further, KSM could today already unshare the zeropages and unmerging KSM pages when enabling storage kets would unshare the KSM-placed zeropages in the same way, resulting in the same latency. [ agordeev: Fixed sparse and checkpatch complaints and error handling ] Reviewed-by: Christian Borntraeger Tested-by: Christian Borntraeger Fixes: fa41ba0d08de ("s390/mm: avoid empty zero pages for KVM guests to avoid postcopy hangs") Signed-off-by: David Hildenbrand Link: https://lore.kernel.org/r/20240411161441.910170-3-david@redhat.com Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 95720873fe9caddd134fa99841dc717a63685464 Author: David Hildenbrand Date: Thu Apr 11 18:14:40 2024 +0200 mm/userfaultfd: Do not place zeropages when zeropages are disallowed [ Upstream commit 90a7592da14951bd21f74a53246ba30955a648aa ] s390x must disable shared zeropages for processes running VMs, because the VMs could end up making use of "storage keys" or protected virtualization, which are incompatible with shared zeropages. Yet, with userfaultfd it is possible to insert shared zeropages into such processes. Let's fallback to simply allocating a fresh zeroed anonymous folio and insert that instead. mm_forbids_zeropage() was introduced in commit 593befa6ab74 ("mm: introduce mm_forbids_zeropage function"), briefly before userfaultfd went upstream. Note that we don't want to fail the UFFDIO_ZEROPAGE request like we do for hugetlb, it would be rather unexpected. Further, we also cannot really indicated "not supported" to user space ahead of time: it could be that the MM disallows zeropages after userfaultfd was already registered. [ agordeev: Fixed checkpatch complaints ] Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Reviewed-by: Peter Xu Link: https://lore.kernel.org/r/20240411161441.910170-2-david@redhat.com Signed-off-by: David Hildenbrand Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 7a8de6309eecc60b4a99bf346103d69f1aefcdc6 Author: Gabriel Krisman Bertazi Date: Mon Apr 15 22:10:53 2024 -0400 io-wq: write next_work before dropping acct_lock [ Upstream commit 068c27e32e51e94e4a9eb30ae85f4097a3602980 ] Commit 361aee450c6e ("io-wq: add intermediate work step between pending list and active work") closed a race between a cancellation and the work being removed from the wq for execution. To ensure the request is always reachable by the cancellation, we need to move it within the wq lock, which also synchronizes the cancellation. But commit 42abc95f05bf ("io-wq: decouple work_list protection from the big wqe->lock") replaced the wq lock here and accidentally reintroduced the race by releasing the acct_lock too early. In other words: worker | cancellation work = io_get_next_work() | raw_spin_unlock(&acct->lock); | | | io_acct_cancel_pending_work | io_wq_worker_cancel() worker->next_work = work Using acct_lock is still enough since we synchronize on it on io_acct_cancel_pending_work. Fixes: 42abc95f05bf ("io-wq: decouple work_list protection from the big wqe->lock") Signed-off-by: Gabriel Krisman Bertazi Link: https://lore.kernel.org/r/20240416021054.3940-2-krisman@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d5f5dc59d593a924f26d2e2f13b9eae213001328 Author: Chuck Lever Date: Mon Apr 15 11:20:56 2024 -0400 shmem: Fix shmem_rename2() [ Upstream commit ad191eb6d6942bb835a0b20b647f7c53c1d99ca4 ] When renaming onto an existing directory entry, user space expects the replacement entry to have the same directory offset as the original one. Link: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15966 Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-4-cel@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit b770b6f6a44e26e1079a04981a6f37b6ab05e39e Author: Chuck Lever Date: Mon Apr 15 11:20:55 2024 -0400 libfs: Add simple_offset_rename() API [ Upstream commit 5a1a25be995e1014abd01600479915683e356f5c ] I'm about to fix a tmpfs rename bug that requires the use of internal simple_offset helpers that are not available in mm/shmem.c Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-3-cel@kernel.org Signed-off-by: Christian Brauner Stable-dep-of: ad191eb6d694 ("shmem: Fix shmem_rename2()") Signed-off-by: Sasha Levin commit 1005b273bd9aa010d23eafd4e3ad88661f1f9e16 Author: Chuck Lever Date: Mon Apr 15 11:20:54 2024 -0400 libfs: Fix simple_offset_rename_exchange() [ Upstream commit 23cdd0eed3f1fff3af323092b0b88945a7950d8e ] User space expects the replacement (old) directory entry to have the same directory offset after the rename. Suggested-by: Christian Brauner Fixes: a2e459555c5f ("shmem: stable directory offsets") Signed-off-by: Chuck Lever Link: https://lore.kernel.org/r/20240415152057.4605-2-cel@kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 978a12c91b38bf1a213e567f3c20e2beef215f07 Author: Ilya Denisyev Date: Fri Apr 12 18:53:54 2024 +0300 jffs2: prevent xattr node from overflowing the eraseblock [ Upstream commit c6854e5a267c28300ff045480b5a7ee7f6f1d913 ] Add a check to make sure that the requested xattr node size is no larger than the eraseblock minus the cleanmarker. Unlike the usual inode nodes, the xattr nodes aren't split into parts and spread across multiple eraseblocks, which means that a xattr node must not occupy more than one eraseblock. If the requested xattr value is too large, the xattr node can spill onto the next eraseblock, overwriting the nodes and causing errors such as: jffs2: argh. node added in wrong place at 0x0000b050(2) jffs2: nextblock 0x0000a000, expected at 0000b00c jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050, read=0xfc892c93, calc=0x000000 jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed at 0x01e00c. {848f,2fc4,0fef511f,59a3d171} jffs2: Node at 0x0000000c with length 0x00001044 would run over the end of the erase block jffs2: Perhaps the file system was created with the wrong erase size? jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000010: 0x1044 instead This breaks the filesystem and can lead to KASAN crashes such as: BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0 Read of size 4 at addr ffff88802c31e914 by task repro/830 CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Call Trace: dump_stack_lvl+0xc6/0x120 print_report+0xc4/0x620 ? __virt_addr_valid+0x308/0x5b0 kasan_report+0xc1/0xf0 ? jffs2_sum_add_kvec+0x125e/0x15d0 ? jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_sum_add_kvec+0x125e/0x15d0 jffs2_flash_direct_writev+0xa8/0xd0 jffs2_flash_writev+0x9c9/0xef0 ? __x64_sys_setxattr+0xc4/0x160 ? do_syscall_64+0x69/0x140 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: aa98d7cf59b5 ("[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)") Signed-off-by: Ilya Denisyev Link: https://lore.kernel.org/r/20240412155357.237803-1-dev@elkcl.ru Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit ccad6e25b76f71fe987927e3f8c4472738f9cfe1 Author: Maxime Ripard Date: Wed Apr 3 12:56:23 2024 +0200 ARM: configs: sunxi: Enable DRM_DW_HDMI [ Upstream commit deff401b14e2d832b25b55862ad6c73378fe034e ] Commit 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") turned the DRM_DW_HDMI dependency of DRM_SUN8I_DW_HDMI into a depends on which ended up disabling the driver in the defconfig. Make sure it's still enabled. Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") Reported-by: Mark Brown Reported-by: Alexander Stein Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec Link: https://lore.kernel.org/r/20240403-fix-dw-hdmi-kconfig-v1-5-afbc4a835c38@kernel.org Signed-off-by: Jernej Skrabec Signed-off-by: Sasha Levin commit 4c3e2ef4d8ddd313c8ce3ac30505940bea8d6257 Author: Nikita Kiryushin Date: Mon Apr 1 22:43:15 2024 +0300 rcu: Fix buffer overflow in print_cpu_stall_info() [ Upstream commit 3758f7d9917bd7ef0482c4184c0ad673b4c4e069 ] The rcuc-starvation output from print_cpu_stall_info() might overflow the buffer if there is a huge difference in jiffies difference. The situation might seem improbable, but computers sometimes get very confused about time, which can result in full-sized integers, and, in this case, buffer overflow. Also, the unsigned jiffies difference is printed using %ld, which is normally for signed integers. This is intentional for debugging purposes, but it is not obvious from the code. This commit therefore changes sprintf() to snprintf() and adds a clarifying comment about intention of %ld format. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 245a62982502 ("rcu: Dump rcuc kthread status for CPUs not reporting quiescent state") Signed-off-by: Nikita Kiryushin Reviewed-by: Steven Rostedt (Google) Signed-off-by: Paul E. McKenney Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Sasha Levin commit 1a240e138071b25944ded0f5b3e357aa99fabcb7 Author: Nikita Kiryushin Date: Wed Mar 27 20:47:47 2024 +0300 rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow [ Upstream commit cc5645fddb0ce28492b15520306d092730dffa48 ] There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: edf3775f0ad6 ("rcu-tasks: Add count for idle tasks on offline CPUs") Signed-off-by: Nikita Kiryushin Reviewed-by: Steven Rostedt (Google) Signed-off-by: Paul E. McKenney Signed-off-by: Uladzislau Rezki (Sony) Signed-off-by: Sasha Levin commit 80924b344de0230b12c1f7d4e179507482cc1f7a Author: Jens Axboe Date: Mon Mar 25 18:53:33 2024 -0600 io_uring: use the right type for work_llist empty check [ Upstream commit 22537c9f79417fed70b352d54d01d2586fee9521 ] io_task_work_pending() uses wq_list_empty() on ctx->work_llist, but it's not an io_wq_work_list, it's a struct llist_head. They both have ->first as head-of-list, and it turns out the checks are identical. But be proper and use the right helper. Fixes: dac6a0eae793 ("io_uring: ensure iopoll runs local task work as well") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 1461b430ee730990da7d9ff83d29f6a457260f2d Author: Peter Oberparleiter Date: Tue Mar 26 17:04:56 2024 +0100 s390/cio: fix tracepoint subchannel type field [ Upstream commit 8692a24d0fae19f674d51726d179ad04ba95d958 ] The subchannel-type field "st" of s390_cio_stsch and s390_cio_msch tracepoints is incorrectly filled with the subchannel-enabled SCHIB value "ena". Fix this by assigning the correct value. Fixes: d1de8633d96a ("s390 cio: Rewrite trace point class s390_class_schib") Reviewed-by: Heiko Carstens Signed-off-by: Peter Oberparleiter Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 74737ae1310170ce16a6cd3b2d9de249187eefcb Author: Eric Biggers Date: Fri Apr 5 20:26:10 2024 -0400 crypto: x86/sha512-avx2 - add missing vzeroupper [ Upstream commit 6a24fdfe1edbafacdacd53516654d99068f20eec ] Since sha512_transform_rorx() uses ymm registers, execute vzeroupper before returning from it. This is necessary to avoid reducing the performance of SSE code. Fixes: e01d69cb0195 ("crypto: sha512 - Optimized SHA512 x86_64 assembly routine using AVX instructions.") Signed-off-by: Eric Biggers Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f23d6d4d8fcd2a5e50841b439cc6da9bb92f8008 Author: Eric Biggers Date: Fri Apr 5 20:26:09 2024 -0400 crypto: x86/sha256-avx2 - add missing vzeroupper [ Upstream commit 57ce8a4e162599cf9adafef1f29763160a8e5564 ] Since sha256_transform_rorx() uses ymm registers, execute vzeroupper before returning from it. This is necessary to avoid reducing the performance of SSE code. Fixes: d34a460092d8 ("crypto: sha256 - Optimized sha256 x86_64 routine using AVX2's RORX instructions") Signed-off-by: Eric Biggers Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1271214fc607e6c3cac5198d167ba832151d331a Author: Eric Biggers Date: Fri Apr 5 20:26:08 2024 -0400 crypto: x86/nh-avx2 - add missing vzeroupper [ Upstream commit 4ad096cca942959871d8ff73826d30f81f856f6e ] Since nh_avx2() uses ymm registers, execute vzeroupper before returning from it. This is necessary to avoid reducing the performance of SSE code. Fixes: 0f961f9f670e ("crypto: x86/nhpoly1305 - add AVX2 accelerated NHPoly1305") Signed-off-by: Eric Biggers Acked-by: Tim Chen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 719f22ce6f42096b76e14d9d98e2c0efc8edc3c3 Author: Arnd Bergmann Date: Wed Apr 3 10:06:42 2024 +0200 crypto: ccp - drop platform ifdef checks [ Upstream commit 42c2d7d02977ef09d434b1f5b354f5bc6c1027ab ] When both ACPI and OF are disabled, the dev_vdata variable is unused: drivers/crypto/ccp/sp-platform.c:33:34: error: unused variable 'dev_vdata' [-Werror,-Wunused-const-variable] This is not a useful configuration, and there is not much point in saving a few bytes when only one of the two is enabled, so just remove all these ifdef checks and rely on of_match_node() and acpi_match_device() returning NULL when these subsystems are disabled. Fixes: 6c5063434098 ("crypto: ccp - Add ACPI support") Signed-off-by: Arnd Bergmann Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 52404a40bbdf67096ec9b17d1de5399cc10fa9e4 Author: Al Viro Date: Mon Apr 1 22:35:54 2024 -0400 parisc: add missing export of __cmpxchg_u8() [ Upstream commit c57e5dccb06decf3cb6c272ab138c033727149b5 ] __cmpxchg_u8() had been added (initially) for the sake of drivers/phy/ti/phy-tusb1210.c; the thing is, that drivers is modular, so we need an export Fixes: b344d6a83d01 "parisc: add support for cmpxchg on u8 pointers" Signed-off-by: Al Viro Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit ffb1fc7ddfea7a6e0b3ae6e02d173afe501b2b71 Author: Arnd Bergmann Date: Thu Mar 28 15:30:44 2024 +0100 nilfs2: fix out-of-range warning [ Upstream commit c473bcdd80d4ab2ae79a7a509a6712818366e32a ] clang-14 points out that v_size is always smaller than a 64KB page size if that is configured by the CPU architecture: fs/nilfs2/ioctl.c:63:19: error: result of comparison of constant 65536 with expression of type '__u16' (aka 'unsigned short') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (argv->v_size > PAGE_SIZE) ~~~~~~~~~~~~ ^ ~~~~~~~~~ This is ok, so just shut up that warning with a cast. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240328143051.1069575-7-arnd@kernel.org Fixes: 3358b4aaa84f ("nilfs2: fix problems of memory allocation in ioctl") Acked-by: Ryusuke Konishi Reviewed-by: Justin Stitt Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit f6008487f1eeb8693f8d2a36a89c87d9122ddf74 Author: Brian Kubisiak Date: Sun Mar 17 07:46:00 2024 -0700 ecryptfs: Fix buffer size for tag 66 packet [ Upstream commit 85a6a1aff08ec9f5b929d345d066e2830e8818e5 ] The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer. Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer. This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 __asan_store1+0x62/0x80 ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10 ? __alloc_pages+0x2e2/0x540 ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d] ? dentry_open+0x8f/0xd0 ecryptfs_write_metadata+0x30a/0x550 ? __pfx_ecryptfs_write_metadata+0x10/0x10 ? ecryptfs_get_lower_file+0x6b/0x190 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 ? __pfx_path_openat+0x10/0x10 do_filp_open+0x15e/0x290 ? __pfx_do_filp_open+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? _raw_spin_lock+0x86/0xf0 ? __pfx__raw_spin_lock+0x10/0x10 ? __kasan_check_write+0x18/0x30 ? alloc_fd+0xf4/0x330 do_sys_openat2+0x122/0x160 ? __pfx_do_sys_openat2+0x10/0x10 __x64_sys_openat+0xef/0x170 ? __pfx___x64_sys_openat+0x10/0x10 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f00a703fd67 Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67 RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941 R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040 Allocated by task 181: kasan_save_stack+0x2f/0x60 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x25/0x40 __kasan_kmalloc+0xc5/0xd0 __kmalloc+0x66/0x160 ecryptfs_generate_key_packet_set+0x6d2/0xde0 ecryptfs_write_metadata+0x30a/0x550 ecryptfs_initialize_file+0x77/0x150 ecryptfs_create+0x1c2/0x2f0 path_openat+0x17cf/0x1ba0 do_filp_open+0x15e/0x290 do_sys_openat2+0x122/0x160 __x64_sys_openat+0xef/0x170 do_syscall_64+0x60/0xd0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Fixes: dddfa461fc89 ("[PATCH] eCryptfs: Public key; packet management") Signed-off-by: Brian Kubisiak Link: https://lore.kernel.org/r/5j2q56p6qkhezva6b2yuqfrsurmvrrqtxxzrnp3wqu7xrz22i7@hoecdztoplbl Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit eedb420f4ce282563342d5f480c51237822cd2d3 Author: Laurent Pinchart Date: Tue Mar 26 21:58:06 2024 +0200 firmware: raspberrypi: Use correct device for DMA mappings [ Upstream commit df518a0ae1b982a4dcf2235464016c0c4576a34d ] The buffer used to transfer data over the mailbox interface is mapped using the client's device. This is incorrect, as the device performing the DMA transfer is the mailbox itself. Fix it by using the mailbox controller device instead. This requires including the mailbox_controller.h header to dereference the mbox_chan and mbox_controller structures. The header is not meant to be included by clients. This could be fixed by extending the client API with a function to access the controller's device. Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver") Signed-off-by: Laurent Pinchart Reviewed-by: Stefan Wahren Tested-by: Ivan T. Ivanov Link: https://lore.kernel.org/r/20240326195807.15163-3-laurent.pinchart@ideasonboard.com Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 2cee42c620f052f819a900fe5d40f4376848e3f2 Author: Guenter Roeck Date: Tue Apr 2 06:38:39 2024 -0700 mm/slub, kunit: Use inverted data to corrupt kmem cache [ Upstream commit b1080c667b3b2c8c38a7fa83ca5567124887abae ] Two failure patterns are seen randomly when running slub_kunit tests with CONFIG_SLAB_FREELIST_RANDOM and CONFIG_SLAB_FREELIST_HARDENED enabled. Pattern 1: # test_clobber_zone: pass:1 fail:0 skip:0 total:1 ok 1 test_clobber_zone # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72 Expected 3 == slab_errors, but slab_errors == 0 (0x0) # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:84 Expected 2 == slab_errors, but slab_errors == 0 (0x0) # test_next_pointer: pass:0 fail:1 skip:0 total:1 not ok 2 test_next_pointer In this case, test_next_pointer() overwrites p[s->offset], but the data at p[s->offset] is already 0x12. Pattern 2: ok 1 test_clobber_zone # test_next_pointer: EXPECTATION FAILED at lib/slub_kunit.c:72 Expected 3 == slab_errors, but slab_errors == 2 (0x2) # test_next_pointer: pass:0 fail:1 skip:0 total:1 not ok 2 test_next_pointer In this case, p[s->offset] has a value other than 0x12, but one of the expected failures is nevertheless missing. Invert data instead of writing a fixed value to corrupt the cache data structures to fix the problem. Fixes: 1f9f78b1b376 ("mm/slub, kunit: add a KUnit test for SLUB debugging functionality") Cc: Oliver Glitta Cc: Vlastimil Babka CC: Daniel Latypov Cc: Marco Elver Signed-off-by: Guenter Roeck Signed-off-by: Vlastimil Babka Signed-off-by: Sasha Levin commit 5e5669331d3340a2e0d076682fb8b10b629a2f05 Author: Krzysztof Kozlowski Date: Mon Nov 20 19:56:23 2023 +0100 firmware: qcom: qcm: fix unused qcom_scm_qseecom_allowlist [ Upstream commit e478c5fb6aa10af7b7edbff69bc8aef6fbb5f0ed ] For !OF builds, the qcom_scm_qseecom_allowlist is unused: drivers/firmware/qcom/qcom_scm.c:1652:34: error: ‘qcom_scm_qseecom_allowlist’ defined but not used [-Werror=unused-const-variable=] Fixes: 00b1248606ba ("firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202311191654.S4wlVUrz-lkp@intel.com/ Signed-off-by: Krzysztof Kozlowski Acked-by: Maximilian Luz Link: https://lore.kernel.org/r/20231120185623.338608-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3b7a40740f04e2f27114dfd6225c5e721dda9d57 Author: Aleksandr Mishin Date: Fri Mar 22 23:59:15 2024 +0300 crypto: bcm - Fix pointer arithmetic [ Upstream commit 2b3460cbf454c6b03d7429e9ffc4fe09322eb1a9 ] In spu2_dump_omd() value of ptr is increased by ciph_key_len instead of hash_iv_len which could lead to going beyond the buffer boundaries. Fix this bug by changing ciph_key_len to hash_iv_len. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Aleksandr Mishin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f4d748358af81f67f521a05701f4b8210974346c Author: Eric Sandeen Date: Fri Mar 1 16:33:11 2024 -0600 openpromfs: finish conversion to the new mount API [ Upstream commit 8f27829974b025d4df2e78894105d75e3bf349f0 ] The original mount API conversion inexplicably left out the change from ->remount_fs to ->reconfigure; do that now. Fixes: 7ab2fa7693c3 ("vfs: Convert openpromfs to use the new mount API") Signed-off-by: Eric Sandeen Link: https://lore.kernel.org/r/90b968aa-c979-420f-ba37-5acc3391b28f@redhat.com Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit d92c0e40d27be9c2c768de6461b7d1ef2ec105f4 Author: Eric Biggers Date: Mon Apr 22 14:10:41 2024 -0700 KEYS: asymmetric: Add missing dependencies of FIPS_SIGNATURE_SELFTEST commit 9d2fd8bdc12f403a5c35c971936a0e1d5cb5108e upstream. Since the signature self-test uses RSA and SHA-256, it must only be enabled when those algorithms are enabled. Otherwise it fails and panics the kernel on boot-up. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202404221528.51d75177-lkp@intel.com Fixes: 3cde3174eb91 ("certs: Add FIPS selftests") Cc: stable@vger.kernel.org Cc: Simo Sorce Cc: David Howells Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit a07f99247310202557a47c05acac361da4269f63 Author: Eric Biggers Date: Mon Apr 22 14:08:45 2024 -0700 KEYS: asymmetric: Add missing dependency on CRYPTO_SIG commit dcaa86b904ea3761e62c849957dd0904e126bf4a upstream. Make ASYMMETRIC_PUBLIC_KEY_SUBTYPE select CRYPTO_SIG to avoid build errors like the following, which were possible with CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y && CONFIG_CRYPTO_SIG=n: ld: vmlinux.o: in function `public_key_verify_signature': (.text+0x306280): undefined reference to `crypto_alloc_sig' ld: (.text+0x306300): undefined reference to `crypto_sig_set_pubkey' ld: (.text+0x306324): undefined reference to `crypto_sig_verify' ld: (.text+0x30636c): undefined reference to `crypto_sig_set_privkey' Fixes: 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 6b55e879e7bd023a03888fc6c8339edf82f576f4 Author: Takashi Iwai Date: Fri May 10 12:14:23 2024 +0200 ALSA: Fix deadlocks with kctl removals at disconnection commit 87988a534d8e12f2e6fc01fe63e6c1925dc5307c upstream. In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218816 Cc: Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20240510101424.6279-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit abb1ad69d98cf1ff25bb14fff0e7c3f66239e1cd Author: Takashi Iwai Date: Tue May 14 20:27:36 2024 +0200 ALSA: timer: Set lower bound of start tick time commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream. Currently ALSA timer doesn't have the lower limit of the start tick time, and it allows a very small size, e.g. 1 tick with 1ns resolution for hrtimer. Such a situation may lead to an unexpected RCU stall, where the callback repeatedly queuing the expire update, as reported by fuzzer. This patch introduces a sanity check of the timer start tick time, so that the system returns an error when a too small start size is set. As of this patch, the lower limit is hard-coded to 100us, which is small enough but can still work somehow. Reported-by: syzbot+43120c2af6ca2938cc38@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com Cc: Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6b8374ee2cabcf034faa34e69a855dc496a9ec12 Author: Takashi Iwai Date: Wed May 22 09:04:39 2024 +0200 ALSA: core: Fix NULL module pointer assignment at card init commit 39381fe7394e5eafac76e7e9367e7351138a29c1 upstream. The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. Fixes: 81033c6b584b ("ALSA: core: Warn on empty module") Reported-by: Xu Yang Closes: https://lore.kernel.org/r/20240520170349.2417900-1-xu.yang_2@nxp.com Cc: Signed-off-by: Takashi Iwai Tested-by: Xu Yang Link: https://lore.kernel.org/r/20240522070442.17786-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit ce3f185bef8673e433fc7691bc26e3a159ed9160 Author: Andy Chi Date: Thu May 23 14:18:31 2024 +0800 ALSA: hda/realtek: fix mute/micmute LEDs don't work for ProBook 440/460 G11. commit b3b6f125da2773cbc681316842afba63ca9869aa upstream. HP ProBook 440/460 G11 needs ALC236_FIXUP_HP_GPIO_LED quirk to make mic-mute/audio-mute working. Signed-off-by: Andy Chi Cc: Link: https://lore.kernel.org/r/20240523061832.607500-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 26ce87cea598215afda9977d6dce013cef323d13 Author: Nandor Kracser Date: Tue May 21 22:56:17 2024 +0900 ksmbd: ignore trailing slashes in share paths commit 405ee4097c4bc3e70556520aed5ba52a511c2266 upstream. Trailing slashes in share paths (like: /home/me/Share/) caused permission issues with shares for clients on iOS and on Android TV for me, but otherwise they work fine with plain old Samba. Cc: stable@vger.kernel.org Signed-off-by: Nandor Kracser Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit e0601d54cca46eb8416679576179b108caaa8707 Author: Namjae Jeon Date: Thu May 9 15:25:39 2024 +0900 ksmbd: avoid to send duplicate oplock break notifications commit c91ecba9e421e4f2c9219cf5042fa63a12025310 upstream. This patch fixes generic/011 when oplocks is enable. Avoid to send duplicate oplock break notifications like smb2 leases case. Fixes: 97c2ec64667b ("ksmbd: avoid to send duplicate lease break notifications") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0075eac9421ab8d1d0a8219bebfb96641d08a3a5 Author: Konstantin Komarov Date: Tue Apr 23 17:21:58 2024 +0300 fs/ntfs3: Break dir enumeration if directory contents error commit 302e9dca8428979c9c99f2dbb44dc1783f5011c3 upstream. If we somehow attempt to read beyond the directory size, an error is supposed to be returned. However, in some cases, read requests do not stop and instead enter into a loop. To avoid this, we set the position in the directory to the end. Signed-off-by: Konstantin Komarov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7113012712f3088b00e0ba5576093270c4463195 Author: Konstantin Komarov Date: Tue Apr 23 15:31:56 2024 +0300 fs/ntfs3: Fix case when index is reused during tree transformation commit 05afeeebcac850a016ec4fb1f681ceda11963562 upstream. In most cases when adding a cluster to the directory index, they are placed at the end, and in the bitmap, this cluster corresponds to the last bit. The new directory size is calculated as follows: data_size = (u64)(bit + 1) << indx->index_bits; In the case of reusing a non-final cluster from the index, data_size is calculated incorrectly, resulting in the directory size differing from the actual size. A check for cluster reuse has been added, and the size update is skipped. Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b66f0129f2046e8d9c084aca4e26ca1b51447fcf Author: Konstantin Komarov Date: Wed Apr 17 10:33:06 2024 +0300 fs/ntfs3: Taking DOS names into account during link counting commit 110b24eb1a749bea3440f3ca2ff890a26179050a upstream. When counting and checking hard links in an ntfs file record, struct MFT_REC { struct NTFS_RECORD_HEADER rhdr; // 'FILE' __le16 seq; // 0x10: Sequence number for this record. >> __le16 hard_links; // 0x12: The number of hard links to record. __le16 attr_off; // 0x14: Offset to attributes. ... the ntfs3 driver ignored short names (DOS names), causing the link count to be reduced by 1 and messages to be output to dmesg. For Windows, such a situation is a minor error, meaning chkdsk does not report errors on such a volume, and in the case of using the /f switch, it silently corrects them, reporting that no errors were found. This does not affect the consistency of the file system. Nevertheless, the behavior in the ntfs3 driver is incorrect and changes the content of the file system. This patch should fix that. PS: most likely, there has been a confusion of concepts MFT_REC::hard_links and inode::__i_nlink. Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 49213a1bab5f90ea6c9903dcf9bbddb7112934fa Author: Konstantin Komarov Date: Wed Apr 3 10:08:04 2024 +0300 fs/ntfs3: Remove max link count info display during driver init commit a8948b5450e7c65a3a34ebf4ccfcebc19335d4fb upstream. Removes the output of this purely informational message from the kernel buffer: "ntfs3: Max link count 4000" Signed-off-by: Konstantin Komarov Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c516db6ab9eabbedbc430b4f93b0d8728e9b427f Author: Ryusuke Konishi Date: Mon May 20 22:26:21 2024 +0900 nilfs2: fix potential hang in nilfs_detach_log_writer() commit eb85dace897c5986bc2f36b3c783c6abb8a4292e upstream. Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy(). Link: https://lkml.kernel.org/r/20240520132621.4054-4-konishi.ryusuke@gmail.com Signed-off-by: Ryusuke Konishi Reported-by: syzbot+e3973c409251e136fdd0@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e3973c409251e136fdd0 Tested-by: Ryusuke Konishi Cc: Cc: "Bai, Shuangpeng" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c61657b362393e5e2f61317913367f0b01e3e9e1 Author: Ryusuke Konishi Date: Mon May 20 22:26:20 2024 +0900 nilfs2: fix unexpected freezing of nilfs_segctor_sync() commit 936184eadd82906992ff1f5ab3aada70cce44cee upstream. A potential and reproducible race issue has been identified where nilfs_segctor_sync() would block even after the log writer thread writes a checkpoint, unless there is an interrupt or other trigger to resume log writing. This turned out to be because, depending on the execution timing of the log writer thread running in parallel, the log writer thread may skip responding to nilfs_segctor_sync(), which causes a call to schedule() waiting for completion within nilfs_segctor_sync() to lose the opportunity to wake up. The reason why waking up the task waiting in nilfs_segctor_sync() may be skipped is that updating the request generation issued using a shared sequence counter and adding an wait queue entry to the request wait queue to the log writer, are not done atomically. There is a possibility that log writing and request completion notification by nilfs_segctor_wakeup() may occur between the two operations, and in that case, the wait queue entry is not yet visible to nilfs_segctor_wakeup() and the wake-up of nilfs_segctor_sync() will be carried over until the next request occurs. Fix this issue by performing these two operations simultaneously within the lock section of sc_state_lock. Also, following the memory barrier guidelines for event waiting loops, move the call to set_current_state() in the same location into the event waiting loop to ensure that a memory barrier is inserted just before the event condition determination. Link: https://lkml.kernel.org/r/20240520132621.4054-3-konishi.ryusuke@gmail.com Fixes: 9ff05123e3bf ("nilfs2: segment constructor") Signed-off-by: Ryusuke Konishi Tested-by: Ryusuke Konishi Cc: Cc: "Bai, Shuangpeng" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 68e738be5c518fc3c4e9146b66f67c8fee0135fb Author: Ryusuke Konishi Date: Mon May 20 22:26:19 2024 +0900 nilfs2: fix use-after-free of timer for log writer thread commit f5d4e04634c9cf68bdf23de08ada0bb92e8befe7 upstream. Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. Link: https://lkml.kernel.org/r/20240520132621.4054-1-konishi.ryusuke@gmail.com Link: https://lkml.kernel.org/r/20240520132621.4054-2-konishi.ryusuke@gmail.com Fixes: fdce895ea5dd ("nilfs2: change sc_timer from a pointer to an embedded one in struct nilfs_sc_info") Signed-off-by: Ryusuke Konishi Reported-by: "Bai, Shuangpeng" Closes: https://groups.google.com/g/syzkaller/c/MK_LYqtt8ko/m/8rgdWeseAwAJ Tested-by: Ryusuke Konishi Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit dd46b51177b14a067033c28da5807f6bf2cdbc30 Author: Nuno Sa Date: Fri Apr 26 17:42:12 2024 +0200 dt-bindings: adc: axi-adc: add clocks property commit 19fb11d7220b8abc016aa254dc7e6d9f2d49b178 upstream. Add a required clock property as we can't access the device registers if the AXI bus clock is not properly enabled. Note this clock is a very fundamental one that is typically enabled pretty early during boot. Independently of that, we should really rely on it to be enabled. Reviewed-by: Krzysztof Kozlowski Fixes: 96553a44e96d ("dt-bindings: iio: adc: add bindings doc for AXI ADC driver") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20240426-ad9467-new-features-v2-3-6361fc3ba1cc@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ac2b86f2644e0c27d4e35c8e9845614505ca1eab Author: Jaegeuk Kim Date: Tue Apr 9 20:34:11 2024 +0000 f2fs: fix false alarm on invalid block address commit b864ddb57eb00c4ea1e6801c7b2f70f1db2a7f4b upstream. f2fs_ra_meta_pages can try to read ahead on invalid block address which is not the corruption case. Cc: # v6.9+ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218770 Fixes: 31f85ccc84b8 ("f2fs: unify the error handling of f2fs_is_valid_blkaddr") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 004e3d4321e05aa7e32d48f4a2151dfc8346f6a3 Author: Thorsten Blum Date: Fri May 10 13:30:55 2024 +0200 net: smc91x: Fix m68k kernel compilation for ColdFire CPU commit 5eefb477d21a26183bc3499aeefa991198315a2d upstream. Compiling the m68k kernel with support for the ColdFire CPU family fails with the following error: In file included from drivers/net/ethernet/smsc/smc91x.c:80: drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_reset’: drivers/net/ethernet/smsc/smc91x.h:160:40: error: implicit declaration of function ‘_swapw’; did you mean ‘swap’? [-Werror=implicit-function-declaration] 160 | #define SMC_outw(lp, v, a, r) writew(_swapw(v), (a) + (r)) | ^~~~~~ drivers/net/ethernet/smsc/smc91x.h:904:25: note: in expansion of macro ‘SMC_outw’ 904 | SMC_outw(lp, x, ioaddr, BANK_SELECT); \ | ^~~~~~~~ drivers/net/ethernet/smsc/smc91x.c:250:9: note: in expansion of macro ‘SMC_SELECT_BANK’ 250 | SMC_SELECT_BANK(lp, 2); | ^~~~~~~~~~~~~~~ cc1: some warnings being treated as errors The function _swapw() was removed in commit d97cf70af097 ("m68k: use asm-generic/io.h for non-MMU io access functions"), but is still used in drivers/net/ethernet/smsc/smc91x.h. Use ioread16be() and iowrite16be() to resolve the error. Cc: stable@vger.kernel.org Fixes: d97cf70af097 ("m68k: use asm-generic/io.h for non-MMU io access functions") Signed-off-by: Thorsten Blum Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20240510113054.186648-2-thorsten.blum@toblux.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7136e4a06def8da7bc31f4aa413833d9e1ee7939 Author: Herve Codina Date: Mon May 13 13:18:53 2024 +0200 net: lan966x: remove debugfs directory in probe() error path commit 99975ad644c7836414183fa7be4f883a4fb2bf64 upstream. A debugfs directory entry is create early during probe(). This entry is not removed on error path leading to some "already present" issues in case of EPROBE_DEFER. Create this entry later in the probe() code to avoid the need to change many 'return' in 'goto' and add the removal in the already present error path. Fixes: 942814840127 ("net: lan966x: Add VCAP debugFS support") Cc: Signed-off-by: Herve Codina Reviewed-by: Andrew Lunn Reviewed-by: Horatiu Vultur Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1e1d5bd7f4682e6925dd960aba2a1aa1d93da53a Author: Romain Gantois Date: Tue May 21 14:44:11 2024 +0200 net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe() commit b31c7e78086127a7fcaa761e8d336ee855a920c6 upstream. In the prueth_probe() function, if one of the calls to emac_phy_connect() fails due to of_phy_connect() returning NULL, then the subsequent call to phy_attached_info() will dereference a NULL pointer. Check the return code of emac_phy_connect and fail cleanly if there is an error. Fixes: 128d5874c082 ("net: ti: icssg-prueth: Add ICSSG ethernet driver") Cc: stable@vger.kernel.org Signed-off-by: Romain Gantois Reviewed-by: Simon Horman Reviewed-by: MD Danish Anwar Link: https://lore.kernel.org/r/20240521-icssg-prueth-fix-v1-1-b4b17b1433e9@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 4e6f225aefeb712cdb870176b6621f02cf235b8c Author: Brennan Xavier McManus Date: Tue Jan 9 18:44:02 2024 -0500 tools/nolibc/stdlib: fix memory error in realloc() commit 791f4641142e2aced85de082e5783b4fb0b977c2 upstream. Pass user_p_len to memcpy() instead of heap->len to prevent realloc() from copying an extra sizeof(heap) bytes from beyond the allocated region. Signed-off-by: Brennan Xavier McManus Cc: stable@vger.kernel.org Reviewed-by: Ammar Faizi Fixes: 0e0ff638400be8f497a35b51a4751fd823f6bd6a ("tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()`") Signed-off-by: Willy Tarreau Signed-off-by: Thomas Weißschuh Signed-off-by: Greg Kroah-Hartman commit 5fdf04b0b717accec7d622a43904a287c72c7f5b Author: Shuah Khan Date: Wed Apr 3 19:10:09 2024 -0600 tools/latency-collector: Fix -Wformat-security compile warns commit df73757cf8f66fa54c4721c53b0916af3c4d9818 upstream. Fix the following -Wformat-security compile warnings adding missing format arguments: latency-collector.c: In function ‘show_available’: latency-collector.c:938:17: warning: format not a string literal and no format arguments [-Wformat-security] 938 | warnx(no_tracer_msg); | ^~~~~ latency-collector.c:943:17: warning: format not a string literal and no format arguments [-Wformat-security] 943 | warnx(no_latency_tr_msg); | ^~~~~ latency-collector.c: In function ‘find_default_tracer’: latency-collector.c:986:25: warning: format not a string literal and no format arguments [-Wformat-security] 986 | errx(EXIT_FAILURE, no_tracer_msg); | ^~~~ latency-collector.c: In function ‘scan_arguments’: latency-collector.c:1881:33: warning: format not a string literal and no format arguments [-Wformat-security] 1881 | errx(EXIT_FAILURE, no_tracer_msg); | ^~~~ Link: https://lore.kernel.org/linux-trace-kernel/20240404011009.32945-1-skhan@linuxfoundation.org Cc: stable@vger.kernel.org Fixes: e23db805da2df ("tracing/tools: Add the latency-collector to tools directory") Signed-off-by: Shuah Khan Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 825030a2170ffacba7286ebaefa5955b7fdd61ba Author: Souradeep Chakrabarti Date: Sun May 19 23:05:04 2024 -0700 net: mana: Fix the extra HZ in mana_hwc_send_request commit 9c91c7fadb1771dcc2815c5271d14566366d05c5 upstream. Commit 62c1bff593b7 added an extra HZ along with msecs_to_jiffies. This patch fixes that. Cc: stable@vger.kernel.org Fixes: 62c1bff593b7 ("net: mana: Configure hwc timeout from hardware") Signed-off-by: Souradeep Chakrabarti Reviewed-by: Brett Creeley Reviewed-by: Dexuan Cui Link: https://lore.kernel.org/r/1716185104-31658-1-git-send-email-schakrabarti@linux.microsoft.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 79b52013429a42b8efdb0cda8bb0041386abab87 Author: Petr Pavlu Date: Fri May 17 15:40:08 2024 +0200 ring-buffer: Fix a race between readers and resize checks commit c2274b908db05529980ec056359fae916939fdaa upstream. The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer. The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing: [ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] [ 190.272414] ---[ end trace 0000000000000000 ]--- Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue. The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page(): ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) /* inserted delay loop */ __asm__ __volatile__ ("" : : : "memory"); rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list; .. and then run the following commands on the target system: echo 1 > /sys/kernel/tracing/events/sched/sched_switch/enable while true; do echo 16 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1 echo 8 > /sys/kernel/tracing/buffer_size_kb; sleep 0.1 done & while true; do for i in /sys/kernel/tracing/per_cpu/*; do timeout 0.1 cat $i/trace_pipe; sleep 0.2 done done To fix the problem, make sure ring_buffer_resize() doesn't invoke rb_check_pages() concurrently with a reader operating on the same ring_buffer_per_cpu by taking its cpu_buffer->reader_lock. Link: https://lore.kernel.org/linux-trace-kernel/20240517134008.24529-3-petr.pavlu@suse.com Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 659f451ff213 ("ring-buffer: Add integrity check at end of iter read") Signed-off-by: Petr Pavlu [ Fixed whitespace ] Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 54e7a0d111240c92c0f02ceba6eb8f26bf6d6479 Author: Ken Milmore Date: Tue May 21 23:45:50 2024 +0100 r8169: Fix possible ring buffer corruption on fragmented Tx packets. commit c71e3a5cffd5309d7f84444df03d5b72600cc417 upstream. An issue was found on the RTL8125b when transmitting small fragmented packets, whereby invalid entries were inserted into the transmit ring buffer, subsequently leading to calls to dma_unmap_single() with a null address. This was caused by rtl8169_start_xmit() not noticing changes to nr_frags which may occur when small packets are padded (to work around hardware quirks) in rtl8169_tso_csum_v2(). To fix this, postpone inspecting nr_frags until after any padding has been applied. Fixes: 9020845fb5d6 ("r8169: improve rtl8169_start_xmit") Cc: stable@vger.kernel.org Signed-off-by: Ken Milmore Reviewed-by: Heiner Kallweit Link: https://lore.kernel.org/r/27ead18b-c23d-4f49-a020-1fc482c5ac95@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 00f31813567db6016c5d6bb89deeb05aa2cee2a9 Author: Heiner Kallweit Date: Wed May 15 08:18:01 2024 +0200 Revert "r8169: don't try to disable interrupts if NAPI is, scheduled already" commit eabb8a9be1e4a12f3bf37ceb7411083e3775672d upstream. This reverts commit 7274c4147afbf46f45b8501edbdad6da8cd013b9. Ken reported that RTL8125b can lock up if gro_flush_timeout has the default value of 20000 and napi_defer_hard_irqs is set to 0. In this scenario device interrupts aren't disabled, what seems to trigger some silicon bug under heavy load. I was able to reproduce this behavior on RTL8168h. Fix this by reverting 7274c4147afb. Fixes: 7274c4147afb ("r8169: don't try to disable interrupts if NAPI is scheduled already") Cc: stable@vger.kernel.org Reported-by: Ken Milmore Signed-off-by: Heiner Kallweit Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/9b5b6f4c-4f54-4b90-b0b3-8d8023c2e780@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit f812f6dfcd8dd7c0472522d3c1667327cb9bc041 Author: Jens Axboe Date: Tue May 21 12:31:12 2024 -0600 io_uring/sqpoll: ensure that normal task_work is also run timely commit d13ddd9c893f0e8498526bf88c6b5fad01f0edd8 upstream. With the move to private task_work, SQPOLL neglected to also run the normal task_work, if any is pending. This will eventually get run, but we should run it with the private task_work to ensure that things like a final fput() is processed in a timely fashion. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/313824bc-799d-414f-96b7-e6de57c7e21d@gmail.com/ Reported-by: Andrew Udvare Fixes: af5d68f8892f ("io_uring/sqpoll: manage task_work privately") Tested-by: Christian Heusel Tested-by: Andrew Udvare Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 462043fb66b0d8687ae2c60630aae1f659e52eb1 Author: Ming Lei Date: Fri May 10 11:50:27 2024 +0800 io_uring: fail NOP if non-zero op flags is passed in commit 3d8f874bd620ce03f75a5512847586828ab86544 upstream. The NOP op flags should have been checked from beginning like any other opcode, otherwise NOP may not be extended with the op flags. Given both liburing and Rust io-uring crate always zeros SQE op flags, just ignore users which play raw NOP uring interface without zeroing SQE, because NOP is just for test purpose. Then we can save one NOP2 opcode. Suggested-by: Jens Axboe Fixes: 2b188cc1bb85 ("Add io_uring IO interface") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20240510035031.78874-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 562b4bbe724d4dbe5408f16515496de26a99ec75 Author: Dmitry Torokhov Date: Mon Apr 29 14:50:41 2024 -0700 Input: try trimming too long modalias strings commit 0774d19038c496f0c3602fb505c43e1b2d8eed85 upstream. If an input device declares too many capability bits then modalias string for such device may become too long and not fit into uevent buffer, resulting in failure of sending said uevent. This, in turn, may prevent userspace from recognizing existence of such devices. This is typically not a concern for real hardware devices as they have limited number of keys, but happen with synthetic devices such as ones created by xen-kbdfront driver, which creates devices as being capable of delivering all possible keys, since it doesn't know what keys the backend may produce. To deal with such devices input core will attempt to trim key data, in the hope that the rest of modalias string will fit in the given buffer. When trimming key data it will indicate that it is not complete by placing "+," sign, resulting in conversions like this: old: k71,72,73,74,78,7A,7B,7C,7D,8E,9E,A4,AD,E0,E1,E4,F8,174, new: k71,72,73,74,78,7A,7B,7C,+, This should allow existing udev rules continue to work with existing devices, and will also allow writing more complex rules that would recognize trimmed modalias and check input device characteristics by other means (for example by parsing KEY= data in uevent or parsing input device sysfs attributes). Note that the driver core may try adding more uevent environment variables once input core is done adding its own, so when forming modalias we can not use the entire available buffer, so we reduce it by somewhat an arbitrary amount (96 bytes). Reported-by: Jason Andryuk Reviewed-by: Peter Hutterer Tested-by: Jason Andryuk Link: https://lore.kernel.org/r/ZjAWMQCJdrxZkvkB@google.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1f97ccd2c32ad8f0322e4fe3a291a61e509b3e5e Author: Pin-yen Lin Date: Wed Apr 24 20:58:08 2024 +0800 serial: 8520_mtk: Set RTS on shutdown for Rx in-band wakeup commit 4244f830a56058ee0670d80e7ac9fd7c982eb480 upstream. When Rx in-band wakeup is enabled, set RTS to true in mtk8250_shutdown() so the connected device can still send message and trigger IRQ when the system is suspended. Fixes: 18c9d4a3c249 ("serial: When UART is suspended, set RTS to false") Cc: stable Signed-off-by: Pin-yen Lin Link: https://lore.kernel.org/r/20240424130619.2924456-1-treapking@chromium.org Signed-off-by: Greg Kroah-Hartman commit f98bc68a3244beacf8092977782462429638d6eb Author: Doug Berger Date: Wed Apr 24 15:25:59 2024 -0700 serial: 8250_bcm7271: use default_mux_rate if possible commit 614a19b89ca43449196a8af1afac7d55c6781687 upstream. There is a scenario when resuming from some power saving states with no_console_suspend where console output can be generated before the 8250_bcm7271 driver gets the opportunity to restore the baud_mux_clk frequency. Since the baud_mux_clk is at its default frequency at this time the output can be garbled until the driver gets the opportunity to resume. Since this is only an issue with console use of the serial port during that window and the console isn't likely to use baud rates that require alternate baud_mux_clk frequencies, allow the driver to select the default_mux_rate if it is accurate enough. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Cc: stable@vger.kernel.org Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20240424222559.1844045-1-opendmb@gmail.com Signed-off-by: Greg Kroah-Hartman commit 671202e86739557e5612c132883c0246e02655cc Author: Hugo Villeneuve Date: Tue Apr 30 16:04:30 2024 -0400 serial: sc16is7xx: fix bug in sc16is7xx_set_baud() when using prescaler commit 8492bd91aa055907c67ef04f2b56f6dadd1f44bf upstream. When using a high speed clock with a low baud rate, the 4x prescaler is automatically selected if required. In that case, sc16is7xx_set_baud() properly configures the chip registers, but returns an incorrect baud rate by not taking into account the prescaler value. This incorrect baud rate is then fed to uart_update_timeout(). For example, with an input clock of 80MHz, and a selected baud rate of 50, sc16is7xx_set_baud() will return 200 instead of 50. Fix this by first changing the prescaler variable to hold the selected prescaler value instead of the MCR bitfield. Then properly take into account the selected prescaler value in the return value computation. Also add better documentation about the divisor value computation. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20240430200431.4102923-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman commit d52c04474feac8e305814a5228e622afe481b2ef Author: Dan Carpenter Date: Mon Apr 15 14:02:23 2024 +0300 speakup: Fix sizeof() vs ARRAY_SIZE() bug commit 008ab3c53bc4f0b2f20013c8f6c204a3203d0b8b upstream. The "buf" pointer is an array of u16 values. This code should be using ARRAY_SIZE() (which is 256) instead of sizeof() (which is 512), otherwise it can the still got out of bounds. Fixes: c8d2f34ea96e ("speakup: Avoid crash on very long word") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Reviewed-by: Samuel Thibault Link: https://lore.kernel.org/r/d16f67d2-fd0a-4d45-adac-75ddd11001aa@moroto.mountain Signed-off-by: Greg Kroah-Hartman commit fa5703bfa1e6002a1541cba93df7e312a2cf7ec0 Author: Daniel Starke Date: Wed Apr 24 07:48:42 2024 +0200 tty: n_gsm: fix missing receive state reset after mode switch commit 70d7f1427afcf7fa2d21cb5a04c6f3555d5b9357 upstream. The current implementation uses either gsm0_receive() or gsm1_receive() depending on whether the user configured the mux in basic or advanced option mode. Both functions share some state values over the same logical elements of the frame. However, both frame types differ in their nature. gsm0_receive() uses non-transparency framing, whereas gsm1_receive() uses transparency mechanism. Switching between both modes leaves the receive function in an undefined state when done during frame reception. Fix this by splitting both states. Add gsm0_receive_state_check_and_fix() and gsm1_receive_state_check_and_fix() to ensure that gsm->state is reset after a change of gsm->receive. Note that gsm->state is only accessed in: - gsm0_receive() - gsm1_receive() - gsm_error() Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20240424054842.7741-2-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit b890d45aaf02b564e6cae2d2a590f9649330857d Author: Daniel Starke Date: Wed Apr 24 07:48:41 2024 +0200 tty: n_gsm: fix possible out-of-bounds in gsm0_receive() commit 47388e807f85948eefc403a8a5fdc5b406a65d5a upstream. Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. Reported-by: j51569436@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218708 Tested-by: j51569436@gmail.com Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20240424054842.7741-1-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman commit 1eb4dfc3523dbd88b74256c27719d105eca4058a Author: Will Deacon Date: Wed May 22 11:53:05 2024 +0100 Reapply "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD" commit f481bb32d60e45fb3d19ea68ce79c5629f3fc3a0 upstream. This reverts commit b8995a18417088bb53f87c49d200ec72a9dd4ec1. Ard managed to reproduce the dm-crypt corruption problem and got to the bottom of it, so re-apply the problematic patch in preparation for fixing things properly. Cc: stable@vger.kernel.org Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 25b90cd122d546823da90b916f7c3289dfe83a99 Author: Ard Biesheuvel Date: Wed May 22 11:13:36 2024 +0200 arm64/fpsimd: Avoid erroneous elide of user state reload commit e92bee9f861b466c676f0200be3e46af7bc4ac6b upstream. TIF_FOREIGN_FPSTATE is a 'convenience' flag that should reflect whether the current CPU holds the most recent user mode FP/SIMD state of the current task. It combines two conditions: - whether the current CPU's FP/SIMD state belongs to the task; - whether that state is the most recent associated with the task (as a task may have executed on other CPUs as well). When a task is scheduled in and TIF_KERNEL_FPSTATE is set, it means the task was in a kernel mode NEON section when it was scheduled out, and so the kernel mode FP/SIMD state is restored. Since this implies that the current CPU is *not* holding the most recent user mode FP/SIMD state of the current task, the TIF_FOREIGN_FPSTATE flag is set too, so that the user mode FP/SIMD state is reloaded from memory when returning to userland. However, the task may be scheduled out after completing the kernel mode NEON section, but before returning to userland. When this happens, the TIF_FOREIGN_FPSTATE flag will not be preserved, but will be set as usual the next time the task is scheduled in, and will be based on the above conditions. This means that, rather than setting TIF_FOREIGN_FPSTATE when scheduling in a task with TIF_KERNEL_FPSTATE set, the underlying state should be updated so that TIF_FOREIGN_FPSTATE will assume the expected value as a result. So instead, call fpsimd_flush_cpu_state(), which takes care of this. Closes: https://lore.kernel.org/all/cb8822182231850108fa43e0446a4c7f@kernel.org Reported-by: Johannes Nixdorf Fixes: aefbab8e77eb ("arm64: fpsimd: Preserve/restore kernel mode NEON at context switch") Cc: Mark Brown Cc: Dave Martin Cc: Janne Grunau Cc: stable@vger.kernel.org Signed-off-by: Ard Biesheuvel Tested-by: Janne Grunau Tested-by: Johannes Nixdorf Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20240522091335.335346-2-ardb+git@google.com Signed-off-by: Will Deacon Cc: Florian Klink Signed-off-by: Greg Kroah-Hartman commit d73469ac250925ea01d374eda61224ea88a7d89b Author: Will Deacon Date: Fri May 17 12:55:55 2024 +0100 Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD" commit b8995a18417088bb53f87c49d200ec72a9dd4ec1 upstream. This reverts commit 2632e25217696712681dd1f3ecc0d71624ea3b23. Johannes (and others) report data corruption with dm-crypt on Apple M1 which has been bisected to this change. Revert the offending commit while we figure out what's going on. Cc: stable@vger.kernel.org Reported-by: Johannes Nixdorf Link: https://lore.kernel.org/all/D1B7GPIR9K1E.5JFV37G0YTIF@shadowice.org/ Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 31310e373f4c8c74e029d4326b283e757edabc0b Author: Zheng Yejian Date: Fri May 10 03:28:59 2024 +0800 ftrace: Fix possible use-after-free issue in ftrace_location() commit e60b613df8b6253def41215402f72986fee3fc8d upstream. KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). Link: https://lore.kernel.org/linux-trace-kernel/20240509192859.1273558-1-zhengyejian1@huawei.com Cc: stable@vger.kernel.org Cc: Cc: Cc: Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization") Suggested-by: Steven Rostedt Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit da10fc52ca831eac73d2d20871af0f9b58dd504a Author: Masami Hiramatsu (Google) Date: Sat May 4 09:33:19 2024 +0900 selftests/ftrace: Fix checkbashisms errors commit b07b7e2fd51840c7dfffa98c4344ab36195bb8dc upstream. Fix the below checkbashisms errors. Because of these errors, these tests will fail on dash shell. possible bashism in test.d/kprobe/kretprobe_entry_arg.tc line 14 ('function' is useless): function streq() { possible bashism in test.d/dynevent/fprobe_entry_arg.tc line 14 ('function' is useless): function streq() { Fixes: f6e2253a617c ("selftests/ftrace: Add test cases for entry args at function exit") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 492f73bcb4249eabd6d57de879912f58d7df15ce Author: Masami Hiramatsu (Google) Date: Sat May 4 09:33:10 2024 +0900 selftests/ftrace: Fix BTFARG testcase to check fprobe is enabled correctly commit 2fd3ef1b9265eda7f53b9506f1ebfb67eb6435a2 upstream. Since the dynevent/add_remove_btfarg.tc test case forgets to ensure that fprobe is enabled for some structure field access tests which uses the fprobe, it fails if CONFIG_FPROBE=n or CONFIG_FPROBE_EVENTS=n. Fixes it to ensure the fprobe events are supported. Fixes: d892d3d3d885 ("selftests/ftrace: Add BTF fields access testcases") Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman commit 4c2a81f196eadf5681982583f0bffecbb4a7e59d Author: Daniel J Blueman Date: Fri Apr 19 16:51:46 2024 +0800 x86/tsc: Trust initial offset in architectural TSC-adjust MSRs commit 455f9075f14484f358b3c1d6845b4a438de198a7 upstream. When the BIOS configures the architectural TSC-adjust MSRs on secondary sockets to correct a constant inter-chassis offset, after Linux brings the cores online, the TSC sync check later resets the core-local MSR to 0, triggering HPET fallback and leading to performance loss. Fix this by unconditionally using the initial adjust values read from the MSRs. Trusting the initial offsets in this architectural mechanism is a better approach than special-casing workarounds for specific platforms. Signed-off-by: Daniel J Blueman Signed-off-by: Thomas Gleixner Reviewed-by: Steffen Persvold Reviewed-by: James Cleverdon Reviewed-by: Dimitri Sivanich Reviewed-by: Prarit Bhargava Link: https://lore.kernel.org/r/20240419085146.175665-1-daniel@quora.org Signed-off-by: Greg Kroah-Hartman