commit f6d41443f54856ceece0d5b584f47f681513bde4 Author: Greg Kroah-Hartman Date: Thu Dec 5 13:54:34 2024 +0100 Linux 6.11.11 Link: https://lore.kernel.org/r/20241203143955.605130076@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Miguel Ojeda Tested-by: kernelci.org bot Signed-off-by: Greg Kroah-Hartman commit 0aa57396ae503de8b22e7b2eb4ded50c4086c554 Author: Ming Lei Date: Thu Oct 31 21:37:20 2024 +0800 block: don't verify IO lock for freeze/unfreeze in elevator_init_mq() commit 357e1b7f730bd85a383e7afa75a3caba329c5707 upstream. elevator_init_mq() is only called at the entry of add_disk_fwnode() when disk IO isn't allowed yet. So not verify io lock(q->io_lockdep_map) for freeze & unfreeze in elevator_init_mq(). Reported-by: Marek Szyprowski Reported-by: Lai Yi Fixes: f1be1788a32e ("block: model freeze & enter queue as lock for supporting lockdep") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241031133723.303835-5-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6655172e54f87af43a1cc0612c6c860d62e8e72c Author: Ming Lei Date: Thu Oct 31 21:37:19 2024 +0800 block: always verify unfreeze lock on the owner task commit 6a78699838a0ddeed3620ddf50c1521f1fe1e811 upstream. commit f1be1788a32e ("block: model freeze & enter queue as lock for supporting lockdep") tries to apply lockdep for verifying freeze & unfreeze. However, the verification is only done the outmost freeze and unfreeze. This way is actually not correct because q->mq_freeze_depth still may drop to zero on other task instead of the freeze owner task. Fix this issue by always verifying the last unfreeze lock on the owner task context, and make sure both the outmost freeze & unfreeze are verified in the current task. Fixes: f1be1788a32e ("block: model freeze & enter queue as lock for supporting lockdep") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241031133723.303835-4-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 54baa8fb084291db648946ba97228315aaa6fafe Author: Patryk Wlazlyn Date: Wed Nov 13 15:48:22 2024 +0100 tools/power turbostat: Fix child's argument forwarding [ Upstream commit 1da0daf746342dfdc114e4dc8fbf3ece28666d4f ] Add '+' to optstring when early scanning for --no-msr and --no-perf. It causes option processing to stop as soon as a nonoption argument is encountered, effectively skipping child's arguments. Fixes: 3e4048466c39 ("tools/power turbostat: Add --no-msr option") Signed-off-by: Patryk Wlazlyn Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 2409cf42bce57992adc1791ccecf45fc812d465e Author: Zhang Rui Date: Tue Aug 27 13:07:51 2024 +0800 tools/power turbostat: Fix trailing '\n' parsing [ Upstream commit fed8511cc8996989178823052dc0200643e1389a ] parse_cpu_string() parses the string input either from command line or from /sys/fs/cgroup/cpuset.cpus.effective to get a list of CPUs that turbostat can run with. The cpu string returned by /sys/fs/cgroup/cpuset.cpus.effective contains a trailing '\n', but strtoul() fails to treat this as an error. That says, for the code below val = ("\n", NULL, 10); val returns 0, and errno is also not set. As a result, CPU0 is erroneously considered as allowed CPU and this causes failures when turbostat tries to run on CPU0. get_counters: Could not migrate to CPU 0 ... turbostat: re-initialized with num_cpus 8, allowed_cpus 5 get_counters: Could not migrate to CPU 0 Add a check to return immediately if '\n' or '\0' is detected. Fixes: 8c3dd2c9e542 ("tools/power/turbostat: Abstrct function for parsing cpu string") Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Sasha Levin commit 6ba6e19912570b2ad68298be0be1dc779014a303 Author: Dan Carpenter Date: Wed Oct 23 11:41:59 2024 +0300 sh: intc: Fix use-after-free bug in register_intc_controller() [ Upstream commit 63e72e551942642c48456a4134975136cdcb9b3c ] In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let's only add it to the list after everything has succeeded. Fixes: 2dcec7a988a1 ("sh: intc: set_irq_wake() support") Signed-off-by: Dan Carpenter Reviewed-by: John Paul Adrian Glaubitz Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sasha Levin commit 2d2d392af544cd5b0b46ef022517039e43079445 Author: Zhang Xianwei Date: Thu Nov 28 17:00:56 2024 +0800 brd: decrease the number of allocated pages which discarded [ Upstream commit 82734209bedd65a8b508844bab652b464379bfdd ] The number of allocated pages which discarded will not decrease. Fix it. Fixes: 9ead7efc6f3f ("brd: implement discard support") Signed-off-by: Zhang Xianwei Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241128170056565nPKSz2vsP8K8X2uk2iaDG@zte.com.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit dcaa738afde55085ac6056252e319479cf23cde2 Author: Yu Kuai Date: Fri Nov 29 17:15:09 2024 +0800 block, bfq: fix bfqq uaf in bfq_limit_depth() [ Upstream commit e8b8344de3980709080d86c157d24e7de07d70ad ] Set new allocated bfqq to bic or remove freed bfqq from bic are both protected by bfqd->lock, however bfq_limit_depth() is deferencing bfqq from bic without the lock, this can lead to UAF if the io_context is shared by multiple tasks. For example, test bfq with io_uring can trigger following UAF in v6.6: ================================================================== BUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50 Call Trace: dump_stack_lvl+0x47/0x80 print_address_description.constprop.0+0x66/0x300 print_report+0x3e/0x70 kasan_report+0xb4/0xf0 bfqq_group+0x15/0x50 bfqq_request_over_limit+0x130/0x9a0 bfq_limit_depth+0x1b5/0x480 __blk_mq_alloc_requests+0x2b5/0xa00 blk_mq_get_new_requests+0x11d/0x1d0 blk_mq_submit_bio+0x286/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __block_write_full_folio+0x3d0/0x640 writepage_cb+0x3b/0xc0 write_cache_pages+0x254/0x6c0 write_cache_pages+0x254/0x6c0 do_writepages+0x192/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork_asm+0x1b/0x30 Allocated by task 808602: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x83/0x90 kmem_cache_alloc_node+0x1b1/0x6d0 bfq_get_queue+0x138/0xfa0 bfq_get_bfqq_handle_split+0xe3/0x2c0 bfq_init_rq+0x196/0xbb0 bfq_insert_request.isra.0+0xb5/0x480 bfq_insert_requests+0x156/0x180 blk_mq_insert_request+0x15d/0x440 blk_mq_submit_bio+0x8a4/0xb00 submit_bio_noacct_nocheck+0x331/0x400 __blkdev_direct_IO_async+0x2dd/0x330 blkdev_write_iter+0x39a/0x450 io_write+0x22a/0x840 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Freed by task 808589: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 __kasan_slab_free+0x126/0x1b0 kmem_cache_free+0x10c/0x750 bfq_put_queue+0x2dd/0x770 __bfq_insert_request.isra.0+0x155/0x7a0 bfq_insert_request.isra.0+0x122/0x480 bfq_insert_requests+0x156/0x180 blk_mq_dispatch_plug_list+0x528/0x7e0 blk_mq_flush_plug_list.part.0+0xe5/0x590 __blk_flush_plug+0x3b/0x90 blk_finish_plug+0x40/0x60 do_writepages+0x19d/0x310 filemap_fdatawrite_wbc+0x95/0xc0 __filemap_fdatawrite_range+0x99/0xd0 filemap_write_and_wait_range.part.0+0x4d/0xa0 blkdev_read_iter+0xef/0x1e0 io_read+0x1b6/0x8a0 io_issue_sqe+0x87/0x300 io_wq_submit_work+0xeb/0x390 io_worker_handle_work+0x24d/0x550 io_wq_worker+0x27f/0x6c0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x1b/0x30 Fix the problem by protecting bic_to_bfqq() with bfqd->lock. CC: Jan Kara Fixes: 76f1df88bbc2 ("bfq: Limit number of requests consumed by each cgroup") Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20241129091509.2227136-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f6a1bb6de4548575400352a9eb1b8be1f244b91f Author: Benjamin Coddington Date: Fri Nov 22 10:11:12 2024 -0500 nfs/blocklayout: Limit repeat device registration on failure [ Upstream commit 614733f9441ed53bb442d4734112ec1e24bd6da7 ] Every pNFS SCSI IO wants to do LAYOUTGET, then within the layout find the device which can drive GETDEVINFO, then finally may need to prep the device with a reservation. This slow work makes a mess of IO latencies if one of the later steps is going to fail for awhile. If we're unable to register a SCSI device, ensure we mark the device as unavailable so that it will timeout and be re-added via GETDEVINFO. This avoids repeated doomed attempts to register a device in the IO path. Add some clarifying comments as well. Fixes: d869da91cccb ("nfs/blocklayout: Fix premature PR key unregistration") Signed-off-by: Benjamin Coddington Reviewed-by: Christoph Hellwig Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 3402704a424f34bbcca7f4a4503859357f422217 Author: Benjamin Coddington Date: Fri Nov 22 10:11:11 2024 -0500 nfs/blocklayout: Don't attempt unregister for invalid block device [ Upstream commit 3a4ce14d9a6b868e0787e4582420b721c04ee41e ] Since commit d869da91cccb ("nfs/blocklayout: Fix premature PR key unregistration") an unmount of a pNFS SCSI layout-enabled NFS may dereference a NULL block_device in: bl_unregister_scsi+0x16/0xe0 [blocklayoutdriver] bl_free_device+0x70/0x80 [blocklayoutdriver] bl_free_deviceid_node+0x12/0x30 [blocklayoutdriver] nfs4_put_deviceid_node+0x60/0xc0 [nfsv4] nfs4_deviceid_purge_client+0x132/0x190 [nfsv4] unset_pnfs_layoutdriver+0x59/0x60 [nfsv4] nfs4_destroy_server+0x36/0x70 [nfsv4] nfs_free_server+0x23/0xe0 [nfs] deactivate_locked_super+0x30/0xb0 cleanup_mnt+0xba/0x150 task_work_run+0x59/0x90 syscall_exit_to_user_mode+0x217/0x220 do_syscall_64+0x8e/0x160 This happens because even though we were able to create the nfs4_deviceid_node, the lookup for the device was unable to attach the block device to the pnfs_block_dev. If we never found a block device to register, we can avoid this case with the PNFS_BDEV_REGISTERED flag. Move the deref behind the test for the flag. Fixes: d869da91cccb ("nfs/blocklayout: Fix premature PR key unregistration") Signed-off-by: Benjamin Coddington Reviewed-by: Christoph Hellwig Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 694ccb05b79ee5f5a9f14c2f80d2635d3bb8bdc3 Author: Liu Jian Date: Tue Nov 12 21:54:34 2024 +0800 sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket [ Upstream commit 3f23f96528e8fcf8619895c4c916c52653892ec1 ] BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Reproduction script: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 The reason here is that the tcp socket in netns_1 (nfs side) has been shutdown and closed (done in xs_destroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns_1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems. To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport. Fixes: 26abe14379f8 ("net: Modify sk_alloc to not reference count the netns of kernel sockets.") Signed-off-by: Liu Jian Acked-by: Jeff Layton Reviewed-by: Kuniyuki Iwashima Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f1c4c4f9c9ba2e210f8a64542b0b9701ef82a3f5 Author: Benjamin Coddington Date: Fri Nov 15 08:59:36 2024 -0500 SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT [ Upstream commit d7bdd849ef1b681da03ac05ca0957b2cbe2d24b6 ] We've noticed a situation where an unstable TCP connection can cause the TLS handshake to timeout waiting for userspace to complete it. When this happens, we don't want to return from xs_tls_handshake_sync() with zero, as this will cause the upper xprt to be set CONNECTED, and subsequent attempts to transmit will be returned with -EPIPE. The sunrpc machine does not recover from this situation and will spin attempting to transmit. The return value of tls_handshake_cancel() can be used to detect a race with completion: * tls_handshake_cancel - cancel a pending handshake * Return values: * %true - Uncompleted handshake request was canceled * %false - Handshake request already completed or not found If true, we do not want the upper xprt to be connected, so return -ETIMEDOUT. If false, its possible the handshake request was lost and that may be the reason for our timeout. Again we do not want the upper xprt to be connected, so return -ETIMEDOUT. Ensure that we alway return an error from xs_tls_handshake_sync() if we call tls_handshake_cancel(). Signed-off-by: Benjamin Coddington Reviewed-by: Chuck Lever Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 638a8fa5a7e641f9401346c57e236f02379a0c40 Author: Liu Jian Date: Fri Nov 15 17:38:04 2024 +0800 sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport [ Upstream commit 4db9ad82a6c823094da27de4825af693a3475d51 ] Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. Fixes: 7196dbb02ea0 ("SUNRPC: Allow changing of the TCP timeout parameters on the fly") Signed-off-by: Li Lingfeng Signed-off-by: Liu Jian Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f25bddb3b7c0ebb0526b7062d54b5f8a05cd0c3f Author: Li Lingfeng Date: Thu Nov 14 12:53:03 2024 +0800 nfs: ignore SB_RDONLY when mounting nfs [ Upstream commit 52cb7f8f177878b4f22397b9c4d2c8f743766be3 ] When exporting only one file system with fsid=0 on the server side, the client alternately uses the ro/rw mount options to perform the mount operation, and a new vfsmount is generated each time. It can be reproduced as follows: [root@localhost ~]# mount /dev/sda /mnt2 [root@localhost ~]# echo "/mnt2 *(rw,no_root_squash,fsid=0)" >/etc/exports [root@localhost ~]# systemctl restart nfs-server [root@localhost ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa [root@localhost ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa [root@localhost ~]# mount -t nfs -o ro,vers=4 127.0.0.1:/ /mnt/sdaa [root@localhost ~]# mount -t nfs -o rw,vers=4 127.0.0.1:/ /mnt/sdaa [root@localhost ~]# mount | grep nfs4 127.0.0.1:/ on /mnt/sdaa type nfs4 (ro,relatime,vers=4.2,rsize=1048576,... 127.0.0.1:/ on /mnt/sdaa type nfs4 (rw,relatime,vers=4.2,rsize=1048576,... 127.0.0.1:/ on /mnt/sdaa type nfs4 (ro,relatime,vers=4.2,rsize=1048576,... 127.0.0.1:/ on /mnt/sdaa type nfs4 (rw,relatime,vers=4.2,rsize=1048576,... [root@localhost ~]# We expected that after mounting with the ro option, using the rw option to mount again would return EBUSY, but the actual situation was not the case. As shown above, when mounting for the first time, a superblock with the ro flag will be generated, and at the same time, in do_new_mount_fc --> do_add_mount, it detects that the superblock corresponding to the current target directory is inconsistent with the currently generated one (path->mnt->mnt_sb != newmnt->mnt.mnt_sb), and a new vfsmount will be generated. When mounting with the rw option for the second time, since no matching superblock can be found in the fs_supers list, a new superblock with the rw flag will be generated again. The superblock in use (ro) is different from the newly generated superblock (rw), and a new vfsmount will be generated again. When mounting with the ro option for the third time, the superblock (ro) is found in fs_supers, the superblock in use (rw) is different from the found superblock (ro), and a new vfsmount will be generated again. We can switch between ro/rw through remount, and only one superblock needs to be generated, thus avoiding the problem of repeated generation of vfsmount caused by switching superblocks. Furthermore, This can also resolve the issue described in the link. Fixes: 275a5d24bf56 ("NFS: Error when mounting the same filesystem with different options") Link: https://lore.kernel.org/all/20240604112636.236517-3-lilingfeng@huaweicloud.com/ Signed-off-by: Li Lingfeng Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 9ff46e1d444e8e6105c2b6d3268096d90a31b0a1 Author: Dan Carpenter Date: Fri Nov 15 12:13:58 2024 +0300 cifs: unlock on error in smb3_reconfigure() [ Upstream commit cda88d2fef7aa7de80b5697e8009fcbbb436f42d ] Unlock before returning if smb3_sync_session_ctx_passwords() fails. Fixes: 7e654ab7da03 ("cifs: during remount, make sure passwords are in sync") Signed-off-by: Dan Carpenter Reviewed-by: Bharath SM Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 674ba43944dab8e8f87434e25d9d10c5152584bc Author: Shyam Prasad N Date: Wed Oct 30 06:45:50 2024 +0000 cifs: during remount, make sure passwords are in sync [ Upstream commit 0f0e357902957fba28ed31bde0d6921c6bd1485d ] This fixes scenarios where remount can overwrite the only currently working password, breaking reconnect. We recently introduced a password2 field in both ses and ctx structs. This was done so as to allow the client to rotate passwords for a mount without any downtime. However, when the client transparently handles password rotation, it can swap the values of the two password fields in the ses struct, but not in smb3_fs_context struct that hangs off cifs_sb. This can lead to a situation where a remount unintentionally overwrites a working password in the ses struct. In order to fix this, we first get the passwords in ctx struct in-sync with ses struct, before replacing them with what the passwords that could be passed as a part of remount. Also, in order to avoid race condition between smb2_reconnect and smb3_reconfigure, we make sure to lock session_mutex before changing password and password2 fields of the ses structure. Fixes: 35f834265e0d ("smb3: fix broken reconnect when password changing on the server by allowing password rotation") Signed-off-by: Shyam Prasad N Signed-off-by: Meetakshi Setiya Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b0f06a70b83e3ecfee7e7e516c78d7da9956e68b Author: Masahiro Yamada Date: Wed Nov 20 08:56:39 2024 +0900 modpost: remove incorrect code in do_eisa_entry() [ Upstream commit 0c3e091319e4748cb36ac9a50848903dc6f54054 ] This function contains multiple bugs after the following commits:  - ac551828993e ("modpost: i2c aliases need no trailing wildcard")  - 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling") Commit ac551828993e inserted the following code to do_eisa_entry():     else             strcat(alias, "*"); This is incorrect because 'alias' is uninitialized. If it is not NULL-terminated, strcat() could cause a buffer overrun. Even if 'alias' happens to be zero-filled, it would output: MODULE_ALIAS("*"); This would match anything. As a result, the module could be loaded by any unrelated uevent from an unrelated subsystem. Commit ac551828993e introduced another bug.             Prior to that commit, the conditional check was:     if (eisa->sig[0]) This checked if the first character of eisa_device_id::sig was not '\0'. However, commit ac551828993e changed it as follows:     if (sig[0]) sig[0] is NOT the first character of the eisa_device_id::sig. The type of 'sig' is 'char (*)[8]', meaning that the type of 'sig[0]' is 'char [8]' instead of 'char'. 'sig[0]' and 'symval' refer to the same address, which never becomes NULL. The correct conversion would have been:     if ((*sig)[0]) However, this if-conditional was meaningless because the earlier change in commit ac551828993e was incorrect. This commit removes the entire incorrect code, which should never have been executed. Fixes: ac551828993e ("modpost: i2c aliases need no trailing wildcard") Fixes: 6543becf26ff ("mod/file2alias: make modalias generation safe for cross compiling") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 7ef523e499ef95f43da8285998b7914f6a3ca2c6 Author: John Garry Date: Wed Nov 27 09:23:18 2024 +0000 block: Don't allow an atomic write be truncated in blkdev_write_iter() [ Upstream commit 2cbd51f1f8739fd2fdf4bae1386bcf75ce0176ba ] A write which goes past the end of the bdev in blkdev_write_iter() will be truncated. Truncating cannot tolerated for an atomic write, so error that condition. Fixes: caf336f81b3a ("block: Add fops atomic write support") Signed-off-by: John Garry Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20241127092318.632790-1-john.g.garry@oracle.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4b216c8f9c7d84ef7de33ca60b97e08e03ef3292 Author: Paul Aurich Date: Tue Nov 26 18:50:31 2024 -0600 smb: Initialize cfid->tcon before performing network ops [ Upstream commit c353ee4fb119a2582d0e011f66a76a38f5cf984d ] Avoid leaking a tcon ref when a lease break races with opening the cached directory. Processing the leak break might take a reference to the tcon in cached_dir_lease_break() and then fail to release the ref in cached_dir_offload_close, since cfid->tcon is still NULL. Fixes: ebe98f1447bb ("cifs: enable caching of directories for which a lease is held") Signed-off-by: Paul Aurich Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 029ee0022a81eac2e6a11626320c7852785ae190 Author: Matt Fleming Date: Thu Nov 7 15:05:08 2024 +0000 kbuild: deb-pkg: Don't fail if modules.order is missing [ Upstream commit bcbbf493f2fa6fa1f0832f6b5b4c80a65de242d6 ] Kernels built without CONFIG_MODULES might still want to create -dbg deb packages but install_linux_image_dbg() assumes modules.order always exists. This obviously isn't true if no modules were built, so we should skip reading modules.order in that case. Fixes: 16c36f8864e3 ("kbuild: deb-pkg: use build ID instead of debug link for dbg package") Signed-off-by: Matt Fleming Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 8d9cc7f1593ed809b0398a0f5f079fb5aca3e919 Author: Masahiro Yamada Date: Thu Nov 7 01:14:41 2024 +0900 Rename .data.once to .data..once to fix resetting WARN*_ONCE [ Upstream commit dbefa1f31a91670c9e7dac9b559625336206466f ] Commit b1fca27d384e ("kernel debug: support resetting WARN*_ONCE") added support for clearing the state of once warnings. However, it is not functional when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION or CONFIG_LTO_CLANG is enabled, because .data.once matches the .data.[0-9a-zA-Z_]* pattern in the DATA_MAIN macro. Commit cb87481ee89d ("kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured") was introduced to suppress the issue for the default CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n case, providing a minimal fix for stable backporting. We were aware this did not address the issue for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y. The plan was to apply correct fixes and then revert cb87481ee89d. [1] Seven years have passed since then, yet the #ifdef workaround remains in place. Meanwhile, commit b1fca27d384e introduced the .data.once section, and commit dc5723b02e52 ("kbuild: add support for Clang LTO") extended the #ifdef. Using a ".." separator in the section name fixes the issue for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION and CONFIG_LTO_CLANG. [1]: https://lore.kernel.org/linux-kbuild/CAK7LNASck6BfdLnESxXUeECYL26yUDm0cwRZuM4gmaWUkxjL5g@mail.gmail.com/ Fixes: b1fca27d384e ("kernel debug: support resetting WARN*_ONCE") Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 513b1f8bae10197b8865c6cf9b07da6350a1501e Author: Masahiro Yamada Date: Thu Nov 7 01:14:40 2024 +0900 Rename .data.unlikely to .data..unlikely [ Upstream commit bb43a59944f45e89aa158740b8a16ba8f0b0fa2b ] Commit 7ccaba5314ca ("consolidate WARN_...ONCE() static variables") was intended to collect all .data.unlikely sections into one chunk. However, this has not worked when CONFIG_LD_DEAD_CODE_DATA_ELIMINATION or CONFIG_LTO_CLANG is enabled, because .data.unlikely matches the .data.[0-9a-zA-Z_]* pattern in the DATA_MAIN macro. Commit cb87481ee89d ("kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured") was introduced to suppress the issue for the default CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n case, providing a minimal fix for stable backporting. We were aware this did not address the issue for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y. The plan was to apply correct fixes and then revert cb87481ee89d. [1] Seven years have passed since then, yet the #ifdef workaround remains in place. Using a ".." separator in the section name fixes the issue for CONFIG_LD_DEAD_CODE_DATA_ELIMINATION and CONFIG_LTO_CLANG. [1]: https://lore.kernel.org/linux-kbuild/CAK7LNASck6BfdLnESxXUeECYL26yUDm0cwRZuM4gmaWUkxjL5g@mail.gmail.com/ Fixes: cb87481ee89d ("kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit fc9af4c0cf467b0e7a03f3cb71810e8de5235d7d Author: Maxime Chevallier Date: Fri Nov 22 11:10:30 2024 +0100 rtc: ab-eoz9: don't fail temperature reads on undervoltage notification [ Upstream commit e0779a0dcf41a6452ac0a169cd96863feb5787c7 ] The undervoltage flags reported by the RTC are useful to know if the time and date are reliable after a reboot. Although the threshold VLOW1 indicates that the thermometer has been shutdown and time compensation is off, it doesn't mean that the temperature readout is currently impossible. As the system is running, the RTC voltage is now fully established and we can read the temperature. Fixes: 67075b63cce2 ("rtc: add AB-RTCMC-32.768kHz-EOZ9 RTC support") Signed-off-by: Maxime Chevallier Link: https://lore.kernel.org/r/20241122101031.68916-3-maxime.chevallier@bootlin.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cd7f8c72dd989730156799ac4f384518ecf38c9a Author: Pali Rohár Date: Sun Oct 6 19:30:01 2024 +0200 cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE session [ Upstream commit f4ca4f5a36eac9b4da378a0f28cbbe38534a0901 ] SMB1 NT_TRANSACT_IOCTL/FSCTL_GET_REPARSE_POINT even in non-UNICODE mode returns reparse buffer in UNICODE/UTF-16 format. This is because FSCTL_GET_REPARSE_POINT is NT-based IOCTL which does not distinguish between 8-bit non-UNICODE and 16-bit UNICODE modes and its path buffers are always encoded in UTF-16. This change fixes reading of native symlinks in SMB1 when UNICODE session is not active. Fixes: ed3e0a149b58 ("smb: client: implement ->query_reparse_point() for SMB1") Signed-off-by: Pali Rohár Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c9280c017ea13ff8678ef4f1ea78a4b683292e8b Author: Pali Rohár Date: Mon Sep 23 22:40:38 2024 +0200 cifs: Fix parsing native symlinks relative to the export [ Upstream commit 723f4ef90452aa629f3d923e92e0449d69362b1d ] SMB symlink which has SYMLINK_FLAG_RELATIVE set is relative (as opposite of the absolute) and it can be relative either to the current directory (where is the symlink stored) or relative to the top level export path. To what it is relative depends on the first character of the symlink target path. If the first character is path separator then symlink is relative to the export, otherwise to the current directory. Linux (and generally POSIX systems) supports only symlink paths relative to the current directory where is symlink stored. Currently if Linux SMB client reads relative SMB symlink with first character as path separator (slash), it let as is. Which means that Linux interpret it as absolute symlink pointing from the root (/). But this location is different than the top level directory of SMB export (unless SMB export was mounted to the root) and thefore SMB symlinks relative to the export are interpreted wrongly by Linux SMB client. Fix this problem. As Linux does not have equivalent of the path relative to the top of the mount point, convert such symlink target path relative to the current directory. Do this by prepending "../" pattern N times before the SMB target path, where N is the number of path separators found in SMB symlink path. So for example, if SMB share is mounted to Linux path /mnt/share/, symlink is stored in file /mnt/share/test/folder1/symlink (so SMB symlink path is test\folder1\symlink) and SMB symlink target points to \test\folder2\file, then convert symlink target path to Linux path ../../test/folder2/file. Deduplicate code for parsing SMB symlinks in native form from functions smb2_parse_symlink_response() and parse_reparse_native_symlink() into new function smb2_parse_native_symlink() and pass into this new function a new full_path parameter from callers, which specify SMB full path where is symlink stored. This change fixes resolving of the native Windows symlinks relative to the top level directory of the SMB share. Signed-off-by: Pali Rohár Signed-off-by: Steve French Stable-dep-of: f4ca4f5a36ea ("cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE session") Signed-off-by: Sasha Levin commit ac0ceec5c8f57a56c7bd342b5b45b505df775cca Author: Andy Shevchenko Date: Mon Nov 25 12:49:14 2024 +0200 x86/Documentation: Update algo in init_size description of boot protocol [ Upstream commit be4ca6c53e66cb275cf0d71f32dac0c4606b9dc0 ] The init_size description of boot protocol has an example of the runtime start address for the compressed bzImage. For non-relocatable kernel it relies on the pref_address value (if not 0), but for relocatable case only pays respect to the load_addres and kernel_alignment, and it is inaccurate for the latter. Boot loader must consider the pref_address as the Linux kernel relocates to it before being decompressed as nicely described in this commit message a year ago: 43b1d3e68ee7 ("kexec: Allocate kernel above bzImage's pref_address") Due to this documentation inaccuracy some of the bootloaders (*) made a mistake in the calculations and if kernel image is big enough, this may lead to unbootable configurations. *) In particular, kexec-tools missed that and resently got a couple of changes which will be part of v2.0.30 release. For the record, commit 43b1d3e68ee7 only fixed the kernel kexec implementation and also missed to update the init_size description. While at it, make an example C-like looking as it's done elsewhere in the document and fix indentation as presribed by the reStructuredText specifications, so the syntax highliting will work properly. Fixes: 43b1d3e68ee7 ("kexec: Allocate kernel above bzImage's pref_address") Fixes: d297366ba692 ("x86: document new bzImage fields") Signed-off-by: Andy Shevchenko Signed-off-by: Ingo Molnar Acked-by: Randy Dunlap Cc: "H. Peter Anvin" Link: https://lore.kernel.org/r/20241125105005.1616154-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin commit 5048efee33592c421d860f55eea9d7782e1ef930 Author: Henrique Carvalho Date: Fri Nov 22 22:14:35 2024 -0300 smb: client: disable directory caching when dir_cache_timeout is zero [ Upstream commit ceaf1451990e3ea7fb50aebb5a149f57945f6e9f ] Setting dir_cache_timeout to zero should disable the caching of directory contents. Currently, even when dir_cache_timeout is zero, some caching related functions are still invoked, which is unintended behavior. Fix the issue by setting tcon->nohandlecache to true when dir_cache_timeout is zero, ensuring that directory handle caching is properly disabled. Fixes: 238b351d0935 ("smb3: allow controlling length of time directory entries are cached with dir leases") Reviewed-by: Paulo Alcantara (Red Hat) Reviewed-by: Enzo Matsumiya Signed-off-by: Henrique Carvalho Signed-off-by: Steve French Signed-off-by: Sasha Levin commit b7ed8eba0c71ada4d0f94892590a6470d7fb4a96 Author: Namhyung Kim Date: Wed Nov 20 16:13:34 2024 -0800 perf/arm-cmn: Ensure port and device id bits are set properly [ Upstream commit dfdf714fed559c09021df1d2a4bb64c0ad5f53bc ] The portid_bits and deviceid_bits were set only for XP type nodes in the arm_cmn_discover() and it confused other nodes to find XP nodes. Copy the both bits from the XP nodes directly when it sets up a new node. Fixes: e79634b53e39 ("perf/arm-cmn: Refactor node ID handling. Again.") Signed-off-by: Namhyung Kim Acked-by: Will Deacon Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20241121001334.331334-1-namhyung@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 37ad4f94cf0b01c50a4145de8b4b840e145debd7 Author: Chun-Tse Shao Date: Fri Nov 8 05:08:05 2024 +0000 perf/arm-smmuv3: Fix lockdep assert in ->event_init() [ Upstream commit 02a55f2743012a8089f09f6867220c3d57f16564 ] Same as https://lore.kernel.org/all/20240514180050.182454-1-namhyung@kernel.org/, we should skip `for_each_sibling_event()` for group leader since it doesn't have the ctx yet. Fixes: f3c0eba28704 ("perf: Add a few assertions") Reported-by: Greg Thelen Cc: Namhyung Kim Cc: Robin Murphy Cc: Tuan Phan Signed-off-by: Chun-Tse Shao Acked-by: Will Deacon Link: https://lore.kernel.org/r/20241108050806.3730811-1-ctshao@google.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit d888f5f5d76b2722c267e6bdf51d445d60647b7b Author: Alex Zenla Date: Thu Nov 21 22:51:00 2024 +0000 9p/xen: fix release of IRQ [ Upstream commit e43c608f40c065b30964f0a806348062991b802d ] Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. Fixes: 71ebd71921e45 ("xen/9pfs: connect to the backend") Signed-off-by: Alex Zenla Signed-off-by: Alexander Merritt Signed-off-by: Ariadne Conill Reviewed-by: Juergen Gross Message-ID: <20241121225100.5736-1-alexander@edera.dev> [Dominique: remove confusing variable reset to 0] Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 827ab5b83314ca5316bae8e0bd979eaca69a6912 Author: Alex Zenla Date: Tue Nov 19 21:16:33 2024 +0000 9p/xen: fix init sequence [ Upstream commit 7ef3ae82a6ebbf4750967d1ce43bcdb7e44ff74b ] Large amount of mount hangs observed during hotplugging of 9pfs devices. The 9pfs Xen driver attempts to initialize itself more than once, causing the frontend and backend to disagree: the backend listens on a channel that the frontend does not send on, resulting in stalled processing. Only allow initialization of 9p frontend once. Fixes: c15fe55d14b3b ("9p/xen: fix connection sequence") Signed-off-by: Alex Zenla Signed-off-by: Alexander Merritt Signed-off-by: Ariadne Conill Reviewed-by: Juergen Gross Message-ID: <20241119211633.38321-1-alexander@edera.dev> Signed-off-by: Dominique Martinet Signed-off-by: Sasha Levin commit 30794f4952decb2ec8efa42f704cac5304499a41 Author: Nilay Shroff Date: Tue Nov 5 11:42:09 2024 +0530 nvme-fabrics: fix kernel crash while shutting down controller [ Upstream commit e9869c85c81168a1275f909d5972a3fc435304be ] The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below: Call Trace: autoremove_wake_function+0x0/0xbc (unreliable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18 While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvme_keep_alive_end_io function is then invoked to handle the end of the keep-alive operation which decrements the admin->q_usage_counter and assuming this is the last/only request in the admin queue then the admin->q_usage_counter becomes zero. If that happens then blk-mq destroy queue operation (blk_mq_destroy_ queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash. The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()") and added it under nvme_uninit_ctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash. To fix the observed crash, we decided to move nvme_stop_keep_alive() from nvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash. Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead of adding nvme_stop_keep_alive() to the beginning of the controller shutdown code path in nvme_stop_ctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"), would help save one callsite of nvme_stop_keep_alive(). Fixes: a54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()") Link: https://lore.kernel.org/all/1a21f37b-0f2a-4745-8c56-4dc8628d3983@linux.ibm.com/ Reviewed-by: Ming Lei Signed-off-by: Nilay Shroff Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 25e3fb956bbd15cf2dffcacd4683df4a754b0762 Author: Christoph Hellwig Date: Tue Nov 19 08:26:02 2024 +0100 block: return unsigned int from bdev_io_min [ Upstream commit 46fd48ab3ea3eb3bb215684bd66ea3d260b091a9 ] The underlying limit is defined as an unsigned int, so return that from bdev_io_min as well. Fixes: ac481c20ef8f ("block: Topology ioctls") Signed-off-by: Christoph Hellwig Reviewed-by: Martin K. Petersen Reviewed-by: John Garry Link: https://lore.kernel.org/r/20241119072602.1059488-1-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit a0e93b9fefafe97d596f9c98701ae6c3b04b3ff6 Author: Yu Kuai Date: Mon Nov 4 19:00:05 2024 +0800 block: fix uaf for flush rq while iterating tags [ Upstream commit 3802f73bd80766d70f319658f334754164075bc3 ] blk_mq_clear_flush_rq_mapping() is not called during scsi probe, by checking blk_queue_init_done(). However, QUEUE_FLAG_INIT_DONE is cleared in del_gendisk by commit aec89dc5d421 ("block: keep q_usage_counter in atomic mode after del_gendisk"), hence for disk like scsi, following blk_mq_destroy_queue() will not clear flush rq from tags->rqs[] as well, cause following uaf that is found by our syzkaller for v6.6: ================================================================== BUG: KASAN: slab-use-after-free in blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 Read of size 4 at addr ffff88811c969c20 by task kworker/1:2H/224909 CPU: 1 PID: 224909 Comm: kworker/1:2H Not tainted 6.6.0-ga836a5060850 #32 Workqueue: kblockd blk_mq_timeout_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 blk_mq_find_and_get_req+0x16e/0x1a0 block/blk-mq-tag.c:261 bt_iter block/blk-mq-tag.c:288 [inline] __sbitmap_for_each_set include/linux/sbitmap.h:295 [inline] sbitmap_for_each_set include/linux/sbitmap.h:316 [inline] bt_for_each+0x455/0x790 block/blk-mq-tag.c:325 blk_mq_queue_tag_busy_iter+0x320/0x740 block/blk-mq-tag.c:534 blk_mq_timeout_work+0x1a3/0x7b0 block/blk-mq.c:1673 process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631 process_scheduled_works kernel/workqueue.c:2704 [inline] worker_thread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293 Allocated by task 942: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:374 [inline] __kasan_kmalloc mm/kasan/common.c:383 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:380 kasan_kmalloc include/linux/kasan.h:198 [inline] __do_kmalloc_node mm/slab_common.c:1007 [inline] __kmalloc_node+0x69/0x170 mm/slab_common.c:1014 kmalloc_node include/linux/slab.h:620 [inline] kzalloc_node include/linux/slab.h:732 [inline] blk_alloc_flush_queue+0x144/0x2f0 block/blk-flush.c:499 blk_mq_alloc_hctx+0x601/0x940 block/blk-mq.c:3788 blk_mq_alloc_and_init_hctx+0x27f/0x330 block/blk-mq.c:4261 blk_mq_realloc_hw_ctxs+0x488/0x5e0 block/blk-mq.c:4294 blk_mq_init_allocated_queue+0x188/0x860 block/blk-mq.c:4350 blk_mq_init_queue_data block/blk-mq.c:4166 [inline] blk_mq_init_queue+0x8d/0x100 block/blk-mq.c:4176 scsi_alloc_sdev+0x843/0xd50 drivers/scsi/scsi_scan.c:335 scsi_probe_and_add_lun+0x77c/0xde0 drivers/scsi/scsi_scan.c:1189 __scsi_scan_target+0x1fc/0x5a0 drivers/scsi/scsi_scan.c:1727 scsi_scan_channel drivers/scsi/scsi_scan.c:1815 [inline] scsi_scan_channel+0x14b/0x1e0 drivers/scsi/scsi_scan.c:1791 scsi_scan_host_selected+0x2fe/0x400 drivers/scsi/scsi_scan.c:1844 scsi_scan+0x3a0/0x3f0 drivers/scsi/scsi_sysfs.c:151 store_scan+0x2a/0x60 drivers/scsi/scsi_sysfs.c:191 dev_attr_store+0x5c/0x90 drivers/base/core.c:2388 sysfs_kf_write+0x11c/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x3fc/0x610 fs/kernfs/file.c:338 call_write_iter include/linux/fs.h:2083 [inline] new_sync_write+0x1b4/0x2d0 fs/read_write.c:493 vfs_write+0x76c/0xb00 fs/read_write.c:586 ksys_write+0x127/0x250 fs/read_write.c:639 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Freed by task 244687: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x50 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] __kasan_slab_free+0x12a/0x1b0 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1815 [inline] slab_free_freelist_hook mm/slub.c:1841 [inline] slab_free mm/slub.c:3807 [inline] __kmem_cache_free+0xe4/0x520 mm/slub.c:3820 blk_free_flush_queue+0x40/0x60 block/blk-flush.c:520 blk_mq_hw_sysfs_release+0x4a/0x170 block/blk-mq-sysfs.c:37 kobject_cleanup+0x136/0x410 lib/kobject.c:689 kobject_release lib/kobject.c:720 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x119/0x140 lib/kobject.c:737 blk_mq_release+0x24f/0x3f0 block/blk-mq.c:4144 blk_free_queue block/blk-core.c:298 [inline] blk_put_queue+0xe2/0x180 block/blk-core.c:314 blkg_free_workfn+0x376/0x6e0 block/blk-cgroup.c:144 process_one_work+0x7c4/0x1450 kernel/workqueue.c:2631 process_scheduled_works kernel/workqueue.c:2704 [inline] worker_thread+0x804/0xe40 kernel/workqueue.c:2785 kthread+0x346/0x450 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:293 Other than blk_mq_clear_flush_rq_mapping(), the flag is only used in blk_register_queue() from initialization path, hence it's safe not to clear the flag in del_gendisk. And since QUEUE_FLAG_REGISTERED already make sure that queue should only be registered once, there is no need to test the flag as well. Fixes: 6cfeadbff3f8 ("blk-mq: don't clear flush_rq from tags->rqs[]") Depends-on: commit aec89dc5d421 ("block: keep q_usage_counter in atomic mode after del_gendisk") Signed-off-by: Yu Kuai Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241104110005.1412161-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b3ba71d3ed22b8f5c9a6d05b604d739f55aafbac Author: Ming Lei Date: Fri Oct 25 08:37:20 2024 +0800 block: model freeze & enter queue as lock for supporting lockdep [ Upstream commit f1be1788a32e8fa63416ad4518bbd1a85a825c9d ] Recently we got several deadlock report[1][2][3] caused by blk_mq_freeze_queue and blk_enter_queue(). Turns out the two are just like acquiring read/write lock, so model them as read/write lock for supporting lockdep: 1) model q->q_usage_counter as two locks(io and queue lock) - queue lock covers sync with blk_enter_queue() - io lock covers sync with bio_enter_queue() 2) make the lockdep class/key as per-queue: - different subsystem has very different lock use pattern, shared lock class causes false positive easily - freeze_queue degrades to no lock in case that disk state becomes DEAD because bio_enter_queue() won't be blocked any more - freeze_queue degrades to no lock in case that request queue becomes dying because blk_enter_queue() won't be blocked any more 3) model blk_mq_freeze_queue() as acquire_exclusive & try_lock - it is exclusive lock, so dependency with blk_enter_queue() is covered - it is trylock because blk_mq_freeze_queue() are allowed to run concurrently 4) model blk_enter_queue() & bio_enter_queue() as acquire_read() - nested blk_enter_queue() are allowed - dependency with blk_mq_freeze_queue() is covered - blk_queue_exit() is often called from other contexts(such as irq), and it can't be annotated as lock_release(), so simply do it in blk_enter_queue(), this way still covered cases as many as possible With lockdep support, such kind of reports may be reported asap and needn't wait until the real deadlock is triggered. For example, lockdep report can be triggered in the report[3] with this patch applied. [1] occasional block layer hang when setting 'echo noop > /sys/block/sda/queue/scheduler' https://bugzilla.kernel.org/show_bug.cgi?id=219166 [2] del_gendisk() vs blk_queue_enter() race condition https://lore.kernel.org/linux-block/20241003085610.GK11458@google.com/ [3] queue_freeze & queue_enter deadlock in scsi https://lore.kernel.org/linux-block/ZxG38G9BuFdBpBHZ@fedora/T/#u Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241025003722.3630252-4-ming.lei@redhat.com Signed-off-by: Jens Axboe Stable-dep-of: 3802f73bd807 ("block: fix uaf for flush rq while iterating tags") Signed-off-by: Sasha Levin commit 5ddbe85ac614024522d738c5d962b3b763a6971b Author: Ming Lei Date: Fri Oct 25 08:37:18 2024 +0800 blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs [ Upstream commit 8acdd0e7bfadda6b5103f2960d293581954454ed ] Add non_owner variant of start_freeze/unfreeze queue APIs, so that the caller knows that what they are doing, and we can skip lockdep support for non_owner variant in per-call level. Prepare for supporting lockdep for freezing/unfreezing queue. Reviewed-by: Christoph Hellwig Suggested-by: Christoph Hellwig Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241025003722.3630252-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Stable-dep-of: 3802f73bd807 ("block: fix uaf for flush rq while iterating tags") Signed-off-by: Sasha Levin commit c03cc062e3acccc6693a6f70d611784c39b9b2d4 Author: Breno Leitao Date: Tue Nov 5 06:42:46 2024 -0800 nvme/multipath: Fix RCU list traversal to use SRCU primitive [ Upstream commit 5dd18f09ce7399df6fffe80d1598add46c395ae9 ] The code currently uses list_for_each_entry_rcu() while holding an SRCU lock, triggering false positive warnings with CONFIG_PROVE_RCU=y enabled: drivers/nvme/host/multipath.c:168 RCU-list traversed in non-reader section!! drivers/nvme/host/multipath.c:227 RCU-list traversed in non-reader section!! drivers/nvme/host/multipath.c:260 RCU-list traversed in non-reader section!! While the list is properly protected by SRCU lock, the code uses the wrong list traversal primitive. Replace list_for_each_entry_rcu() with list_for_each_entry_srcu() to correctly indicate SRCU-based protection and eliminate the false warning. Signed-off-by: Breno Leitao Fixes: be647e2c76b2 ("nvme: use srcu for iterating namespace list") Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 64184804a74e5cab8bb71bc856b4693d5d06cdb0 Author: Hannes Reinecke Date: Sat Sep 14 14:01:23 2024 +0200 nvme-multipath: avoid hang on inaccessible namespaces [ Upstream commit 3b97f5a05cfc55e7729ff3769f63eef64e2178bb ] During repetitive namespace remapping operations on the target the namespace might have changed between the time the initial scan was performed, and partition scan was invoked by device_add_disk() in nvme_mpath_set_live(). We then end up with a stuck scanning process: [<0>] folio_wait_bit_common+0x12a/0x310 [<0>] filemap_read_folio+0x97/0xd0 [<0>] do_read_cache_folio+0x108/0x390 [<0>] read_part_sector+0x31/0xa0 [<0>] read_lba+0xc5/0x160 [<0>] efi_partition+0xd9/0x8f0 [<0>] bdev_disk_changed+0x23d/0x6d0 [<0>] blkdev_get_whole+0x78/0xc0 [<0>] bdev_open+0x2c6/0x3b0 [<0>] bdev_file_open_by_dev+0xcb/0x120 [<0>] disk_scan_partitions+0x5d/0x100 [<0>] device_add_disk+0x402/0x420 [<0>] nvme_mpath_set_live+0x4f/0x1f0 [nvme_core] [<0>] nvme_mpath_add_disk+0x107/0x120 [nvme_core] [<0>] nvme_alloc_ns+0xac6/0xe60 [nvme_core] [<0>] nvme_scan_ns+0x2dd/0x3e0 [nvme_core] [<0>] nvme_scan_work+0x1a3/0x490 [nvme_core] This happens when we have several paths, some of which are inaccessible, and the active paths are removed first. Then nvme_find_path() will requeue I/O in the ns_head (as paths are present), but the requeue list is never triggered as all remaining paths are inactive. This patch checks for NVME_NSHEAD_DISK_LIVE in nvme_available_path(), and requeue I/O after NVME_NSHEAD_DISK_LIVE has been cleared once the last path has been removed to properly terminate pending I/O. Signed-off-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Stable-dep-of: 5dd18f09ce73 ("nvme/multipath: Fix RCU list traversal to use SRCU primitive") Signed-off-by: Sasha Levin commit 45ab2cc383f7524673f22ffb8410e4ba18a66fe2 Author: Trond Myklebust Date: Mon Nov 4 21:09:21 2024 -0500 Revert "nfs: don't reuse partially completed requests in nfs_lock_and_join_requests" [ Upstream commit 66f9dac9077c9c063552e465212abeb8f97d28a7 ] This reverts commit b571cfcb9dcac187c6d967987792d37cb0688610. This patch appears to assume that if one request is complete, then the others will complete too before unlocking. That is not a valid assumption, since other requests could hit a non-fatal error or a short write that would cause them not to complete. Reported-by: Igor Raits Link: https://bugzilla.kernel.org/show_bug.cgi?id=219508 Fixes: b571cfcb9dca ("nfs: don't reuse partially completed requests in nfs_lock_and_join_requests") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ef92f44efa22f8f1224365e49fc3febb051d1b51 Author: Wolfram Sang Date: Wed Nov 13 12:30:32 2024 +0100 rtc: rzn1: fix BCD to rtc_time conversion errors [ Upstream commit 55727188dfa3572aecd946e58fab9e4a64f06894 ] tm_mon describes months from 0 to 11, but the register contains BCD from 1 to 12. tm_year contains years since 1900, but the BCD contains 20XX. Apply the offsets when converting these numbers. Fixes: deeb4b5393e1 ("rtc: rzn1: Add new RTC driver") Signed-off-by: Wolfram Sang Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20241113113032.27409-1-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 4844e462ca96e5e35c885a24ab34825d6cda61f6 Author: Qingfang Deng Date: Mon Jul 1 12:52:05 2024 +0800 jffs2: fix use of uninitialized variable [ Upstream commit 3ba44ee966bc3c41dd8a944f963466c8fcc60dc8 ] When building the kernel with -Wmaybe-uninitialized, the compiler reports this warning: In function 'jffs2_mark_erased_block', inlined from 'jffs2_erase_pending_blocks' at fs/jffs2/erase.c:116:4: fs/jffs2/erase.c:474:9: warning: 'bad_offset' may be used uninitialized [-Wmaybe-uninitialized] 474 | jffs2_erase_failed(c, jeb, bad_offset); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ fs/jffs2/erase.c: In function 'jffs2_erase_pending_blocks': fs/jffs2/erase.c:402:18: note: 'bad_offset' was declared here 402 | uint32_t bad_offset; | ^~~~~~~~~~ When mtd->point() is used, jffs2_erase_pending_blocks can return -EIO without initializing bad_offset, which is later used at the filebad label in jffs2_mark_erased_block. Fix it by initializing this variable. Fixes: 8a0f572397ca ("[JFFS2] Return values of jffs2_block_check_erase error paths") Signed-off-by: Qingfang Deng Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 398a91599d263e41c5f95a2fd4ebdb6280b5c6c3 Author: Waqar Hameed Date: Wed Oct 9 16:46:59 2024 +0200 ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit [ Upstream commit 4617fb8fc15effe8eda4dd898d4e33eb537a7140 ] After an insertion in TNC, the tree might split and cause a node to change its `znode->parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's `znode->cparent` could still point to a freed node. This `znode->cparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode->cparent` in `write_index()` in `ubifs_tnc_end_commit()`. This can be triggered by running rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports: BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153 Call trace: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 do_commit+0x4e0/0x1340 ubifs_bg_thread+0x234/0x2e0 kthread+0x36c/0x410 ret_from_fork+0x10/0x20 Allocated by task 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 write_cache_pages+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c file_write_and_wait_range+0x140/0x190 ubifs_fsync+0xe8/0x290 vfs_fsync_range+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Freed by task 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 do_unlinkat+0x2cc/0x490 __arm64_sys_unlinkat+0x90/0x100 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC: zroot / / zp1 / / zn Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn `zn->parent` has now been moved to `zp2`, *but* `zn->cparent` still points to `zp1`. Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`: zroot \ \ zp2 \ \ zn `zroot` and `zp2` get freed and the tree collapses: zn `zn` now becomes the new `zroot`. `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode->cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode->cparent->zbranch[znode->iip].hash` that triggers the use-after-free! Fix this by explicitly setting `znode->cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes is bottom-up in the tree. Thus, when `find_next_dirty(znode)` returns NULL, the current `znode` _is_ the root node. Add an assert for this. Fixes: 16a26b20d2af ("ubifs: authentication: Add hashes to index nodes") Tested-by: Waqar Hameed Co-developed-by: Zhihao Cheng Signed-off-by: Zhihao Cheng Signed-off-by: Waqar Hameed Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 3d8558135cd56a2a8052024be4073e160f36658c Author: Zhihao Cheng Date: Fri Oct 11 12:50:02 2024 +0800 ubi: fastmap: Fix duplicate slab cache names while attaching [ Upstream commit bcddf52b7a17adcebc768d26f4e27cf79adb424c ] Since commit 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y"), the duplicate slab cache names can be detected and a kernel WARNING is thrown out. In UBI fast attaching process, alloc_ai() could be invoked twice with the same slab cache name 'ubi_aeb_slab_cache', which will trigger following warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0 The problem could be easily reproduced by loading UBI device by fastmap with CONFIG_DEBUG_VM=y. Fix it by using different slab names for alloc_ai() callers. Fixes: d2158f69a7d4 ("UBI: Remove alloc_ai() slab name from parameter list") Fixes: fdf10ed710c0 ("ubi: Rework Fastmap attach base code") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 6d1505741f8e97805b537a1355a7b9e7c968f714 Author: Zhihao Cheng Date: Thu Sep 5 09:09:09 2024 +0800 ubifs: Correct the total block count by deducting journal reservation [ Upstream commit 84a2bee9c49769310efa19601157ef50a1df1267 ] Since commit e874dcde1cbf ("ubifs: Reserve one leb for each journal head while doing budget"), available space is calulated by deducting reservation for all journal heads. However, the total block count ( which is only used by statfs) is not updated yet, which will cause the wrong displaying for used space(total - available). Fix it by deducting reservation for all journal heads from total block count. Fixes: e874dcde1cbf ("ubifs: Reserve one leb for each journal head while doing budget") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit ec869b6ae9a99cb02cb761b46f36acfcfdc3b5e1 Author: Zhihao Cheng Date: Mon Aug 19 11:26:22 2024 +0800 ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty [ Upstream commit c4595fe394a289927077e3da561db27811919ee0 ] Since commit 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb before wear leveling"), wear_leveling_worker() won't schedule fm_work if wear-leveling pool is empty, which could temporarily disable the wear-leveling until the fastmap is updated(eg. pool becomes empty). Fix it by scheduling fm_work if wl_pool is empty during wear-leveing. Fixes: 14072ee33d5a ("ubi: fastmap: Check wl_pool for free peb before wear leveling") Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit a1f0b4af90cc18b10261ecde56c6a56b22c75bd1 Author: Yongliang Gao Date: Fri Oct 11 12:31:53 2024 +0800 rtc: check if __rtc_read_time was successful in rtc_timer_do_work() [ Upstream commit e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d ] If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. Fixes: 6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events") Signed-off-by: Yongliang Gao Acked-by: Jingqun Li Link: https://lore.kernel.org/r/20241011043153.3788112-1-leonylgao@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 0ffa3b4cb8574c480b5d14008235c7f3a67e072b Author: Nobuhiro Iwamatsu Date: Tue Oct 8 13:17:37 2024 +0900 rtc: abx80x: Fix WDT bit position of the status register [ Upstream commit 10e078b273ee7a2b8b4f05a64ac458f5e652d18d ] The WDT bit in the status register is 5, not 6. This fixes from 6 to 5. Link: https://abracon.com/Support/AppsManuals/Precisiontiming/AB08XX-Application-Manual.pdf Link: https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-1805-C3_App-Manual.pdf Fixes: 749e36d0a0d7 ("rtc: abx80x: add basic watchdog support") Cc: Jeremy Gebben Signed-off-by: Nobuhiro Iwamatsu Link: https://lore.kernel.org/r/20241008041737.1640633-1-iwamatsu@nigauri.org Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit cbd100e558a04234f0067ed54b6391b1e71c8615 Author: Jinjie Ruan Date: Thu Sep 12 11:37:27 2024 +0800 rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit b6cd7adec0cf03f0aefc55676e71dd721cbc71a8 ] If request_irq() fails in st_rtc_probe(), there is no need to enable the irq, and if it succeeds, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC") Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/r/20240912033727.3013951-1-ruanjinjie@huawei.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit e2277a1d9d5cd0d625a4fd7c04fce2b53e66df77 Author: Trond Myklebust Date: Fri Nov 8 12:13:31 2024 -0500 NFSv4.0: Fix a use-after-free problem in the asynchronous open() [ Upstream commit 2fdb05dc0931250574f0cb0ebeb5ed8e20f4a889 ] Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed. Reported-by: Yang Erkun Fixes: 24ac23ab88df ("NFSv4: Convert open() into an asynchronous RPC call") Reviewed-by: Yang Erkun Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 7e8cf283d25f3acf247d6e2d5f72f0a07db81ada Author: Tiwei Bie Date: Wed Nov 6 18:39:33 2024 +0800 um: Always dump trace for specified task in show_stack [ Upstream commit 0f659ff362eac69777c4c191b7e5ccb19d76c67d ] Currently, show_stack() always dumps the trace of the current task. However, it should dump the trace of the specified task if one is provided. Otherwise, things like running "echo t > sysrq-trigger" won't work as expected. Fixes: 970e51feaddb ("um: Add support for CONFIG_STACKTRACE") Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20241106103933.1132365-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 17c6ca854ba3c99c17075934925779b4d9c391c0 Author: Tiwei Bie Date: Tue Nov 5 00:32:00 2024 +0800 um: ubd: Initialize ubd's disk pointer in ubd_add [ Upstream commit df700802abcac3c7c4a4ced099aa42b9a144eea8 ] Currently, the initialization of the disk pointer in the ubd structure is missing. It should be initialized with the allocated gendisk pointer in ubd_add(). Fixes: 32621ad7a7ea ("ubd: remove the ubd_gendisk array") Signed-off-by: Tiwei Bie Acked-By: Anton Ivanov Link: https://patch.msgid.link/20241104163203.435515-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit aa4ac48bcab016336e0583af33993bffceb315ab Author: Christoph Hellwig Date: Wed Oct 23 07:53:04 2024 +0200 kfifo: don't include dma-mapping.h in kfifo.h [ Upstream commit 44059790a5cb9258ae6137387e4c39b717fd2ced ] Nothing in kfifo.h directly needs dma-mapping.h, only two macros use DMA_MAPPING_ERROR when actually instantiated. Drop the dma-mapping.h include to reduce include bloat. Add an explicity include to drivers/mailbox/omap-mailbox.c as that file uses __raw_readl and __raw_writel through a complicated include chain involving Fixes: d52b761e4b1a ("kfifo: add kfifo_dma_out_prepare_mapped()") Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20241023055317.313234-1-hch@lst.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit be6291ebb511b2a984d107980252f8477e0b9fec Author: Tiwei Bie Date: Fri Sep 13 10:33:02 2024 +0800 um: Fix the return value of elf_core_copy_task_fpregs [ Upstream commit 865e3845eeaa21e9a62abc1361644e67124f1ec0 ] This function is expected to return a boolean value, which should be true on success and false on failure. Fixes: d1254b12c93e ("uml: fix x86_64 core dump crash") Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20240913023302.130300-1-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d1a211e5210d31da8f49fc0021bf7129b726468c Author: Tiwei Bie Date: Mon Sep 16 12:59:48 2024 +0800 um: Fix potential integer overflow during physmem setup [ Upstream commit a98b7761f697e590ed5d610d87fa12be66f23419 ] This issue happens when the real map size is greater than LONG_MAX, which can be easily triggered on UML/i386. Fixes: fe205bdd1321 ("um: Print minimum physical memory requirement") Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20240916045950.508910-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ec305f303bf070b4f6896b7a76009f702956d402 Author: Yang Erkun Date: Mon Oct 21 22:23:42 2024 +0800 SUNRPC: make sure cache entry active before cache_show commit 2862eee078a4d2d1f584e7f24fa50dddfa5f3471 upstream. The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 084f797dbc7e52209a4ab6dbc7f0109268754eb9 Author: Chuck Lever Date: Tue Sep 17 12:15:23 2024 -0400 NFSD: Prevent a potential integer overflow commit 7f33b92e5b18e904a481e6e208486da43e4dc841 upstream. If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value. Reported-by: Dan Carpenter Cc: stable@vger.kernel.org Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 85211611661f3cd33ea9a0286368cea03486f0d2 Author: Yuan Can Date: Thu Nov 7 21:52:23 2024 -0800 Input: cs40l50 - fix wrong usage of INIT_WORK() commit 5c822c0ce5cc83ed4cd8394f3dc46dae8d9a681d upstream. In cs40l50_add(), the work_data is a local variable and the work_data.work should initialize with INIT_WORK_ONSTACK() instead of INIT_WORK(). Small error in cs40l50_erase() also fixed in this commit. Fixes: c38fe1bb5d21 ("Input: cs40l50 - Add support for the CS40L50 haptic driver") Signed-off-by: Yuan Can Reviewed-by: James Ogletree Link: https://lore.kernel.org/r/20241106013549.78142-1-yuancan@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8fed302872e26c7bf44d855c53a1cde747172d58 Author: Ma Wupeng Date: Wed Oct 23 17:31:29 2024 +0800 ipc: fix memleak if msg_init_ns failed in create_ipc_ns commit bc8f5921cd69188627c08041276238de222ab466 upstream. Percpu memory allocation may failed during create_ipc_ns however this fail is not handled properly since ipc sysctls and mq sysctls is not released properly. Fix this by release these two resource when failure. Here is the kmemleak stack when percpu failed: unreferenced object 0xffff88819de2a600 (size 512): comm "shmem_2nstest", pid 120711, jiffies 4300542254 hex dump (first 32 bytes): 60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H..... 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V..... backtrace (crc be7cba35): [] __kmalloc_node_track_caller_noprof+0x333/0x420 [] kmemdup_noprof+0x26/0x50 [] setup_mq_sysctls+0x57/0x1d0 [] copy_ipcs+0x29c/0x3b0 [] create_new_namespaces+0x1d0/0x920 [] copy_namespaces+0x2e9/0x3e0 [] copy_process+0x29f3/0x7ff0 [] kernel_clone+0xc0/0x650 [] __do_sys_clone+0xa1/0xe0 [] do_syscall_64+0xbf/0x1c0 [] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Link: https://lkml.kernel.org/r/20241023093129.3074301-1-mawupeng1@huawei.com Fixes: 72d1e611082e ("ipc/msg: mitigate the lock contention with percpu counter") Signed-off-by: Ma Wupeng Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit c1077078ce4589b5e5387f6b0aaa0d4534b9eb57 Author: Chao Yu Date: Wed Oct 16 16:13:37 2024 +0800 f2fs: fix to do sanity check on node blkaddr in truncate_node() commit 6babe00ccd34fc65b78ef8b99754e32b4385f23d upstream. syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node(). Reported-by: syzbot+33379ce4ac76acf7d0c7@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/0000000000009a6cd706224ca720@google.com/ Cc: stable@vger.kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 33c5253b8f0abf1e2d2fbb9c4fa1713087f5d8c5 Author: Bartosz Golaszewski Date: Fri Nov 1 21:54:53 2024 +0100 lib: string_helpers: silence snprintf() output truncation warning commit a508ef4b1dcc82227edc594ffae583874dd425d7 upstream. The output of ".%03u" with the unsigned int in range [0, 4294966295] may get truncated if the target buffer is not 12 bytes. This can't really happen here as the 'remainder' variable cannot exceed 999 but the compiler doesn't know it. To make it happy just increase the buffer to where the warning goes away. Fixes: 3c9f3681d0b4 ("[SCSI] lib: add generic helper to print sizes rounded to the correct SI range") Signed-off-by: Bartosz Golaszewski Reviewed-by: Andy Shevchenko Cc: James E.J. Bottomley Cc: Kees Cook Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton Link: https://lore.kernel.org/r/20241101205453.9353-1-brgl@bgdev.pl Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit b286a9fc717e3ff92c3f7453355cb4490ac869df Author: Ming Lei Date: Tue Nov 19 11:06:46 2024 +0800 ublk: fix error code for unsupported command commit 34c1227035b3ab930a1ae6ab6f22fec1af8ab09e upstream. ENOTSUPP is for kernel use only, and shouldn't be sent to userspace. Fix it by replacing it with EOPNOTSUPP. Cc: stable@vger.kernel.org Fixes: bfbcef036396 ("ublk_drv: move ublk_get_device_from_id into ublk_ctrl_uring_cmd") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241119030646.2319030-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 76765823308db7834bf2639d8068f4683fdb8552 Author: Javier Carrasco Date: Sun Oct 27 13:26:49 2024 +0100 counter: stm32-timer-cnt: fix device_node handling in probe_encoder() commit 147359e23e5c9652ff8c5a98a51a7323bd51c94a upstream. Device nodes accessed via of_get_compatible_child() require of_node_put() to be called when the node is no longer required to avoid leaving a reference to the node behind, leaking the resource. In this case, the usage of 'tnode' is straightforward and there are no error paths, allowing for a single of_node_put() when 'tnode' is no longer required. Cc: stable@vger.kernel.org Fixes: 29646ee33cc3 ("counter: stm32-timer-cnt: add checks on quadrature encoder capability") Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20241027-stm32-timer-cnt-of_node_put-v1-1-ebd903cdf7ac@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman commit ceda8d727901eb8af1d3ba97f755d7e331ee15ee Author: Javier Carrasco Date: Mon Oct 14 10:56:37 2024 +0200 staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node commit 22a3703af127e897dc7df89372b85bb9dc331c5f upstream. An error path was introduced without including the required call to of_node_put() to decrement the node's refcount and avoid leaking memory. If the call to kzalloc() for 'mgmt' fails, the probe returns without decrementing the refcount. Use the automatic cleanup facility to fix the bug and protect the code against new error paths where the call to of_node_put() might be missing again. Cc: stable@vger.kernel.org Fixes: 1c9e16b73166 ("staging: vc04_services: vchiq_arm: Split driver static and runtime data") Signed-off-by: Javier Carrasco Reviewed-by: Dan Carpenter Reviewed-by: Umang Jain Link: https://lore.kernel.org/r/20241014-vchiq_arm-of_node_put-v2-2-cafe0a4c2666@gmail.com Signed-off-by: Greg Kroah-Hartman commit b7c3d0b59213ebeedff63d128728ce0b3d7a51ec Author: Thinh Nguyen Date: Thu Nov 14 01:02:18 2024 +0000 usb: dwc3: gadget: Fix looping of queued SG entries commit b7fc65f5141c24785dc8c19249ca4efcf71b3524 upstream. The dwc3_request->num_queued_sgs is decremented on completion. If a partially completed request is handled, then the dwc3_request->num_queued_sgs no longer reflects the total number of num_queued_sgs (it would be cleared). Correctly check the number of request SG entries remained to be prepare and queued. Failure to do this may cause null pointer dereference when accessing non-existent SG entry. Cc: stable@vger.kernel.org Fixes: c96e6725db9d ("usb: dwc3: gadget: Correct the logic for queuing sgs") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/d07a7c4aa0fcf746cdca0515150dbe5c52000af7.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit fb3c0449e1a63268246bde611a3d6541fccef743 Author: Thinh Nguyen Date: Thu Nov 14 01:02:12 2024 +0000 usb: dwc3: gadget: Fix checking for number of TRBs left commit 02a6982b0ccfcdc39e20016f5fc9a1b7826a6ee7 upstream. The check whether the TRB ring is full or empty in dwc3_calc_trbs_left() is insufficient. It assumes there are active TRBs if there's any request in the started_list. However, that's not the case for requests with a large SG list. That is, if we have a single usb request that requires more TRBs than the total TRBs in the TRB ring, the queued TRBs will be available when all the TRBs in the ring are completed. But the request is only partially completed and remains in the started_list. With the current logic, the TRB ring is empty, but dwc3_calc_trbs_left() returns 0. Fix this by additionally checking for the request->num_trbs for active TRB count. Cc: stable@vger.kernel.org Fixes: 51f1954ad853 ("usb: dwc3: gadget: Fix dwc3_calc_trbs_left()") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/708dc62b56b77da1f704cc2ae9b6ddb1f2dbef1f.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit f05ad9755bb294328c3d0f429164ac6d4d08c548 Author: Hubert Wiśniewski Date: Sun Nov 10 18:21:48 2024 +0100 usb: musb: Fix hardware lockup on first Rx endpoint request commit 3fc137386c4620305bbc2a216868c53f9245670a upstream. There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set. 4. The first request is enqueued using usb_ep_queue(), leading to the call of req->complete(), as shown in the call trace above. 5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usb_g_giveback() removes the request before invoking the callback. 6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set. For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rx_complete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host. The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways: 1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netif_rx() interacts with interrupts was already quite challenging and u_ether is not the only function driver. Similar "bugs" could be hidden in other drivers as well. 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack. 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them. 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once IRQs are enabled, the interrupt handler will be able to correctly process the next incoming packet (eventually calling rxstate()). This approach may cause one or two packets to be dropped (two if double buffering is enabled), but this seems to be a minor issue, as packet loss can occur when the software is not yet ready to process them. Additionally, this solution makes the gadget driver compliant with the rule mentioned in the docstring of usb_ep_queue(). There may be additional solutions, but from these four, the last one has been chosen as it seems to be the most appropriate, as it addresses the "bad" behavior of the driver. Fixes: baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context.") Cc: stable@vger.kernel.org Signed-off-by: Hubert Wiśniewski Link: https://lore.kernel.org/r/4ee1ead4525f78fb5909a8cbf99513ad0082ad21.camel@gmail.com Signed-off-by: Greg Kroah-Hartman commit ad551e4735fafee123dee83319244648540e1b0d Author: Thinh Nguyen Date: Thu Nov 14 01:02:06 2024 +0000 usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED commit 5d2fb074dea289c41f5aaf2c3f68286bee370634 upstream. The driver cannot issue the End Transfer command to the SETUP transfer. Don't clear DWC3_EP_TRANSFER_STARTED flag to make sure that the driver won't send Start Transfer command again, which can cause no-resource error. For example this can occur if the host issues a reset to the device. Cc: stable@vger.kernel.org Fixes: 76cb323f80ac ("usb: dwc3: ep0: clear all EP0 flags") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/d3d618185fd614bb7426352a9fc1199641d3b5f5.1731545781.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 817180ec0797ebe2699cd4c7e6d008ba7ab69211 Author: Stanislaw Gruszka Date: Tue Nov 12 08:55:12 2024 +0100 usb: misc: ljca: move usb_autopm_put_interface() after wait for response commit 5c5d8eb8af06df615e8b1dc88e5847196c846045 upstream. Do not mark interface as ready to suspend when we are still waiting for response messages from the device. Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus Signed-off-by: Stanislaw Gruszka Link: https://lore.kernel.org/r/20241112075514.680712-1-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2acc0372e8b42906843e1317f55b17f3872cbd14 Author: Stanislaw Gruszka Date: Tue Nov 12 08:55:13 2024 +0100 usb: misc: ljca: set small runtime autosuspend delay commit 2481af79671a6603fce201cbbc48f31e488e9fae upstream. On some Lenovo platforms, the patch works around problems with ov2740 sensor initialization, which manifest themself like below: [ 4.540476] ov2740 i2c-INT3474:01: error -EIO: failed to find sensor [ 4.542066] ov2740 i2c-INT3474:01: probe with driver ov2740 failed with error -5 or [ 7.742633] ov2740 i2c-INT3474:01: chip id mismatch: 2740 != 0 [ 7.742638] ov2740 i2c-INT3474:01: error -ENXIO: failed to find sensor and also by random failures of video stream start. Issue can be reproduced by this script: n=0 k=0 while [ $n -lt 50 ] ; do sudo modprobe -r ov2740 sleep `expr $RANDOM % 5` sudo modprobe ov2740 if media-ctl -p | grep -q ov2740 ; then let k++ fi let n++ done echo Success rate $k/$n Without the patch, success rate is approximately 15 or 50 tries. With the patch it does not fail. This problem is some hardware or firmware malfunction, that can not be easy debug and fix. While setting small autosuspend delay is not perfect workaround as user can configure it to any value, it will prevent the failures by default. Additionally setting small autosuspend delay should have positive effect on power consumption as for most ljca workloads device is used for just a few milliseconds flowed by long periods of at least 100ms of inactivity (usually more). Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus Signed-off-by: Stanislaw Gruszka Link: https://lore.kernel.org/r/20241112075514.680712-2-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit ff4528bbc82d0d90073751f7b49e7b9e9c7e5638 Author: Paul Aurich Date: Mon Nov 18 13:50:28 2024 -0800 smb: During unmount, ensure all cached dir instances drop their dentry commit 3fa640d035e5ae526769615c35cb9ed4be6e3662 upstream. The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs: BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661! This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including: - Receiving a lease break from the server - Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid. To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal. The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations. Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing. While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry. Fixes: ebe98f1447bb ("cifs: enable caching of directories for which a lease is held") Cc: stable@vger.kernel.org Signed-off-by: Paul Aurich Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 97e2afcac0bebfef6a5360f4267ce4c44507b845 Author: Paul Aurich Date: Mon Nov 18 13:50:27 2024 -0800 smb: prevent use-after-free due to open_cached_dir error paths commit a9685b409a03b73d2980bbfa53eb47555802d0a9 upstream. If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) Cc: stable@vger.kernel.org Signed-off-by: Paul Aurich Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1d76332d783db12684b67592f1fb2057b88af4c3 Author: Paul Aurich Date: Mon Nov 18 13:50:26 2024 -0800 smb: Don't leak cfid when reconnect races with open_cached_dir commit 7afb86733685c64c604d32faf00fa4a1f22c2ab1 upstream. open_cached_dir() may either race with the tcon reconnection even before compound_send_recv() or directly trigger a reconnection via SMB2_open_init() or SMB_query_info_init(). The reconnection process invokes invalidate_all_cached_dirs() via cifs_mark_open_files_invalid(), which removes all cfids from the cfids->entries list but doesn't drop a ref if has_lease isn't true. This results in the currently-being-constructed cfid not being on the list, but still having a refcount of 2. It leaks if returned from open_cached_dir(). Fix this by setting cfid->has_lease when the ref is actually taken; the cfid will not be used by other threads until it has a valid time. Addresses these kmemleaks: unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] open_cached_dir+0x993/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e And addresses these BUG splats when unmounting the SMB filesystem: BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100 Modules linked in: CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:umount_check+0xd0/0x100 Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace: d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007ffee9138598 EFLAGS: 00000246 ORIG_RAX: 0000000000000050 RAX: 0000000000000000 RBX: 0000558f1803e9a0 RCX: 00007f23bfb93ae7 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000558f1803e9a0 RBP: 0000558f1803e600 R08: 0000000000000007 R09: 0000558f17fab610 R10: d91d5ec34ab757b0 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 0000000000000015 R15: 0000000000000000 irq event stamp: 1163486 hardirqs last enabled at (1163485): [] _raw_spin_unlock_irqrestore+0x34/0x60 hardirqs last disabled at (1163486): [] __schedule+0xc7c/0x19a0 softirqs last enabled at (1163482): [] __smb_send_rqst+0x3de/0x990 softirqs last disabled at (1163480): [] release_sock+0x21/0xf0 ---[ end trace 0000000000000000 ]--- VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 UID: 0 PID: 3433 Comm: bash Tainted: G W 6.12.0-rc4-g850925a8133c-dirty #49 Tainted: [W]=WARN Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:generic_shutdown_super+0x290/0x2a0 Code: e8 15 7c f7 ff 48 8b 5d 28 48 89 df e8 09 7c f7 ff 48 8b 0b 48 89 ee 48 8d 95 68 06 00 00 48 c7 c7 80 7f db ac e8 00 69 af ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 90 90 90 90 90 RSP: 0018:ffff88811cc27a50 EFLAGS: 00010246 RAX: 000000000000003e RBX: ffffffffae994420 RCX: 0000000000000027 RDX: 0000000000000000 RSI: ffffffffab06180e RDI: ffff8881f6eb18c8 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed103edd6319 R10: ffff8881f6eb18cb R11: 00000000016d3158 R12: ffff8881462ec9c0 R13: ffff8881462ec050 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f23bfa98740(0000) GS:ffff8881f6e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8364005d68 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace: kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:generic_shutdown_super+0x290/0x2a0 Code: e8 15 7c f7 ff 48 8b 5d 28 48 89 df e8 09 7c f7 ff 48 8b 0b 48 89 ee 48 8d 95 68 06 00 00 48 c7 c7 80 7f db ac e8 00 69 af ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 90 90 90 90 90 RSP: 0018:ffff88811cc27a50 EFLAGS: 00010246 RAX: 000000000000003e RBX: ffffffffae994420 RCX: 0000000000000027 RDX: 0000000000000000 RSI: ffffffffab06180e RDI: ffff8881f6eb18c8 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed103edd6319 R10: ffff8881f6eb18cb R11: 00000000016d3158 R12: ffff8881462ec9c0 R13: ffff8881462ec050 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f23bfa98740(0000) GS:ffff8881f6e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8364005d68 CR3: 0000000123c80000 CR4: 0000000000350ef0 This reproduces eventually with an SMB mount and two shells running these loops concurrently - while true; do cd ~; sleep 1; for i in {1..3}; do cd /mnt/test/subdir; echo $PWD; sleep 1; cd ..; echo $PWD; sleep 1; done; echo ...; done - while true; do iptables -F OUTPUT; mount -t cifs -a; for _ in {0..2}; do ls /mnt/test/subdir/ | wc -l; done; iptables -I OUTPUT -p tcp --dport 445 -j DROP; sleep 10 echo "unmounting"; umount -l -t cifs -a; echo "done unmounting"; sleep 20 echo "recovering"; iptables -F OUTPUT; sleep 10; done Fixes: ebe98f1447bb ("cifs: enable caching of directories for which a lease is held") Fixes: 5c86919455c1 ("smb: client: fix use-after-free in smb2_query_info_compound()") Cc: stable@vger.kernel.org Signed-off-by: Paul Aurich Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2ae227f8c2793036bcf0c2ff9f34f2b34a74722c Author: Paulo Alcantara Date: Mon Nov 18 12:35:16 2024 -0300 smb: client: handle max length for SMB symlinks commit 0812340811e45ec4039d409049be53056182a552 upstream. We can't use PATH_MAX for SMB symlinks because (1) Windows Server will fail FSCTL_SET_REPARSE_POINT with STATUS_IO_REPARSE_DATA_INVALID when input buffer is larger than 16K, as specified in MS-FSA 2.1.5.10.37. (2) The client won't be able to parse large SMB responses that includes SMB symlink path within SMB2_CREATE or SMB2_IOCTL responses. Fix this by defining a maximum length value (4060) for SMB symlinks that both client and server can handle. Cc: David Howells Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5fa30c58dd22d08eb1694a6eed3f7ae6e60767f0 Author: Steve French Date: Mon Nov 18 12:19:46 2024 -0600 smb3: request handle caching when caching directories commit 9ed9d83a51a9636d367c796252409e7b2f4de4d4 upstream. This client was only requesting READ caching, not READ and HANDLE caching in the LeaseState on the open requests we send for directories. To delay closing a handle (e.g. for caching directory contents) we should be requesting HANDLE as well as READ (as we already do for deferred close of files). See MS-SMB2 3.3.1.4 e.g. Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4f7a8d2e646aff216088a9b95a534326c7eafb20 Author: Takashi Iwai Date: Thu Nov 28 08:26:45 2024 +0100 ALSA: hda/realtek: Apply quirk for Medion E15433 commit ca0f79f0286046f6a91c099dc941cf7afae198d6 upstream. Medion E15433 laptop wich ALC269VC (SSID 2782:1705) needs the same workaround for the missing speaker as another model. Link: https://bugzilla.suse.com/show_bug.cgi?id=1233298 Cc: Link: https://patch.msgid.link/20241128072646.15659-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 11dd528ad6c67af026143f5cf35502f630e86824 Author: Dinesh Kumar Date: Mon Nov 25 14:58:42 2024 +0530 ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max commit 5ebe792a5139f1ce6e4aed22bef12e7e2660df96 upstream. Internal Speaker of Infinix Y4 Max remains muted due to incorrect Pin configuration, and the Internal Mic records high noise. This patch corrects the Pin configuration for the Internal Speaker and limits the Internal Mic boost. HW Probe for device: https://linux-hardware.org/?probe=6d4386c347 Test: Internal Speaker works fine, Mic has low noise. Signed-off-by: Dinesh Kumar Cc: Link: https://patch.msgid.link/20241125092842.13208-1-desikumar81@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cdee58d5ab0236523f76cc2f6ef9f94e66963f35 Author: Kailang Yang Date: Thu Nov 21 16:16:26 2024 +0800 ALSA: hda/realtek: Set PCBeep to default value for ALC274 commit 155699ccab7c78cbba69798242b68bc8ac66d5d2 upstream. BIOS Enable PC beep path cause pop noise via speaker during boot time. Set to default value from driver will solve the issue. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/2721bb57e20a44c3826c473e933f9105@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2a9356b724497e95555fc51a5040aed04b679b5f Author: Kailang Yang Date: Thu Nov 14 15:08:07 2024 +0800 ALSA: hda/realtek: Update ALC225 depop procedure commit 1fd50509fe14a9adc9329e0454b986157a4c155a upstream. Old procedure has a chance to meet Headphone no output. Fixes: da911b1f5e98 ("ALSA: hda/realtek - update ALC225 depop optimize") Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/5a27b016ba9d42b4a4e6dadce50a3ba4@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f0ce9e24eff1678c16276f9717f26a78202506a2 Author: Takashi Iwai Date: Wed Nov 20 15:11:02 2024 +0100 ALSA: pcm: Add sanity NULL check for the default mmap fault handler commit d2913a07d9037fe7aed4b7e680684163eaed6bc4 upstream. A driver might allow the mmap access before initializing its runtime->dma_area properly. Add a proper NULL check before passing to virt_to_page() for avoiding a panic. Reported-by: syzbot+4bf62a7b1d0f4fdb7ae2@syzkaller.appspotmail.com Cc: Link: https://patch.msgid.link/20241120141104.7060-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4c65e76b7ff0c54bfc7bff3abde951031aca68fc Author: Takashi Iwai Date: Wed Nov 27 08:00:58 2024 +0100 ALSA: ump: Fix evaluation of MIDI 1.0 FB info commit 7be34f6feedd60e418de1c2c48e661d70416635f upstream. The m1.0 field of UMP Function Block info specifies whether the given FB is a MIDI 1.0 port or not. When implementing the UMP support on Linux, I somehow interpreted as if it were bit flags, but the field is actually an enumeration from 0 to 2, where 2 means MIDI 1.0 *and* low speed. This patch corrects the interpretation and sets the right bit flags depending on the m1.0 field of FB Info. This effectively fixes the missing detection of MIDI 1.0 FB when m1.0 is 2. Fixes: 37e0e14128e0 ("ALSA: ump: Support UMP Endpoint and Function Block parsing") Cc: Link: https://patch.msgid.link/20241127070059.8099-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 237e7fa2c844280f469eca87d8d1e7d9d9fa1e8d Author: Takashi Iwai Date: Mon Nov 25 15:20:25 2024 +0100 ALSA: rawmidi: Fix kvfree() call in spinlock commit 20c0c49720dc4e205d4c1d64add56a5043c5ec5f upstream. At the conversion of locking with guard(), I overlooked that kvfree() must not be called inside the spinlock unlike kfree(), and this was caught by syzkaller now. This patch reverts the conversion partially for restoring the kvfree() call outside the spinlock. It's not trivial to use guard() in this context, unfortunately. Fixes: 84bb065b316e ("ALSA: rawmidi: Use guard() for locking") Reported-by: syzbot+351f8764833934c68836@syzkaller.appspotmail.com Reported-by: Eric Dumazet Closes: https://lore.kernel.org/6744737b.050a0220.1cc393.007e.GAE@google.com Cc: Link: https://patch.msgid.link/20241125142041.16578-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f68fb9f76c6b52de63c696e7e6e719d722e904f4 Author: Hans Verkuil Date: Mon Oct 14 16:52:41 2024 +0200 media: v4l2-core: v4l2-dv-timings: check cvt/gtf result commit 9f070b1862f3411b8bcdfd51a8eaad25286f9deb upstream. The v4l2_detect_cvt/gtf functions should check the result against the timing capabilities: these functions calculate the timings, so if they are out of bounds, they should be rejected. To do this, add the struct v4l2_dv_timings_cap as argument to those functions. This required updates to the adv7604 and adv7842 drivers since the prototype of these functions has now changed. The timings struct that is passed to v4l2_detect_cvt/gtf in those two drivers is filled with the timings detected by the hardware. The vivid driver was also updated, but an additional check was added: the width and height specified by VIDIOC_S_DV_TIMINGS has to match the calculated result, otherwise something went wrong. Note that vivid *emulates* hardware, so all the values passed to the v4l2_detect_cvt/gtf functions came from the timings struct that was filled by userspace and passed on to the driver via VIDIOC_S_DV_TIMINGS. So these fields can contain random data. Both the constraints check via struct v4l2_dv_timings_cap and the additional width/height check ensure that the resulting timings are sane and not messed up by the v4l2_detect_cvt/gtf calculations. Signed-off-by: Hans Verkuil Fixes: 2576415846bc ("[media] v4l2: move dv-timings related code to v4l2-dv-timings.c") Cc: stable@vger.kernel.org Reported-by: syzbot+a828133770f62293563e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-media/000000000000013050062127830a@google.com/ Signed-off-by: Greg Kroah-Hartman commit 8f489315e02dcee935efcd64e26a4f1b46a36eaa Author: Javier Carrasco Date: Sun Oct 13 15:29:17 2024 +0200 soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting() commit c9f1efabf8e3b3ff886a42669f7093789dbeca94 upstream. of_find_compatible_node() requires a call to of_node_put() when the pointer to the node is not required anymore to decrement its refcount and avoid leaking memory. Add the missing call to of_node_put() after the node has been used. Cc: stable@vger.kernel.org Fixes: e95f287deed2 ("soc: fsl: handle RCPM errata A-008646 on SoC LS1021A") Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20241013-rcpm-of_node_put-v1-1-9a8e55a01eae@gmail.com Signed-off-by: Christophe Leroy Signed-off-by: Greg Kroah-Hartman commit 8544602fb6cd5893996d014ce92b73a538a14e4d Author: Joe Damato Date: Thu Nov 14 17:51:56 2024 +0000 netdev-genl: Hold rcu_read_lock in napi_get commit c53bf100f68619acf6cedcf4cf5249a1ca2db0b4 upstream. Hold rcu_read_lock in netdev_nl_napi_get_doit, which calls napi_by_id and is required to be called under rcu_read_lock. Cc: stable@vger.kernel.org Fixes: 27f91aaf49b3 ("netdev-genl: Add netlink framework functions for napi") Signed-off-by: Joe Damato Link: https://patch.msgid.link/20241114175157.16604-1-jdamato@fastly.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7a9d083a7d1fe794e357e7b2dbfd2a2c184f4496 Author: Chen-Yu Tsai Date: Fri Oct 18 16:21:11 2024 +0800 arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes commit 26ea2459d1724406bf0b342df6b4b1f002d7f8e3 upstream. The Voltorb device uses a speaker codec different from the original Corsola device. When the Voltorb device tree was first added, the new codec was added as a separate node when it should have just replaced the existing one. Merge the two nodes. The only differences are the compatible string and the GPIO line property name. This keeps the device node path for the speaker codec the same across the MT8186 Chromebook line. Also rename the related labels and node names from having rt1019p to speaker codec. Cc: stable@vger.kernel.org # v6.11+ Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20241018082113.1297268-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Greg Kroah-Hartman commit ed4524c87249edc3104f6bb28ab11325bed3d536 Author: Stanislaw Gruszka Date: Thu Oct 31 11:23:21 2024 +0100 media: intel/ipu6: do not handle interrupts when device is disabled commit 1429826883bb18847092b2e04c6598ef34bae1d4 upstream. Some IPU6 devices have shared interrupts. We need to handle properly case when interrupt is triggered from other device on shared irq line and IPU6 itself disabled. In such case we get 0xffffffff from ISR_STATUS register and handle all irq's cases, for what we are not not prepared and usually hang the whole system. To avoid the issue use pm_runtime_get_if_active() to check if the device is enabled and prevent suspending it when we handle irq until the end of irq. Additionally use synchronize_irq() in suspend Fixes: ab29a2478e70 ("media: intel/ipu6: add IPU6 buttress interface driver") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Yoga Gen 8, ov2740 Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2e63c908de357048180516b84740ed62dac0b269 Author: Qiu-ji Chen Date: Fri Sep 27 16:39:02 2024 +0800 media: wl128x: Fix atomicity violation in fmc_send_cmd() commit ca59f9956d4519ab18ab2270be47c6b8c6ced091 upstream. Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev->resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev->resp_skb variable is assigned a null value. This results in an invalid fmdev->resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev->resp_skb; when the invalid fmdev->resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb->data; To address this issue, it is recommended to include the validity check of fmdev->resp_skb within the locked section of the function. This modification ensures that the value of fmdev->resp_skb does not change during the validation process, thereby maintaining its validity. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: e8454ff7b9a4 ("[media] drivers:media:radio: wl128x: FM Driver Common sources") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2f8cb07e1d6eefa1b41fa647808201c5cbeeaa3b Author: Peter Große Date: Wed Nov 13 13:07:04 2024 -0800 i40e: Fix handling changed priv flags commit ea301aec8bb718b02b68761d2229fc12c9fefa29 upstream. After assembling the new private flags on a PF, the operation to determine the changed flags uses the wrong bitmaps. Instead of xor-ing orig_flags with new_flags, it uses the still unchanged pf->flags, thus changed_flags is always 0. Fix it by using the correct bitmaps. The issue was discovered while debugging why disabling source pruning stopped working with release 6.7. Although the new flags will be copied to pf->flags later on in that function, disabling source pruning requires a reset of the PF, which was skipped due to this bug. Disabling source pruning: $ sudo ethtool --set-priv-flags eno1 disable-source-pruning on $ sudo ethtool --show-priv-flags eno1 Private flags for eno1: MFP : off total-port-shutdown : off LinkPolling : off flow-director-atr : on veb-stats : off hw-atr-eviction : off link-down-on-close : off legacy-rx : off disable-source-pruning: on disable-fw-lldp : off rs-fec : off base-r-fec : off vf-vlan-pruning : off Regarding reproducing: I observed the issue with a rather complicated lab setup, where * two VLAN interfaces are created on eno1 * each with a different MAC address assigned * each moved into a separate namespace * both VLANs are bridged externally, so they form a single layer 2 network The external bridge is done via a channel emulator adding packet loss and delay and the application in the namespaces tries to send/receive traffic and measure the performance. Sender and receiver are separated by namespaces, yet the network card "sees its own traffic" send back to it. To make that work, source pruning has to be disabled. Cc: stable@vger.kernel.org Fixes: 70756d0a4727 ("i40e: Use DECLARE_BITMAP for flags and hw_features fields in i40e_pf") Signed-off-by: Peter Große Reviewed-by: Paul Menzel Reviewed-by: Przemek Kitszel Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20241113210705.1296408-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c53004b59bb9636f4260fa0396f15bf0f2362259 Author: Jason Gerecke Date: Mon Oct 28 10:39:14 2024 -0700 HID: wacom: Interpret tilt data from Intuos Pro BT as signed values commit 49a397ad24ee5e2c53a59dada2780d7e71bd3f77 upstream. The tilt data contained in the Bluetooth packets of an Intuos Pro are supposed to be interpreted as signed values. Simply casting the values to type `char` is not guaranteed to work since it is implementation- defined whether it is signed or unsigned. At least one user has noticed the data being reported incorrectly on their system. To ensure that the data is interpreted properly, we specifically cast to `signed char` instead. Link: https://github.com/linuxwacom/input-wacom/issues/445 Fixes: 4922cd26f03c ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") CC: stable@vger.kernel.org # 4.11+ Signed-off-by: Jason Gerecke Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 9d63c0eeddc2636109087b27e34fd8cf829c0721 Author: Ziwei Xiao Date: Wed Nov 13 09:59:30 2024 -0800 gve: Flow steering trigger reset only for timeout error commit 8ffade77b6337a8767fae9820d57d7a6413dd1a1 upstream. When configuring flow steering rules, the driver is currently going through a reset for all errors from the device. Instead, the driver should only reset when there's a timeout error from the device. Fixes: 57718b60df9b ("gve: Add flow steering adminq commands") Cc: stable@vger.kernel.org Signed-off-by: Ziwei Xiao Signed-off-by: Jeroen de Borst Reviewed-by: Harshitha Ramamurthy Reviewed-by: Simon Horman Link: https://patch.msgid.link/20241113175930.2585680-1-jeroendb@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 20ff0fe1c8a23a0a7b1751033e62737a5b64f20e Author: Bart Van Assche Date: Tue Oct 22 11:16:17 2024 -0700 blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long commit ccd9e252c515ac5a3ed04a414c95d1307d17f159 upstream. Make sure that the tag_list_lock mutex is not held any longer than necessary. This change reduces latency if e.g. blk_mq_quiesce_tagset() is called concurrently from more than one thread. This function is used by the NVMe core and also by the UFS driver. Reported-by: Peter Wang Cc: Chao Leng Cc: Ming Lei Cc: stable@vger.kernel.org Fixes: 414dd48e882c ("blk-mq: add tagset quiesce interface") Signed-off-by: Bart Van Assche Reviewed-by: Keith Busch Link: https://lore.kernel.org/r/20241022181617.2716173-1-bvanassche@acm.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit aaab132bb2bf97bdd5c73c87c23c1340fbed1477 Author: Muchun Song Date: Mon Oct 14 17:29:34 2024 +0800 block: fix ordering between checking BLK_MQ_S_STOPPED request adding commit 96a9fe64bfd486ebeeacf1e6011801ffe89dae18 upstream. Supposing first scenario with a virtio_blk driver. CPU0 CPU1 blk_mq_try_issue_directly() __blk_mq_issue_directly() q->mq_ops->queue_rq() virtio_queue_rq() blk_mq_stop_hw_queue() virtblk_done() blk_mq_request_bypass_insert() 1) store blk_mq_start_stopped_hw_queue() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load return __blk_mq_sched_dispatch_requests() Supposing another scenario. CPU0 CPU1 blk_mq_requeue_work() blk_mq_insert_request() 1) store virtblk_done() blk_mq_start_stopped_hw_queue() blk_mq_run_hw_queues() clear_bit(BLK_MQ_S_STOPPED) 3) store blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_sched_dispatch_requests() if (blk_mq_hctx_stopped()) 2) load continue blk_mq_run_hw_queue() Both scenarios are similar, the full memory barrier should be inserted between 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees BLK_MQ_S_STOPPED is cleared or CPU1 sees dispatch list. Otherwise, either CPU will not rerun the hardware queue causing starvation of the request. The easy way to fix it is to add the essential full memory barrier into helper of blk_mq_hctx_stopped(). In order to not affect the fast path (hardware queue is not stopped most of the time), we only insert the barrier into the slow path. Actually, only slow path needs to care about missing of dispatching the request to the low-level device driver. Fixes: 320ae51feed5 ("blk-mq: new multi-queue block IO queueing mechanism") Cc: stable@vger.kernel.org Cc: Muchun Song Signed-off-by: Muchun Song Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241014092934.53630-4-songmuchun@bytedance.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3d2fd8163620b2f62163d0f9931091f8dca75b95 Author: Muchun Song Date: Mon Oct 14 17:29:33 2024 +0800 block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding commit 6bda857bcbb86fb9d0e54fbef93a093d51172acc upstream. Supposing the following scenario. CPU0 CPU1 blk_mq_insert_request() 1) store blk_mq_unquiesce_queue() blk_queue_flag_clear() 3) store blk_mq_run_hw_queues() blk_mq_run_hw_queue() if (!blk_mq_hctx_has_pending()) 4) load return blk_mq_run_hw_queue() if (blk_queue_quiesced()) 2) load return blk_mq_sched_dispatch_requests() The full memory barrier should be inserted between 1) and 2), as well as between 3) and 4) to make sure that either CPU0 sees QUEUE_FLAG_QUIESCED is cleared or CPU1 sees dispatch list or setting of bitmap of software queue. Otherwise, either CPU will not rerun the hardware queue causing starvation. So the first solution is to 1) add a pair of memory barrier to fix the problem, another solution is to 2) use hctx->queue->queue_lock to synchronize QUEUE_FLAG_QUIESCED. Here, we chose 2) to fix it since memory barrier is not easy to be maintained. Fixes: f4560ffe8cec ("blk-mq: use QUEUE_FLAG_QUIESCED to quiesce queue") Cc: stable@vger.kernel.org Cc: Muchun Song Signed-off-by: Muchun Song Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241014092934.53630-3-songmuchun@bytedance.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dc43bdcfb3a9f332aa2b49803c977715b7c97a30 Author: Muchun Song Date: Mon Oct 14 17:29:32 2024 +0800 block: fix missing dispatching request when queue is started or unquiesced commit 2003ee8a9aa14d766b06088156978d53c2e9be3d upstream. Supposing the following scenario with a virtio_blk driver. CPU0 CPU1 CPU2 blk_mq_try_issue_directly() __blk_mq_issue_directly() q->mq_ops->queue_rq() virtio_queue_rq() blk_mq_stop_hw_queue() virtblk_done() blk_mq_try_issue_directly() if (blk_mq_hctx_stopped()) blk_mq_request_bypass_insert() blk_mq_run_hw_queue() blk_mq_run_hw_queue() blk_mq_run_hw_queue() blk_mq_insert_request() return After CPU0 has marked the queue as stopped, CPU1 will see the queue is stopped. But before CPU1 puts the request on the dispatch list, CPU2 receives the interrupt of completion of request, so it will run the hardware queue and marks the queue as non-stopped. Meanwhile, CPU1 also runs the same hardware queue. After both CPU1 and CPU2 complete blk_mq_run_hw_queue(), CPU1 just puts the request to the same hardware queue and returns. It misses dispatching a request. Fix it by running the hardware queue explicitly. And blk_mq_request_issue_directly() should handle a similar situation. Fix it as well. Fixes: d964f04a8fde ("blk-mq: fix direct issue") Cc: stable@vger.kernel.org Cc: Muchun Song Signed-off-by: Muchun Song Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20241014092934.53630-2-songmuchun@bytedance.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 823202251b60ea1f3331c2eaf6f2d838359e8aa0 Author: Will Deacon Date: Thu Nov 14 09:53:32 2024 +0000 arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled commit 67ab51cbdfee02ef07fb9d7d14cc0bf6cb5a5e5c upstream. Commit 18011eac28c7 ("arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks") tried to optimise the context switching of tpidrro_el0 by eliding the clearing of the register when switching to a native task with kpti enabled, on the erroneous assumption that the kpti trampoline entry code would already have taken care of the write. Although the kpti trampoline does zero the register on entry from a native task, the check in tls_thread_switch() is on the *next* task and so we can end up leaving a stale, non-zero value in the register if the previous task was 32-bit. Drop the broken optimisation and zero tpidrro_el0 unconditionally when switching to a native 64-bit task. Cc: Mark Rutland Cc: stable@vger.kernel.org Fixes: 18011eac28c7 ("arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks") Signed-off-by: Will Deacon Acked-by: Mark Rutland Link: https://lore.kernel.org/r/20241114095332.23391-1-will@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 64e048f08c49f2cfc22e01c671c7a150c6494d79 Author: Ming Lei Date: Mon Nov 11 19:07:18 2024 +0800 ublk: fix ublk_ch_mmap() for 64K page size commit d369735e02ef122d19d4c3d093028da0eb400636 upstream. In ublk_ch_mmap(), queue id is calculated in the following way: (vma->vm_pgoff << PAGE_SHIFT) / `max_cmd_buf_size` 'max_cmd_buf_size' is equal to `UBLK_MAX_QUEUE_DEPTH * sizeof(struct ublksrv_io_desc)` and UBLK_MAX_QUEUE_DEPTH is 4096 and part of UAPI, so 'max_cmd_buf_size' is always page aligned in 4K page size kernel. However, it isn't true in 64K page size kernel. Fixes the issue by always rounding up 'max_cmd_buf_size' with PAGE_SIZE. Cc: stable@vger.kernel.org Fixes: 71f28f3136af ("ublk_drv: add io_uring based userspace block driver") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20241111110718.1394001-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 4f32048b05f7ff5c4855a35778c21b2ed7fbc558 Author: Zicheng Qu Date: Thu Oct 31 01:45:05 2024 +0000 iio: gts: Fix uninitialized symbol 'ret' commit e2fb2f89faf87b681038475d093214f4cbe12ebb upstream. Initialize the variable ret at the time of declaration to prevent it from being returned without a defined value. Fixes smatch warning: drivers/iio/industrialio-gts-helper.c:256 gain_to_scaletables() error: uninitialized symbol 'ret'. Cc: stable@vger.kernel.org # v6.6+ Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers") Signed-off-by: Zicheng Qu Reviewed-by: Matti Vaittinen Link: https://patch.msgid.link/20241031014505.2313035-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 39373f6f89f52770a5405d30dddd08a27d097872 Author: Huacai Chen Date: Thu Jul 14 16:41:36 2022 +0800 sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK commit 3c891f7c6a4e90bb1199497552f24b26e46383bc upstream. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning similar as below when showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Reviewed-by: John Paul Adrian Glaubitz Tested-by: John Paul Adrian Glaubitz Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Greg Kroah-Hartman commit e9d36f7e71a907ec507f84ee5d60a622c345cac4 Author: Tiwei Bie Date: Tue Nov 5 00:32:03 2024 +0800 um: vector: Do not use drvdata in release commit 51b39d741970742a5c41136241a9c48ac607cf82 upstream. The drvdata is not available in release. Let's just use container_of() to get the vector_device instance. Otherwise, removing a vector device will result in a crash: RIP: 0033:vector_device_release+0xf/0x50 RSP: 00000000e187bc40 EFLAGS: 00010202 RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 60028f61 623ae028 e187bc80 60276fcd 6220b9c0 603f5820 623ae028 00000000 e187bcb0 603a2bcd 623ae000 62370010 Call Trace: [<60028f61>] ? vector_device_release+0x0/0x50 [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<60029422>] vector_remove+0x52/0x58 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<603b19f4>] ? strlen+0x0/0x15 [<60066611>] ? __dequeue_entity+0x1a9/0x206 [<600666a7>] ? set_next_entity+0x39/0x63 [<6006666e>] ? set_next_entity+0x0/0x63 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6 Cc: stable@vger.kernel.org Signed-off-by: Tiwei Bie Acked-By: Anton Ivanov Link: https://patch.msgid.link/20241104163203.435515-5-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 4c72fd692ab17c0aebd66fe56bf9f7840c99ef42 Author: Damien Le Moal Date: Tue Nov 26 19:47:05 2024 +0900 block: Prevent potential deadlock in blk_revalidate_disk_zones() commit 0b83c86b444ab467134b0e618f45ad2216a4973c upstream. The function blk_revalidate_disk_zones() calls the function disk_update_zone_resources() after freezing the device queue. In turn, disk_update_zone_resources() calls queue_limits_start_update() which takes a queue limits mutex lock, resulting in the ordering: q->q_usage_counter check -> q->limits_lock. However, the usual ordering is to always take a queue limit lock before freezing the queue to commit the limits updates, e.g., the code pattern: lim = queue_limits_start_update(q); ... blk_mq_freeze_queue(q); ret = queue_limits_commit_update(q, &lim); blk_mq_unfreeze_queue(q); Thus, blk_revalidate_disk_zones() introduces a potential circular locking dependency deadlock that lockdep sometimes catches with the splat: [ 51.934109] ====================================================== [ 51.935916] WARNING: possible circular locking dependency detected [ 51.937561] 6.12.0+ #2107 Not tainted [ 51.938648] ------------------------------------------------------ [ 51.940351] kworker/u16:4/157 is trying to acquire lock: [ 51.941805] ffff9fff0aa0bea8 (&q->limits_lock){+.+.}-{4:4}, at: disk_update_zone_resources+0x86/0x170 [ 51.944314] but task is already holding lock: [ 51.945688] ffff9fff0aa0b890 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: blk_revalidate_disk_zones+0x15f/0x340 [ 51.948527] which lock already depends on the new lock. [ 51.951296] the existing dependency chain (in reverse order) is: [ 51.953708] -> #1 (&q->q_usage_counter(queue)#3){++++}-{0:0}: [ 51.956131] blk_queue_enter+0x1c9/0x1e0 [ 51.957290] blk_mq_alloc_request+0x187/0x2a0 [ 51.958365] scsi_execute_cmd+0x78/0x490 [scsi_mod] [ 51.959514] read_capacity_16+0x111/0x410 [sd_mod] [ 51.960693] sd_revalidate_disk.isra.0+0x872/0x3240 [sd_mod] [ 51.962004] sd_probe+0x2d7/0x520 [sd_mod] [ 51.962993] really_probe+0xd5/0x330 [ 51.963898] __driver_probe_device+0x78/0x110 [ 51.964925] driver_probe_device+0x1f/0xa0 [ 51.965916] __driver_attach_async_helper+0x60/0xe0 [ 51.967017] async_run_entry_fn+0x2e/0x140 [ 51.968004] process_one_work+0x21f/0x5a0 [ 51.968987] worker_thread+0x1dc/0x3c0 [ 51.969868] kthread+0xe0/0x110 [ 51.970377] ret_from_fork+0x31/0x50 [ 51.970983] ret_from_fork_asm+0x11/0x20 [ 51.971587] -> #0 (&q->limits_lock){+.+.}-{4:4}: [ 51.972479] __lock_acquire+0x1337/0x2130 [ 51.973133] lock_acquire+0xc5/0x2d0 [ 51.973691] __mutex_lock+0xda/0xcf0 [ 51.974300] disk_update_zone_resources+0x86/0x170 [ 51.975032] blk_revalidate_disk_zones+0x16c/0x340 [ 51.975740] sd_zbc_revalidate_zones+0x73/0x160 [sd_mod] [ 51.976524] sd_revalidate_disk.isra.0+0x465/0x3240 [sd_mod] [ 51.977824] sd_probe+0x2d7/0x520 [sd_mod] [ 51.978917] really_probe+0xd5/0x330 [ 51.979915] __driver_probe_device+0x78/0x110 [ 51.981047] driver_probe_device+0x1f/0xa0 [ 51.982143] __driver_attach_async_helper+0x60/0xe0 [ 51.983282] async_run_entry_fn+0x2e/0x140 [ 51.984319] process_one_work+0x21f/0x5a0 [ 51.985873] worker_thread+0x1dc/0x3c0 [ 51.987289] kthread+0xe0/0x110 [ 51.988546] ret_from_fork+0x31/0x50 [ 51.989926] ret_from_fork_asm+0x11/0x20 [ 51.991376] other info that might help us debug this: [ 51.994127] Possible unsafe locking scenario: [ 51.995651] CPU0 CPU1 [ 51.996694] ---- ---- [ 51.997716] lock(&q->q_usage_counter(queue)#3); [ 51.998817] lock(&q->limits_lock); [ 52.000043] lock(&q->q_usage_counter(queue)#3); [ 52.001638] lock(&q->limits_lock); [ 52.002485] *** DEADLOCK *** Prevent this issue by moving the calls to blk_mq_freeze_queue() and blk_mq_unfreeze_queue() around the call to queue_limits_commit_update() in disk_update_zone_resources(). In case of revalidation failure, the call to disk_free_zone_resources() in blk_revalidate_disk_zones() is still done with the queue frozen as before. Fixes: 843283e96e5a ("block: Fake max open zones limit when there is no limit") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20241126104705.183996-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ca4f3c525937e3c72bd4867965901954bb4b17e2 Author: Javier Carrasco Date: Sat Oct 19 22:27:03 2024 +0200 mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode() commit 07593293ffabba14125c8998525adde5a832bfa3 upstream. The 'fw_vols' fwnode_handle initialized via device_get_named_child_node() requires explicit calls to fwnode_handle_put() when the variable is no longer required. Add the missing calls to fwnode_handle_put() before the function returns. Cc: stable@vger.kernel.org Fixes: 51932f9fc487 ("mtd: ubi: populate ubi volume fwnode") Signed-off-by: Javier Carrasco Reviewed-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit cdc87d2f39698f1ba7e3bd634779a6252418fede Author: Arnd Bergmann Date: Fri Nov 15 11:59:54 2024 +0100 serial: amba-pl011: fix build regression commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream. When CONFIG_DMA_ENGINE is disabled, the driver now fails to build: drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx': drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma' 1822 | if (uap->using_rx_dma) { | ^~ drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr' 1823 | uap->dmacr |= UART011_RXDMAE; | ^~ drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr' 1824 | pl011_write(uap->dmacr, uap, REG_DMACR); | ^~ Add the missing #ifdef check around these field accesses, matching what other parts of this driver do. Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used") Cc: stable Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/ Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 34f639363218862364f6866fca6e7d7f3d0dd982 Author: Kartik Rajput Date: Wed Nov 13 14:56:29 2024 +0530 serial: amba-pl011: Fix RX stall when DMA is used commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf upstream. Function pl011_throttle_rx() calls pl011_stop_rx() to disable RX, which also disables the RX DMA by clearing the RXDMAE bit of the DMACR register. However, to properly unthrottle RX when DMA is used, the function pl011_unthrottle_rx() is expected to set the RXDMAE bit of the DMACR register, which it currently lacks. This causes RX to stall after the throttle API is called. Set RXDMAE bit in the DMACR register while unthrottling RX if RX DMA is used. Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle") Cc: stable@vger.kernel.org Signed-off-by: Kartik Rajput Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 1a32f622e38be96f1a6b31b50ffd0a1acf246c93 Author: Bin Liu Date: Thu Oct 31 12:23:15 2024 -0500 serial: 8250: omap: Move pm_runtime_get_sync commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream. Currently in omap_8250_shutdown, the dma->rx_running flag is set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync is called, which is a runtime resume call stack which can re-set the flag. When the call omap_8250_shutdown returns, the flag is expected to be UN-SET, but this is not the case. This is causing issues the next time UART is re-opened and omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync before the omap_8250_rx_dma_flush. cc: stable@vger.kernel.org Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") Signed-off-by: Bin Liu [Judith: Add commit message] Signed-off-by: Judith Mendez Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com Signed-off-by: Greg Kroah-Hartman commit cb35238c333911bb7b07d37a29fca1fbcfee1e75 Author: Filip Brozovic Date: Sun Nov 10 12:17:00 2024 +0100 serial: 8250_fintek: Add support for F81216E commit 166105c9030a30ba08574a9998afc7b60bc72dd7 upstream. The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with the F81216H, but does not support RS-485 auto-direction delays on any port. Signed-off-by: Filip Brozovic Cc: stable Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com Signed-off-by: Greg Kroah-Hartman commit f3d370fd0aa61ebf875d4e71708d525506dbfd9e Author: Michal Simek Date: Mon Sep 16 11:53:06 2024 +0200 dt-bindings: serial: rs485: Fix rs485-rts-delay property commit 12b3642b6c242061d3ba84e6e3050c3141ded14c upstream. Code expects array only with 2 items which should be checked. But also item checking is not working as it should likely because of incorrect items description. Fixes: d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema") Signed-off-by: Michal Simek Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com Signed-off-by: Greg Kroah-Hartman commit 468c2e5394afc848efb1eae6e1961a3c855cf35e Author: Tiwei Bie Date: Tue Nov 5 00:32:02 2024 +0800 um: net: Do not use drvdata in release commit d1db692a9be3b4bd3473b64fcae996afaffe8438 upstream. The drvdata is not available in release. Let's just use container_of() to get the uml_net instance. Otherwise, removing a network device will result in a crash: RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6 Cc: stable@vger.kernel.org Signed-off-by: Tiwei Bie Acked-By: Anton Ivanov Link: https://patch.msgid.link/20241104163203.435515-4-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit e6e5a4cded9bef3a1b0a4fac815b7176eb9a18ec Author: Tiwei Bie Date: Tue Nov 5 00:32:01 2024 +0800 um: ubd: Do not use drvdata in release commit 5bee35e5389f450a7eea7318deb9073e9414d3b1 upstream. The drvdata is not available in release. Let's just use container_of() to get the ubd instance. Otherwise, removing a ubd device will result in a crash: RIP: 0033:blk_mq_free_tag_set+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Kernel panic - not syncing: Segfault with no mm CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1 Workqueue: events mc_work_proc Stack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0 Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? mconsole_reply+0x48/0x50 [<6003379c>] ? um_set_signals+0x3b/0x43 [<60061c55>] ? update_min_vruntime+0x14/0x70 [<6006251f>] ? dequeue_task_fair+0x164/0x235 [<600620aa>] ? update_cfs_group+0x0/0x40 [<603a0e77>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] process_scheduled_works+0x1af/0x2c3 [<6004ede3>] ? assign_work+0x0/0x58 [<600527a1>] worker_thread+0x2f7/0x37a [<6004ee3b>] ? set_pf_worker+0x0/0x64 [<6005765d>] ? arch_local_irq_save+0x0/0x2d [<60058e07>] ? kthread_exit+0x0/0x3a [<600524aa>] ? worker_thread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] new_thread_handler+0x85/0xb6 Cc: stable@vger.kernel.org Signed-off-by: Tiwei Bie Acked-By: Anton Ivanov Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 58b1e84886a0c1ae6b49b006e6b9198b555281e5 Author: Zhihao Cheng Date: Mon Aug 19 11:26:21 2024 +0800 ubi: wl: Put source PEB into correct list if trying locking LEB failed commit d610020f030bec819f42de327c2bd5437d2766b3 upstream. During wear-leveing work, the source PEB will be moved into scrub list when source LEB cannot be locked in ubi_eba_copy_leb(), which is wrong for non-scrub type source PEB. The problem could bring extra and ineffective wear-leveing jobs, which makes more or less negative effects for the life time of flash. Specifically, the process is divided 2 steps: 1. wear_leveling_worker // generate false scrub type PEB ubi_eba_copy_leb // MOVE_RETRY is returned leb_write_trylock // trylock failed scrubbing = 1; e1 is put into ubi->scrub 2. wear_leveling_worker // schedule false scrub type PEB for wl scrubbing = 1 e1 = rb_entry(rb_first(&ubi->scrub)) The problem can be reproduced easily by running fsstress on a small UBIFS partition(<64M, simulated by nandsim) for 5~10mins (CONFIG_MTD_UBI_FASTMAP=y,CONFIG_MTD_UBI_WL_THRESHOLD=50). Following message is shown: ubi0: scrubbed PEB 66 (LEB 0:10), data moved to PEB 165 Since scrub type source PEB has set variable scrubbing as '1', and variable scrubbing is checked before variable keep, so the problem can be fixed by setting keep variable as 1 directly if the source LEB cannot be locked. Fixes: e801e128b220 ("UBI: fix missing scrub when there is a bit-flip") CC: stable@vger.kernel.org Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 82d6b82cf89d950982ac240ba068c3a7e1f23b0a Author: Sebastian Andrzej Siewior Date: Tue Nov 26 14:47:22 2024 +0100 x86/CPU/AMD: Terminate the erratum_1386_microcode array commit ff6cdc407f4179748f4673c39b0921503199a0ad upstream. The erratum_1386_microcode array requires an empty entry at the end. Otherwise x86_match_cpu_with_stepping() will continue iterate the array after it ended. Add an empty entry to erratum_1386_microcode to its end. Fixes: 29ba89f189528 ("x86/CPU/AMD: Improve the erratum 1386 workaround") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Borislav Petkov (AMD) Cc: Link: https://lore.kernel.org/r/20241126134722.480975-1-bigeasy@linutronix.de Signed-off-by: Greg Kroah-Hartman commit ed9f9941d642d41ffe3a0069cee6bdbff3887b30 Author: Russell King (Oracle) Date: Thu Nov 21 12:48:25 2024 +0000 irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain commit 12aaf67584cf19dc84615b7aba272fe642c35b8b upstream. Commit fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") introduced in v6.11-rc1 broke Mavell Armada platforms (and possibly others) by incorrectly switching irq-mvebu-sei to MSI parent. In the above commit, msi_parent_ops is set for the sei->cp_domain, but rather than adding a .select method to mvebu_sei_cp_domain_ops (which is associated with sei->cp_domain), it was added to mvebu_sei_domain_ops which is associated with sei->sei_domain, which doesn't have any msi_parent_ops. This makes the call to msi_lib_irq_domain_select() always fail. This bug manifests itself with the following kernel messages on Armada 8040 based systems: platform f21e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) platform f41e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) Move the select callback to mvebu_sei_cp_domain_ops to cure it. Fixes: fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") Signed-off-by: Russell King (Oracle) Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/E1tE6bh-004CmX-QU@rmk-PC.armlinux.org.uk Signed-off-by: Greg Kroah-Hartman commit 5db44226b6fce7d2f49bd99529d40084f48ce82e Author: Javier Carrasco Date: Sun Oct 13 15:20:24 2024 +0200 platform/chrome: cros_ec_typec: fix missing fwnode reference decrement commit 9c41f371457bd9a24874e3c7934d9745e87fbc58 upstream. The device_for_each_child_node() macro requires explicit calls to fwnode_handle_put() upon early exits (return, break, goto) to decrement the fwnode's refcount, and avoid levaing a node reference behind. Add the missing fwnode_handle_put() after the common label for all error paths. Cc: stable@vger.kernel.org Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver") Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20241013-cross_ec_typec_fwnode_handle_put-v2-1-9182b2cd7767@gmail.com Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman commit 22127c1dc04364cda3da812161e70921e6c3c0af Author: Paulo Alcantara Date: Mon Nov 25 17:17:23 2024 -0300 smb: client: fix NULL ptr deref in crypto_aead_setkey() commit 4bdec0d1f658f7c98749bd2c5a486e6cfa8565d2 upstream. Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher. See MS-SMB2 3.3.5.4. Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") added a @server->cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server->cipher_type is unset for SMB3.02. Fix the following KASAN splat by setting @server->cipher_type for SMB3.02 as well. mount.cifs //srv/share /mnt -o vers=3.02,seal,... BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cc: Tom Talpey Reported-by: Jianhong Yin Cc: stable@vger.kernel.org # v6.12 Fixes: b0abcd65ec54 ("smb: client: fix UAF in async decryption") Signed-off-by: Paulo Alcantara (Red Hat) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f20b77f7897e6aab9ce5527e6016ad2be5d70a33 Author: Yunseong Kim Date: Mon Nov 25 16:45:55 2024 +0900 ksmbd: fix use-after-free in SMB request handling commit 9a8c5d89d327ff58e9b2517f8a6afb4181d32c6e upstream. A race condition exists between SMB request handling in `ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the workqueue handler `handle_ksmbd_work()`. This leads to a UAF. - KASAN: slab-use-after-free Read in handle_ksmbd_work - KASAN: slab-use-after-free in rtlock_slowlock_locked This race condition arises as follows: - `ksmbd_conn_handler_loop()` waits for `conn->r_count` to reach zero: `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);` - Meanwhile, `handle_ksmbd_work()` decrements `conn->r_count` using `atomic_dec_return(&conn->r_count)`, and if it reaches zero, calls `ksmbd_conn_free()`, which frees `conn`. - However, after `handle_ksmbd_work()` decrements `conn->r_count`, it may still access `conn->r_count_q` in the following line: `waitqueue_active(&conn->r_count_q)` or `wake_up(&conn->r_count_q)` This results in a UAF, as `conn` has already been freed. The discovery of this UAF can be referenced in the following PR for syzkaller's support for SMB requests. Link: https://github.com/google/syzkaller/pull/5524 Fixes: ee426bfb9d09 ("ksmbd: add refcnt to ksmbd_conn struct") Cc: linux-cifs@vger.kernel.org Cc: stable@vger.kernel.org # v6.6.55+, v6.10.14+, v6.11.3+ Cc: syzkaller@googlegroups.com Signed-off-by: Yunseong Kim Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 7f30f9c2cb884c71724fb3f3c3813aff79b23c4f Author: Jesse Taube Date: Thu Oct 17 12:00:18 2024 -0700 RISC-V: Check scalar unaligned access on all CPUs commit 8d20a739f17a2de9e269db72330f5655d6545dd4 upstream. Originally, the check_unaligned_access_emulated_all_cpus function only checked the boot hart. This fixes the function to check all harts. Fixes: 71c54b3d169d ("riscv: report misaligned accesses emulation to hwprobe") Signed-off-by: Jesse Taube Reviewed-by: Charlie Jenkins Reviewed-by: Evan Green Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241017-jesse_unaligned_vector-v10-1-5b33500160f8@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 455d6128ffcf36bbb1e1e05cd8b592a9a6001a72 Author: Jesse Taube Date: Thu Oct 17 12:00:19 2024 -0700 RISC-V: Scalar unaligned access emulated on hotplug CPUs commit 9c528b5f7927b857b40f3c46afbc869827af3c94 upstream. The check_unaligned_access_emulated() function should have been called during CPU hotplug to ensure that if all CPUs had emulated unaligned accesses, the new CPU also does. This patch adds the call to check_unaligned_access_emulated() in the hotplug path. Fixes: 55e0bf49a0d0 ("RISC-V: Probe misaligned access speed in parallel") Signed-off-by: Jesse Taube Reviewed-by: Evan Green Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241017-jesse_unaligned_vector-v10-2-5b33500160f8@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 65e0b741cc9d005a7649907dcf016d5b359b64d4 Author: Josh Poimboeuf Date: Wed Oct 2 14:32:04 2024 -0700 parisc/ftrace: Fix function graph tracing disablement commit a5f05a138a8cac035bf9da9b6ed0e532bc7942c8 upstream. Due to an apparent copy-paste bug, the parisc implementation of ftrace_disable_ftrace_graph_caller() doesn't actually do anything. It enables the (already-enabled) static key rather than disabling it. The result is that after function graph tracing has been "disabled", any subsequent (non-graph) function tracing will inadvertently also enable the slow fgraph return address hijacking. Fixes: 98f2926171ae ("parisc/ftrace: use static key to enable/disable function graph tracer") Cc: stable@vger.kernel.org # 5.16+ Signed-off-by: Josh Poimboeuf Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 8692643bc736419d5699891d5a87187d298ee84c Author: Meetakshi Setiya Date: Wed Oct 30 05:37:21 2024 -0400 cifs: support mounting with alternate password to allow password rotation commit b9aef1b13a0a92aa7058ba235afb24b5b89153ca upstream. Fixes the case for example where the password specified on mount is a recently expired password, but password2 is valid. Without this patch this mount scenario would fail. This patch introduces the following changes to support password rotation on mount: 1. If an existing session is not found and the new session setup results in EACCES, EKEYEXPIRED or EKEYREVOKED, swap password and password2 (if available), and retry the mount. 2. To match the new mount with an existing session, add conditions to check if a) password and password2 of the new mount and the existing session are the same, or b) password of the new mount is the same as the password2 of the existing session, and password2 of the new mount is the same as the password of the existing session. 3. If an existing session is found, but needs reconnect, retry the session setup after swapping password and password2 (if available), in case the previous attempt results in EACCES, EKEYEXPIRED or EKEYREVOKED. Cc: stable@vger.kernel.org Signed-off-by: Meetakshi Setiya Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2220bb358ef6b6047012153b3b96a4246f974a0d Author: Jinjie Ruan Date: Thu Nov 7 19:38:41 2024 +0800 cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power() commit 172bf5ed04cb6c9e66d58de003938ed5c8756570 upstream. mtk_cpufreq_get_cpu_power() return 0 if the policy is NULL. Then in em_create_perf_table(), the later zero check for power is not invalid as power is uninitialized. As Lukasz suggested, it must return -EINVAL when the 'policy' is not found. So return -EINVAL to fix it. Cc: stable@vger.kernel.org Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW") Reviewed-by: Lukasz Luba Suggested-by: Lukasz Luba Signed-off-by: Jinjie Ruan Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 487db736d7c3bdd8726a9b6fe1aa0c5f8c2ba8a4 Author: Cheng Ming Lin Date: Tue Nov 12 15:52:42 2024 +0800 mtd: spi-nor: core: replace dummy buswidth from addr to data commit 98d1fb94ce75f39febd456d6d3cbbe58b6678795 upstream. The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Cc: stable@vger.kernel.org Reviewed-by: Pratyush Yadav Signed-off-by: Cheng Ming Lin Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com Signed-off-by: Tudor Ambarus Signed-off-by: Greg Kroah-Hartman commit 5a0e8a1c2be539716cbaeb211f949e54310a6109 Author: Stanislaw Gruszka Date: Fri Nov 22 10:42:24 2024 +0100 spi: Fix acpi deferred irq probe commit d24cfee7f63d6b44d45a67c5662bd1cc48e8b3ca upstream. When probing spi device take care of deferred probe of ACPI irq gpio similar like for OF/DT case. >From practical standpoint this fixes issue with vsc-tp driver on Dell XP 9340 laptop, which try to request interrupt with spi->irq equal to -EPROBE_DEFER and fail to probe with the following error: vsc-tp spi-INTC10D0:00: probe with driver vsc-tp failed with error -22 Suggested-by: Hans de Goede Fixes: 33ada67da352 ("ACPI / spi: attach GPIO IRQ from ACPI description to SPI device") Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka Reviewed-by: Hans de Goede Tested-by: Alexis Lothoré # Dell XPS9320, ov01a10 Link: https://patch.msgid.link/20241122094224.226773-1-stanislaw.gruszka@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 591efa494a1cf649f50a35def649c43ae984cd03 Author: Jeongjun Park Date: Wed Nov 13 22:02:09 2024 +0900 netfilter: ipset: add missing range check in bitmap_ip_uadt commit 35f56c554eb1b56b77b3cf197a6b00922d49033d upstream. When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. Cc: Reported-by: syzbot+58c872f7790a4d2ac951@syzkaller.appspotmail.com Fixes: 72205fc68bd1 ("netfilter: ipset: bitmap:ip set type support") Signed-off-by: Jeongjun Park Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e0c8cf450d7b0c75b31f63aa0c63bae3bb885ade Author: Sai Kumar Cholleti Date: Tue Nov 5 12:45:23 2024 +0530 gpio: exar: set value when external pull-up or pull-down is present commit 72cef64180de04a7b055b4773c138d78f4ebdb77 upstream. Setting GPIO direction = high, sometimes results in GPIO value = 0. If a GPIO is pulled high, the following construction results in the value being 0 when the desired value is 1: $ echo "high" > /sys/class/gpio/gpio336/direction $ cat /sys/class/gpio/gpio336/value 0 Before the GPIO direction is changed from an input to an output, exar_set_value() is called with value = 1, but since the GPIO is an input when exar_set_value() is called, _regmap_update_bits() reads a 1 due to an external pull-up. regmap_set_bits() sets force_write = false, so the value (1) is not written. When the direction is then changed, the GPIO becomes an output with the value of 0 (the hardware default). regmap_write_bits() sets force_write = true, so the value is always written by exar_set_value() and an external pull-up doesn't affect the outcome of setting direction = high. The same can happen when a GPIO is pulled low, but the scenario is a little more complicated. $ echo high > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 $ echo in > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 0 $ echo low > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1 Fixes: 36fb7218e878 ("gpio: exar: switch to using regmap") Co-developed-by: Matthew McClain Signed-off-by: Matthew McClain Signed-off-by: Sai Kumar Cholleti Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241105071523.2372032-1-skmr537@gmail.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman commit 3d27b416e734408bc502799a72f62d69cd8a9858 Author: Mikulas Patocka Date: Mon Nov 18 15:52:50 2024 +0100 blk-settings: round down io_opt to physical_block_size commit 9c0ba14828d64744ccd195c610594ba254a1a9ab upstream. There was a bug report [1] where the user got a warning alignment inconsistency. The user has optimal I/O 16776704 (0xFFFE00) and physical block size 4096. Note that the optimal I/O size may be set by the DMA engines or SCSI controllers and they have no knowledge about the disks attached to them, so the situation with optimal I/O not aligned to physical block size may happen. This commit makes blk_validate_limits round down optimal I/O size to the physical block size of the block device. Closes: https://lore.kernel.org/dm-devel/1426ad71-79b4-4062-b2bf-84278be66a5d@redhat.com/T/ [1] Signed-off-by: Mikulas Patocka Fixes: a23634644afc ("block: take io_opt and io_min into account for max_sectors") Cc: stable@vger.kernel.org # v6.11+ Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/3dc0014b-9690-dc38-81c9-4a316a2d4fb2@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 29eac3eca72d4c2a71122050c37cd7d8f73ac4f3 Author: Pavel Begunkov Date: Tue Nov 26 00:34:18 2024 +0000 io_uring: check for overflows in io_pin_pages commit 0c0a4eae26ac78379d0c1db053de168a8febc6c9 upstream. WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow. Cc: stable@vger.kernel.org Reported-by: syzbot+2159cbb522b02847c053@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/1b7520ddb168e1d537d64be47414a0629d0d8f8f.1732581026.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9250a5cf8d6c8493a65d50549ce6f1c4b574b3df Author: Pavel Begunkov Date: Mon Nov 25 23:10:31 2024 +0000 io_uring: fix corner case forgetting to vunmap commit 43eef70e7e2ac74e7767731dd806720c7fb5e010 upstream. io_pages_unmap() is a bit tricky in trying to figure whether the pages were previously vmap'ed or not. In particular If there is juts one page it belives there is no need to vunmap. Paired io_pages_map(), however, could've failed io_mem_alloc_compound() and attempted to io_mem_alloc_single(), which does vmap, and that leads to unpaired vmap. The solution is to fail if io_mem_alloc_compound() can't allocate a single page. That's the easiest way to deal with it, and those two functions are getting removed soon, so no need to overcomplicate it. Cc: stable@vger.kernel.org Fixes: 3ab1db3c6039e ("io_uring: get rid of remap_pfn_range() for mapping rings/sqes") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/477e75a3907a2fe83249e49c0a92cd480b2c60e0.1732569842.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b345db3ab1991deecee3efc406477189afd1af28 Author: Greg Kroah-Hartman Date: Sat Nov 30 16:55:56 2024 +0100 Revert "serial: sh-sci: Clean sci_ports[0] after at earlycon exit" commit 718632467d88e98816fa01ab12681ef1c2aa56f8 upstream. This reverts commit 3791ea69a4858b81e0277f695ca40f5aae40f312. It was reported to cause boot-time issues, so revert it for now. Reported-by: Geert Uytterhoeven Fixes: 3791ea69a485 ("serial: sh-sci: Clean sci_ports[0] after at earlycon exit") Cc: stable Cc: Claudiu Beznea Signed-off-by: Greg Kroah-Hartman commit 80e55fa3840c185afd7959cc3f4ec95f865db0b3 Author: Claudiu Beznea Date: Wed Nov 6 14:01:12 2024 +0200 serial: sh-sci: Clean sci_ports[0] after at earlycon exit commit 3791ea69a4858b81e0277f695ca40f5aae40f312 upstream. The early_console_setup() function initializes the sci_ports[0].port with an object of type struct uart_port obtained from the object of type struct earlycon_device received as argument by the early_console_setup(). It may happen that later, when the rest of the serial ports are probed, the serial port that was used as earlycon (e.g., port A) to be mapped to a different position in sci_ports[] and the slot 0 to be used by a different serial port (e.g., port B), as follows: sci_ports[0] = port A sci_ports[X] = port B In this case, the new port mapped at index zero will have associated data that was used for earlycon. In case this happens, after Linux boot, any access to the serial port that maps on sci_ports[0] (port A) will block the serial port that was used as earlycon (port B). To fix this, add early_console_exit() that clean the sci_ports[0] at earlycon exit time. Fixes: 0b0cced19ab1 ("serial: sh-sci: Add CONFIG_SERIAL_EARLYCON support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20241106120118.1719888-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman commit 0f6f976a6a4a0ac4921b941a57b4c7c0e38a5951 Author: Michal Vrastil Date: Wed Nov 13 15:54:33 2024 -0800 Revert "usb: gadget: composite: fix OS descriptors w_value logic" commit 51cdd69d6a857f527d6d0697a2e1f0fa8bca1005 upstream. This reverts commit ec6ce7075ef879b91a8710829016005dc8170f17. Fix installation of WinUSB driver using OS descriptors. Without the fix the drivers are not installed correctly and the property 'DeviceInterfaceGUID' is missing on host side. The original change was based on the assumption that the interface number is in the high byte of wValue but it is in the low byte, instead. Unfortunately, the fix is based on MS documentation which is also wrong. The actual USB request for OS descriptors (using USB analyzer) looks like: Offset 0 1 2 3 4 5 6 7 0x000 C1 A1 02 00 05 00 0A 00 C1: bmRequestType (device to host, vendor, interface) A1: nas magic number 0002: wValue (2: nas interface) 0005: wIndex (5: get extended property i.e. nas interface GUID) 008E: wLength (142) The fix was tested on Windows 10 and Windows 11. Cc: stable@vger.kernel.org Fixes: ec6ce7075ef8 ("usb: gadget: composite: fix OS descriptors w_value logic") Signed-off-by: Michal Vrastil Signed-off-by: Elson Roy Serrao Acked-by: Peter korsgaard Link: https://lore.kernel.org/r/20241113235433.20244-1-quic_eserrao@quicinc.com Signed-off-by: Greg Kroah-Hartman commit f680d7c233725f9045ad0224784ebbca360231ec Author: Jaegeuk Kim Date: Tue Nov 12 01:04:58 2024 +0000 Revert "f2fs: remove unreachable lazytime mount option parsing" commit acff9409dd40beaca2bd982678d222e2740ad84b upstream. This reverts commit 54f43a10fa257ad4af02a1d157fefef6ebcfa7dc. The above commit broke the lazytime mount, given mount("/dev/vdb", "/mnt/test", "f2fs", 0, "lazytime"); CC: stable@vger.kernel.org # 6.11+ Signed-off-by: Daniel Rosenberg Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 1ae5ea93b95f35dc4b2c9c26e34c5e932fbece33 Author: Christian Brauner Date: Wed Nov 27 12:45:02 2024 +0100 Revert "fs: don't block i_writecount during exec" commit 3b832035387ff508fdcf0fba66701afc78f79e3d upstream. This reverts commit 2a010c41285345da60cece35575b4e0af7e7bf44. Rui Ueyama writes: > I'm the creator and the maintainer of the mold linker > (https://github.com/rui314/mold). Recently, we discovered that mold > started causing process crashes in certain situations due to a change > in the Linux kernel. Here are the details: > > - In general, overwriting an existing file is much faster than > creating an empty file and writing to it on Linux, so mold attempts to > reuse an existing executable file if it exists. > > - If a program is running, opening the executable file for writing > previously failed with ETXTBSY. If that happens, mold falls back to > creating a new file. > > - However, the Linux kernel recently changed the behavior so that > writing to an executable file is now always permitted > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853). > > That caused mold to write to an executable file even if there's a > process running that file. Since changes to mmap'ed files are > immediately visible to other processes, any processes running that > file would almost certainly crash in a very mysterious way. > Identifying the cause of these random crashes took us a few days. > > Rejecting writes to an executable file that is currently running is a > well-known behavior, and Linux had operated that way for a very long > time. So, I don’t believe relying on this behavior was our mistake; > rather, I see this as a regression in the Linux kernel. Quoting myself from commit 2a010c412853 ("fs: don't block i_writecount during exec") > Yes, someone in userspace could potentially be relying on this. It's not > completely out of the realm of possibility but let's find out if that's > actually the case and not guess. It seems we found out that someone is relying on this obscure behavior. So revert the change. Link: https://github.com/rui314/mold/issues/1361 Link: https://lore.kernel.org/r/4a2bc207-76be-4715-8e12-7fc45a76a125@leemhuis.info Cc: Signed-off-by: Christian Brauner [ revert the original, not the 6.13-rc1 version - gregkh ] Signed-off-by: Greg Kroah-Hartman commit b8b0e9650eeb6637b4e1cf3d6aaf0e96f87862e7 Author: Greg Kroah-Hartman Date: Tue Dec 3 10:33:36 2024 +0100 Revert "exec: don't WARN for racy path_noexec check" This reverts commit d62ba2a5536df83473a2ac15ab302258e3845251 which is commit 0d196e7589cefe207d5d41f37a0a28a1fdeeb7c6 upstream. A later commit needs to be reverted so revert this one as well to allow that to happen properly. Cc: Mateusz Guzik Cc: Christian Brauner Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit cf3998254f02b60234dcedef6b2979e7208b3f58 Author: Javier Carrasco Date: Wed Oct 30 18:34:45 2024 +0100 wifi: brcmfmac: release 'root' node in all execution paths commit 2e19a3b590ebf2e351fc9d0e7c323430e65b6b6d upstream. The fixed patch introduced an additional condition to enter the scope where the 'root' device_node is released (!settings->board_type, currently 'err'), which avoid decrementing the refcount with a call to of_node_put() if that second condition is not satisfied. Move the call to of_node_put() to the point where 'root' is no longer required to avoid leaking the resource if err is not zero. Cc: stable@vger.kernel.org Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties") Signed-off-by: Javier Carrasco Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20241030-brcmfmac-of-cleanup-v1-1-0b90eefb4279@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2eec88c0fa63f8ad35704a8c9df0b5bd8694fcda Author: Jose Ignacio Tornos Martinez Date: Thu Oct 17 20:07:31 2024 +0200 wifi: ath12k: fix crash when unbinding commit 1304446f67863385dc4c914b6e0194f6664ee764 upstream. If there is an error during some initialization related to firmware, the function ath12k_dp_cc_cleanup is called to release resources. However this is released again when the device is unbinded (ath12k_pci), and we get: BUG: kernel NULL pointer dereference, address: 0000000000000020 at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] Call Trace: ath12k_dp_cc_cleanup ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set to NULL the released structure in ath12k_dp_cc_cleanup at the end. cc: stable@vger.kernel.org Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Jose Ignacio Tornos Martinez Link: https://patch.msgid.link/20241017181004.199589-2-jtornosm@redhat.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit d4ef643ea78c59c22546046c25dc6e7206267672 Author: Aleksei Vetrov Date: Tue Oct 29 13:22:11 2024 +0000 wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan commit 9c46a3a5b394d6d123866aa44436fc2cd342eb0d upstream. The channels array in the cfg80211_scan_request has a __counted_by attribute attached to it, which points to the n_channels variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of allocated memory as the initial value for n_channels. It is updated with the actual number of added elements after the array is filled. Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Cc: stable@vger.kernel.org Signed-off-by: Aleksei Vetrov Reviewed-by: Jeff Johnson Link: https://patch.msgid.link/20241029-nl80211_parse_sched_scan-bounds-checker-fix-v2-1-c804b787341f@google.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c Author: Guilherme G. Piccoli Date: Fri Nov 1 16:30:05 2024 -0300 wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures commit 5c1b544563005a00591a3aa86ecff62ed4d11be3 upstream. Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith Signed-off-by: Guilherme G. Piccoli Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman commit 90556b96338aa6037cd26dac857327fda7c19732 Author: Jose Ignacio Tornos Martinez Date: Thu Oct 17 20:07:32 2024 +0200 wifi: ath12k: fix warning when unbinding commit ca68ce0d9f4bcd032fd1334441175ae399642a06 upstream. If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath12k_pci), and we get: WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Call Trace: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free. cc: stable@vger.kernel.org Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Jose Ignacio Tornos Martinez Link: https://patch.msgid.link/20241017181004.199589-3-jtornosm@redhat.com Signed-off-by: Jeff Johnson Signed-off-by: Greg Kroah-Hartman commit 488179abcf4a2b6182c2a4d4d928cc8f43200769 Author: Andreas Kemnade Date: Fri Oct 18 23:47:27 2024 +0200 ARM: dts: omap36xx: declare 1GHz OPP as turbo again commit 96a64e9730c2c76cfa5c510583a0fbf40d62886b upstream. Operating stable without reduced chip life at 1Ghz needs several technologies working: The technologies involve - SmartReflex - DVFS As this cannot directly specified in the OPP table as dependecies in the devicetree yet, use the turbo flag again to mark this OPP as something special to have some kind of opt-in. So revert commit 5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants") Practical reasoning: At least the GTA04A5 (DM3730) has become unstable with that OPP enabled. Furthermore nothing enforces the availability of said technologies, even in the kernel configuration, so allow users to rather opt-in. Cc: Stable@vger.kernel.org Fixes: 5f1bf7ae8481 ("ARM: dts: omap36xx: Remove turbo mode for 1GHz variants") Signed-off-by: Andreas Kemnade Link: https://lore.kernel.org/r/20241018214727.275162-1-andreas@kemnade.info Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 8668a0a14148cd3a23c48d50fc37ae0fa0bec655 Author: Michal Pecio Date: Wed Nov 6 12:14:59 2024 +0200 usb: xhci: Avoid queuing redundant Stop Endpoint commands commit 474538b8dd1cd9c666e56cfe8ef60fbb0fb513f4 upstream. Stop Endpoint command on an already stopped endpoint fails and may be misinterpreted as a known hardware bug by the completion handler. This results in an unnecessary delay with repeated retries of the command. Avoid queuing this command when endpoint state flags indicate that it's stopped or halted and the command will fail. If commands are pending on the endpoint, their completion handlers will process cancelled TDs so it's done. In case of waiting for external operations like clearing TT buffer, the endpoint is stopped and cancelled TDs can be processed now. This eliminates practically all unnecessary retries because an endpoint with pending URBs is maintained in Running state by the driver, unless aforementioned commands or other operations are pending on it. This is guaranteed by xhci_ring_ep_doorbell() and by the fact that it is called every time any of those operations completes. The only known exceptions are hardware bugs (the endpoint never starts at all) and Stream Protocol errors not associated with any TRB, which cause an endpoint reset not followed by restart. Sounds like a bug. Generally, these retries are only expected to happen when the endpoint fails to start for unknown/no reason, which is a worse problem itself, and fixing the bug eliminates the retries too. All cases were tested and found to work as expected. SET_DEQ_PENDING was produced by patching uvcvideo to unlink URBs in 100us intervals, which then runs into this case very often. EP_HALTED was produced by restarting 'cat /dev/ttyUSB0' on a serial dongle with broken cable. EP_CLEARING_TT by the same, with the dongle on an external hub. Fixes: fd9d55d190c0 ("xhci: retry Stop Endpoint on buggy NEC controllers") CC: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-34-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 14570e7373db16be7e0f3cc07d560ae9af9e53db Author: Michal Pecio Date: Wed Nov 6 12:14:58 2024 +0200 usb: xhci: Fix TD invalidation under pending Set TR Dequeue commit 484c3bab2d5dfa13ff659a51a06e9a393141eefc upstream. xhci_invalidate_cancelled_tds() may not work correctly if the hardware is modifying endpoint or stream contexts at the same time by executing a Set TR Dequeue command. And even if it worked, it would be unable to queue Set TR Dequeue for the next stream, failing to clear xHC cache. On stream endpoints, a chain of Set TR Dequeue commands may take some time to execute and we may want to cancel more TDs during this time. Currently this leads to Stop Endpoint completion handler calling this function without testing for SET_DEQ_PENDING, which will trigger the aforementioned problems when it happens. On all endpoints, a halt condition causes Reset Endpoint to be queued and an error status given to the class driver, which may unlink more URBs in response. Stop Endpoint is queued and its handler may execute concurrently with Set TR Dequeue queued by Reset Endpoint handler. (Reset Endpoint handler calls this function too, but there seems to be no possibility of it running concurrently with Set TR Dequeue). Fix xhci_invalidate_cancelled_tds() to work correctly under a pending Set TR Dequeue. Bail out of the function when SET_DEQ_PENDING is set, then make the completion handler call the function again and also call xhci_giveback_invalidated_tds(), which needs to be called next. This seems to fix another potential bug, where the handler would call xhci_invalidate_cancelled_tds(), which may clear some deferred TDs if a sanity check fails, and the TDs wouldn't be given back promptly. Said sanity check seems to be wrong and prone to false positives when the endpoint halts, but fixing it is beyond the scope of this change, besides ensuring that cleared TDs are given back properly. Fixes: 5ceac4402f5d ("xhci: Handle TD clearing for multiple streams case") CC: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-33-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f03cd5d86a3f85f0ade79934e3e2d03a4e7887b0 Author: Michal Pecio Date: Wed Nov 6 12:14:57 2024 +0200 usb: xhci: Limit Stop Endpoint retries commit 42b7581376015c1bbcbe5831f043cd0ac119d028 upstream. Some host controllers fail to atomically transition an endpoint to the Running state on a doorbell ring and enter a hidden "Restarting" state, which looks very much like Stopped, with the important difference that it will spontaneously transition to Running anytime soon. A Stop Endpoint command queued in the Restarting state typically fails with Context State Error and the completion handler sees the Endpoint Context State as either still Stopped or already Running. Even a case of Halted was observed, when an error occurred right after the restart. The Halted state is already recovered from by resetting the endpoint. The Running state is handled by retrying Stop Endpoint. The Stopped state was recognized as a problem on NEC controllers and worked around also by retrying, because the endpoint soon restarts and then stops for good. But there is a risk: the command may fail if the endpoint is "stopped for good" already, and retries will fail forever. The possibility of this was not realized at the time, but a number of cases were discovered later and reproduced. Some proved difficult to deal with, and it is outright impossible to predict if an endpoint may fail to ever start at all due to a hardware bug. One such bug (albeit on ASM3142, not on NEC) was found to be reliably triggered simply by toggling an AX88179 NIC up/down in a tight loop for a few seconds. An endless retries storm is quite nasty. Besides putting needless load on the xHC and CPU, it causes URBs never to be given back, paralyzing the device and connection/disconnection logic for the whole bus if the device is unplugged. User processes waiting for URBs become unkillable, drivers and kworker threads lock up and xhci_hcd cannot be reloaded. For peace of mind, impose a timeout on Stop Endpoint retries in this case. If they don't succeed in 100ms, consider the endpoint stopped permanently for some reason and just give back the unlinked URBs. This failure case is rare already and work is under way to make it rarer. Start this work today by also handling one simple case of race with Reset Endpoint, because it costs just two lines to implement. Fixes: fd9d55d190c0 ("xhci: retry Stop Endpoint on buggy NEC controllers") CC: stable@vger.kernel.org Signed-off-by: Michal Pecio Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-32-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 3063d98c9a4e365d86d60b396cc8f11aa432acce Author: Andrej Shadura Date: Wed Oct 9 14:14:24 2024 +0200 Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}() commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: https://github.com/ClangBuiltLinux/linux/issues/2007 Link: https://github.com/llvm/llvm-project/issues/85647 Signed-off-by: Andrej Shadura Reviewed-by: Nathan Chancellor Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman commit 8d2ca55a8fb79a0673048aca1c8b4893a8ee12df Author: Kuangyi Chiang Date: Wed Nov 6 12:14:44 2024 +0200 xhci: Don't issue Reset Device command to Etron xHCI host commit 76d98856b1c6d06ce18f32c20527a4f9d283e660 upstream. Sometimes the hub driver does not recognize the USB device connected to the external USB2.0 hub when the system resumes from S4. After the SetPortFeature(PORT_RESET) request is completed, the hub driver calls the HCD reset_device callback, which will issue a Reset Device command and free all structures associated with endpoints that were disabled. This happens when the xHCI driver issue a Reset Device command to inform the Etron xHCI host that the USB device associated with a device slot has been reset. Seems that the Etron xHCI host can not perform this command correctly, affecting the USB device. To work around this, the xHCI driver should obtain a new device slot with reference to commit 651aaf36a7d7 ("usb: xhci: Handle USB transaction error on address command"), which is another way to inform the Etron xHCI host that the USB device has been reset. Add a new XHCI_ETRON_HOST quirk flag to invoke the workaround in xhci_discover_or_reset_device(). Fixes: 2a8f82c4ceaf ("USB: xhci: Notify the xHC when a device is reset.") Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-19-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 151f6333a281e15116273232ad2361576f18154a Author: Kuangyi Chiang Date: Wed Nov 6 12:14:46 2024 +0200 xhci: Don't perform Soft Retry for Etron xHCI host commit e735e957f2b9cfe4be486e0304732ec36928591f upstream. Since commit f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors"), unplugging USB device while enumeration results in errors like this: [ 364.855321] xhci_hcd 0000:0b:00.0: ERROR Transfer event for disabled endpoint slot 5 ep 2 [ 364.864622] xhci_hcd 0000:0b:00.0: @0000002167656d70 67f03000 00000021 0c000000 05038001 [ 374.934793] xhci_hcd 0000:0b:00.0: Abort failed to stop command ring: -110 [ 374.958793] xhci_hcd 0000:0b:00.0: xHCI host controller not responding, assume dead [ 374.967590] xhci_hcd 0000:0b:00.0: HC died; cleaning up [ 374.973984] xhci_hcd 0000:0b:00.0: Timeout while waiting for configure endpoint command Seems that Etorn xHCI host can not perform Soft Retry correctly, apply XHCI_NO_SOFT_RETRY quirk to disable Soft Retry and then issue is gone. This patch depends on commit a4a251f8c235 ("usb: xhci: do not perform Soft Retry for some xHCI hosts"). Fixes: f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-21-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 02a49888242aa159a1021516be3e1b5ffd88ba43 Author: Kuangyi Chiang Date: Wed Nov 6 12:14:43 2024 +0200 xhci: Combine two if statements for Etron xHCI host commit d7b11fe5790203fcc0db182249d7bfd945e44ccb upstream. Combine two if statements, because these hosts have the same quirk flags applied. [Mathias: has stable tag because other fixes in series depend on this] Fixes: 91f7a1524a92 ("xhci: Apply broken streams quirk to Etron EJ188 xHCI host") Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-18-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 4725344ca645a98a9d8e45e25b01a2244de5b8aa Author: Kuangyi Chiang Date: Wed Nov 6 12:14:45 2024 +0200 xhci: Fix control transfer error on Etron xHCI host commit 5e1c67abc9301d05130b7e267c204e7005503b33 upstream. Performing a stability stress test on a USB3.0 2.5G ethernet adapter results in errors like this: [ 91.441469] r8152 2-3:1.0 eth3: get_registers -71 [ 91.458659] r8152 2-3:1.0 eth3: get_registers -71 [ 91.475911] r8152 2-3:1.0 eth3: get_registers -71 [ 91.493203] r8152 2-3:1.0 eth3: get_registers -71 [ 91.510421] r8152 2-3:1.0 eth3: get_registers -71 The r8152 driver will periodically issue lots of control-IN requests to access the status of ethernet adapter hardware registers during the test. This happens when the xHCI driver enqueue a control TD (which cross over the Link TRB between two ring segments, as shown) in the endpoint zero's transfer ring. Seems the Etron xHCI host can not perform this TD correctly, causing the USB transfer error occurred, maybe the upper driver retry that control-IN request can solve problem, but not all drivers do this. | | ------- | TRB | Setup Stage ------- | TRB | Link ------- ------- | TRB | Data Stage ------- | TRB | Status Stage ------- | | To work around this, the xHCI driver should enqueue a No Op TRB if next available TRB is the Link TRB in the ring segment, this can prevent the Setup and Data Stage TRB to be breaked by the Link TRB. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in xhci_queue_ctrl_tx(). Fixes: d0e96f5a71a0 ("USB: xhci: Control transfer support.") Cc: stable@vger.kernel.org Signed-off-by: Kuangyi Chiang Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241106101459.775897-20-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit a0120d6463368378539ef928cf067d02372efb8c Author: Yuezhang Mo Date: Mon Oct 28 11:23:36 2024 +0800 exfat: fix out-of-bounds access of directory entries commit 184fa506e392eb78364d9283c961217ff2c0617b upstream. In the case of the directory size is greater than or equal to the cluster size, if start_clu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei->hint_femp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption. This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty. Cc: stable@vger.kernel.org Signed-off-by: Yuezhang Mo Co-developed-by: Namjae Jeon Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 351e6904f11f216948c5f63878e9dd7aa77810e9 Author: Namjae Jeon Date: Sat Oct 26 13:06:15 2024 +0900 exfat: fix uninit-value in __exfat_get_dentry_set commit 02dffe9ab092fc4c8800aee68cb7eafd37a980c4 upstream. There is no check if stream size and start_clu are invalid. If start_clu is EOF cluster and stream size is 4096, It will cause uninit value access. because ei->hint_femp.eidx could be 128(if cluster size is 4K) and wrong hint will allocate next cluster. and this cluster will be same with the cluster that is allocated by exfat_extend_valid_size(). The previous patch will check invalid start_clu, but for clarity, initialize hint_femp.eidx to zero. Cc: stable@vger.kernel.org Reported-by: syzbot+01218003be74b5e1213a@syzkaller.appspotmail.com Tested-by: syzbot+01218003be74b5e1213a@syzkaller.appspotmail.com Reviewed-by: Yuezhang Mo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit 152920642dbfb68197f602d280931d8969f65ad2 Author: Angelo Dureghello Date: Thu Oct 3 19:29:01 2024 +0200 dt-bindings: iio: dac: ad3552r: fix maximum spi speed commit d1d1c117f39b2057d1e978f26a8bd9631ddb193b upstream. Fix maximum SPI clock speed, as per datasheet (Rev. B, page 6). Fixes: b0a96c5f599e ("dt-bindings: iio: dac: Add adi,ad3552r.yaml") Cc: stable@vger.kernel.org Signed-off-by: Angelo Dureghello Acked-by: Krzysztof Kozlowski Link: https://patch.msgid.link/20241003-wip-bl-ad3552r-axi-v0-iio-testing-v4-4-ceb157487329@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 716a99ef8304b9e670fb7da844aa439c325808c2 Author: Krzysztof Kozlowski Date: Tue Oct 15 08:58:47 2024 +0200 dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with fallbacks commit ffb30875172eabff727e2896f097ccd4bb68723f upstream. Commit 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers") added samsung,exynos7-wakeup-eint fallback to some compatibles, so the intention in the if:then: conditions was to handle the cases: 1. Single Exynos7 compatible or Exynos5433+Exynos7 or Exynos7885+Exynos7: only one interrupt 2. Exynos850+Exynos7: no interrupts This was not implemented properly however and if:then: block matches only single Exynos5433 or Exynos7885 compatibles, which do not exist in DTS anymore, so basically is a no-op and no enforcement on number of interrupts is made by the binding. Fix the if:then: condition so interrupts in the Exynos5433 and Exynos7885 wake-up pin controller will be properly constrained. Fixes: 904140fa4553 ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers") Cc: stable@vger.kernel.org Acked-by: Rob Herring (Arm) Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20241015065848.29429-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 177858010327a56c28e41de3ce8fa247245894f2 Author: Johan Hovold Date: Fri Oct 25 14:16:22 2024 +0200 pinctrl: qcom: spmi: fix debugfs drive strength commit 6bc0ebfb1d920f13c522545f114cdabb49e9408a upstream. Commit 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") fixed a long-standing issue in the Qualcomm SPMI PMIC gpio driver which had the 'low' and 'high' drive strength settings switched but failed to update the debugfs interface which still gets this wrong. Fix the debugfs code so that the exported values match the hardware settings. Note that this probably means that most devicetrees that try to describe the firmware settings got this wrong if the settings were derived from debugfs. Before the above mentioned commit the settings would have actually matched the firmware settings even if they were described incorrectly, but now they are inverted. Fixes: 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Cc: Anjelique Melendez Cc: stable@vger.kernel.org # 3.19 Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/20241025121622.1496-1-johan+linaro@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a05cec67116f77667defcf6788eb38106652d418 Author: Thomas Weißschuh Date: Fri Sep 27 18:45:38 2024 +0200 tools/nolibc: s390: include std.h commit 711b5875814b2a0e9a5aaf7a85ba7c80f5a389b1 upstream. arch-s390.h uses types from std.h, but does not include it. Depending on the inclusion order the compilation can fail. Include std.h explicitly to avoid these errors. Fixes: 404fa87c0eaf ("tools/nolibc: s390: provide custom implementation for sys_fork") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20240927-nolibc-s390-std-h-v1-1-30442339a6b9@linutronix.de Signed-off-by: Thomas Weißschuh Signed-off-by: Greg Kroah-Hartman commit 95238df61b65f6999614d66e6c5f0a631eb67909 Author: Ahmed Ehab Date: Sun Aug 25 01:10:30 2024 +0300 locking/lockdep: Avoid creating new name string literals in lockdep_set_subclass() commit d7fe143cb115076fed0126ad8cf5ba6c3e575e43 upstream. Syzbot reports a problem that a warning will be triggered while searching a lock class in look_up_lock_class(). The cause of the issue is that a new name is created and used by lockdep_set_subclass() instead of using the existing one. This results in a lock instance has a different name pointer than previous registered one stored in lock class, and WARN_ONCE() is triggered because of that in look_up_lock_class(). To fix this, change lockdep_set_subclass() to use the existing name instead of a new one. Hence, no new name will be created by lockdep_set_subclass(). Hence, the warning is avoided. [boqun: Reword the commit log to state the correct issue] Reported-by: Fixes: de8f5e4f2dc1f ("lockdep: Introduce wait-type checks") Cc: stable@vger.kernel.org Signed-off-by: Ahmed Ehab Signed-off-by: Boqun Feng Link: https://lore.kernel.org/lkml/20240824221031.7751-1-bottaawesome633@gmail.com/ Signed-off-by: Greg Kroah-Hartman commit c3d05a6b8d8fb1eb2ca706f9596a5901b11b207c Author: Nicolas Bouchinet Date: Tue Nov 12 14:13:31 2024 +0100 tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler commit 635a9fca54f4f4148be1ae1c7c6bd37af80f5773 upstream. Commit 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") introduces the tty_ldisc_autoload sysctl with the wrong proc_handler. .extra1 and .extra2 parameters are set to avoid other values thant SYSCTL_ZERO or SYSCTL_ONE to be set but proc_dointvec do not uses them. This commit fixes this by using proc_dointvec_minmax instead of proc_dointvec. Fixes: 7c0cca7c847e ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") Cc: stable Signed-off-by: Nicolas Bouchinet Reviewed-by: Lin Feng Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20241112131357.49582-4-nicolas.bouchinet@clip-os.org Signed-off-by: Greg Kroah-Hartman commit 2d6b3fda78dd68f52fa25fdbd27011ace59b33e0 Author: Angelo Dureghello Date: Tue Oct 8 17:43:33 2024 +0200 iio: dac: adi-axi-dac: fix wrong register bitfield commit 70602f529e4d76798c95aeed5ce2a8d36263abe5 upstream. Fix ADI_DAC_R1_MODE of AXI_DAC_REG_CNTRL_2. Both generic DAC and ad3552r DAC IPs docs are reporting bit 5 for it. Link: https://wiki.analog.com/resources/fpga/docs/axi_dac_ip Fixes: 4e3949a192e4 ("iio: dac: add support for AXI DAC IP core") Cc: stable@vger.kernel.org Signed-off-by: Angelo Dureghello Reviewed-by: Nuno Sa Link: https://patch.msgid.link/20241008-wip-bl-ad3552r-axi-v0-iio-testing-v5-1-3d410944a63d@baylibre.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 59a149e7c38e7b76616c8b333fc6aa5b6fb2293c Author: Jinjie Ruan Date: Fri Oct 11 09:22:41 2024 +0800 apparmor: test: Fix memory leak for aa_unpack_strdup() commit 7290f59231910ccba427d441a6e8b8c6f6112448 upstream. The string allocated by kmemdup() in aa_unpack_strdup() is not freed and cause following memory leaks, free them to fix it. unreferenced object 0xffffff80c6af8a50 (size 8): comm "kunit_try_catch", pid 225, jiffies 4294894407 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<000000008ecde918>] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80c2a29090 (size 8): comm "kunit_try_catch", pid 227, jiffies 4294894409 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<0000000046a45c1a>] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 Cc: stable@vger.kernel.org Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack") Signed-off-by: Jinjie Ruan Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit c6963a06ce5c61d3238751ada04ee1569663a828 Author: Jann Horn Date: Thu Oct 17 21:07:45 2024 +0200 comedi: Flush partial mappings in error case commit ce8f9fb651fac95dd41f69afe54d935420b945bd upstream. If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path. Fix it by explicitly flushing all mappings in our VMA on the error path. See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in error case"). Cc: stable@vger.kernel.org Fixes: ed9eccbe8970 ("Staging: add comedi core") Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20241017-comedi-tlb-v3-1-16b82f9372ce@google.com Signed-off-by: Greg Kroah-Hartman commit 45a8f8232a495221ed058191629f5c628f21601a Author: Jann Horn Date: Mon Nov 18 17:33:13 2024 +0100 fsnotify: Fix ordering of iput() and watched_objects decrement commit 21d1b618b6b9da46c5116c640ac4b1cc8d40d63a upstream. Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info. Cc: stable@kernel.org Fixes: d2f277e26f52 ("fsnotify: rename fsnotify_{get,put}_sb_connectors()") Signed-off-by: Jann Horn Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b8232925bd8edf1f21d1a48203321c2efeff92b4 Author: Amir Goldstein Date: Wed Nov 13 16:40:34 2024 +0100 fsnotify: fix sending inotify event with unexpected filename commit aa52c54da40d9eee3ba87c05cdcb0cd07c04fa13 upstream. We got a report that adding a fanotify filsystem watch prevents tail -f from receiving events. Reproducer: 1. Create 3 windows / login sessions. Become root in each session. 2. Choose a mounted filesystem that is pretty quiet; I picked /boot. 3. In the first window, run: fsnotifywait -S -m /boot 4. In the second window, run: echo data >> /boot/foo 5. In the third window, run: tail -f /boot/foo 6. Go back to the second window and run: echo more data >> /boot/foo 7. Observe that the tail command doesn't show the new data. 8. In the first window, hit control-C to interrupt fsnotifywait. 9. In the second window, run: echo still more data >> /boot/foo 10. Observe that the tail command in the third window has now printed the missing data. When stracing tail, we observed that when fanotify filesystem mark is set, tail does get the inotify event, but the event is receieved with the filename: read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0foo\0\0\0\0\0\0\0\0\0\0\0\0\0", 50) = 32 This is unexpected, because tail is watching the file itself and not its parent and is inconsistent with the inotify event received by tail when fanotify filesystem mark is not set: read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0", 50) = 16 The inteference between different fsnotify groups was caused by the fact that the mark on the sb requires the filename, so the filename is passed to fsnotify(). Later on, fsnotify_handle_event() tries to take care of not passing the filename to groups (such as inotify) that are interested in the filename only when the parent is watching. But the logic was incorrect for the case that no group is watching the parent, some groups are watching the sb and some watching the inode. Reported-by: Miklos Szeredi Fixes: 7372e79c9eb9 ("fanotify: fix logic of reporting name info with watched parent") Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b96fc194984d0c82de1ca2b4166b35b1298b216c Author: Gustavo A. R. Silva Date: Thu Nov 14 17:55:16 2024 -0600 clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access commit 02fb4f0084331ef72c28d0c70fcb15d1bea369ec upstream. Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated with the `counted_by()` attribute. This means that when memory is allocated for this array, the _counter_, which in this case is member `num` in the flexible structure, should be set to the maximum number of elements the flexible array can contain, or fewer. In this case, the total number of elements for the flexible array is determined by variable `clks_num` when allocating heap space via `devm_kzalloc()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); So, `clp->clk_data.num` should be set to `clks_num` or less, and not exceed `clks_num`, as is currently the case. Otherwise, if data is written into `clp->clk_data.hws[clks_num]`, the instrumentation provided by the compiler won't detect the overflow, leading to a memory corruption bug at runtime. Fix this issue by setting `clp->clk_data.num` to `clks_num`. Fixes: 9796ec0bd04b ("clk: clk-loongson2: Refactor driver for adding new platforms") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/ZzaN5MpmMr0hwHw9@kspp Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 76918202615f2ba7deda14901d9fff528a180099 Author: Gustavo A. R. Silva Date: Thu Nov 14 16:49:21 2024 -0600 clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider commit 6e4bf018bb040955da53dae9f8628ef8fcec2dbe upstream. Some heap space is allocated for the flexible structure `struct clk_hw_onecell_data` and its flexible-array member `hws` through the composite structure `struct loongson2_clk_provider` in function `loongson2_clk_probe()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Then some data is written into the flexible array: 350 clp->clk_data.hws[p->id] = hw; This corrupts `clk_lock`, which is the spinlock variable immediately following the `clk_data` member in `struct loongson2_clk_provider`: struct loongson2_clk_provider { void __iomem *base; struct device *dev; struct clk_hw_onecell_data clk_data; spinlock_t clk_lock; /* protect access to DIV registers */ }; The problem is that the flexible structure is currently placed in the middle of `struct loongson2_clk_provider` instead of at the end. Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of `struct loongson2_clk_provider`. Also, add a code comment to help prevent this from happening again in case new members are added to the structure in the future. This change also fixes the following -Wflex-array-member-not-at-end warning: drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Fixes: 9796ec0bd04b ("clk: clk-loongson2: Refactor driver for adding new platforms") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Link: https://lore.kernel.org/r/ZzZ-cd_EFXs6qFaH@kspp Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 3735684f64e0ab9155aa2f9cc7d0e51ddd596399 Author: Huacai Chen Date: Fri Nov 22 15:47:47 2024 +0800 LoongArch: Explicitly specify code model in Makefile commit e67e0eb6a98b261caf45048f9eb95fd7609289c0 upstream. LoongArch's toolchain may change the default code model from normal to medium. This is unnecessary for kernel, and generates some relocations which cannot be handled by the module loader. So explicitly specify the code model to normal in Makefile (for Rust 'normal' is 'small'). Cc: stable@vger.kernel.org Tested-by: Haiyong Sun Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit c8266ab8e7ccd1d1f5a9c8b29eb2020175048134 Author: Lukas Wunner Date: Thu Oct 10 19:10:34 2024 +0200 PCI: Fix use-after-free of slot->bus on hot remove commit c7acef99642b763ba585f4a43af999fcdbcc3dc4 upstream. Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Link: https://lore.kernel.org/r/4bfd4c0e976c1776cd08e76603903b338cf25729.1728579288.git.lukas@wunner.de Reported-by: Dennis Wassenberg Closes: https://lore.kernel.org/r/6de4b45ff2b32dd91a805ec02ec8ec73ef411bf6.camel@secunet.com/ Tested-by: Dennis Wassenberg Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c446afcef5f195764347e7c559e36fcf8a0187d6 Author: Jan Hendrik Farr Date: Tue Oct 29 15:00:36 2024 +0100 Compiler Attributes: disable __counted_by for clang < 19.1.3 commit f06e108a3dc53c0f5234d18de0bd224753db5019 upstream. This patch disables __counted_by for clang versions < 19.1.3 because of the two issues listed below. It does this by introducing CONFIG_CC_HAS_COUNTED_BY. 1. clang < 19.1.2 has a bug that can lead to __bdos returning 0: https://github.com/llvm/llvm-project/pull/110497 2. clang < 19.1.3 has a bug that can lead to __bdos being off by 4: https://github.com/llvm/llvm-project/pull/112636 Fixes: c8248faf3ca2 ("Compiler Attributes: counted_by: Adjust name and identifier expansion") Cc: stable@vger.kernel.org # 6.6.x: 16c31dd7fdf6: Compiler Attributes: counted_by: bump min gcc version Cc: stable@vger.kernel.org # 6.6.x: 2993eb7a8d34: Compiler Attributes: counted_by: fixup clang URL Cc: stable@vger.kernel.org # 6.6.x: 231dc3f0c936: lkdtm/bugs: Improve warning message for compilers without counted_by support Cc: stable@vger.kernel.org # 6.6.x Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/all/20240913164630.GA4091534@thelio-3990X/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202409260949.a1254989-oliver.sang@intel.com Link: https://lore.kernel.org/all/Zw8iawAF5W2uzGuh@archlinux/T/#m204c09f63c076586a02d194b87dffc7e81b8de7b Suggested-by: Nathan Chancellor Signed-off-by: Jan Hendrik Farr Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Reviewed-by: Miguel Ojeda Reviewed-by: Thorsten Blum Link: https://lore.kernel.org/r/20241029140036.577804-2-kernel@jfarr.cc Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 9f13962c52ac0bc486fbbcef2476b45c3f65580b Author: Kunkun Jiang Date: Thu Nov 7 13:41:36 2024 -0800 KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device commit e9649129d33dca561305fc590a7c4ba8c3e5675a upstream. vgic_its_save_device_tables will traverse its->device_list to save DTE for each device. vgic_its_restore_device_tables will traverse each entry of device table and check if it is valid. Restore if valid. But when MAPD unmaps a device, it does not invalidate the corresponding DTE. In the scenario of continuous saves and restores, there may be a situation where a device's DTE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding DTE when MAPD unmaps a device. Cc: stable@vger.kernel.org Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore") Co-developed-by: Shusen Li Signed-off-by: Shusen Li Signed-off-by: Kunkun Jiang [Jing: Update with entry write helper] Signed-off-by: Jing Zhang Link: https://lore.kernel.org/r/20241107214137.428439-5-jingzhangos@google.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 0b535298ec59407a6afa202b45d468168e320f8c Author: Jing Zhang Date: Thu Nov 7 13:41:34 2024 -0800 KVM: arm64: vgic-its: Add a data length check in vgic_its_save_* commit 7fe28d7e68f92cc3d0668b8f2fbdf5c303ac3022 upstream. In all the vgic_its_save_*() functinos, they do not check whether the data length is 8 bytes before calling vgic_write_guest_lock. This patch adds the check. To prevent the kernel from being blown up when the fault occurs, KVM_BUG_ON() is used. And the other BUG_ON()s are replaced together. Cc: stable@vger.kernel.org Signed-off-by: Kunkun Jiang [Jing: Update with the new entry read/write helpers] Signed-off-by: Jing Zhang Link: https://lore.kernel.org/r/20241107214137.428439-4-jingzhangos@google.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit c16e2dba39ff6ae84bb8dc9c8e0fb21d9b2f6f5c Author: Raghavendra Rao Ananta Date: Mon Oct 28 23:45:33 2024 +0000 KVM: arm64: Get rid of userspace_irqchip_in_use commit 38d7aacca09230fdb98a34194fec2af597e8e20d upstream. Improper use of userspace_irqchip_in_use led to syzbot hitting the following WARN_ON() in kvm_timer_update_irq(): WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459 kvm_timer_update_irq+0x21c/0x394 Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret); Theoretically, since userspace_irqchip_in_use's functionality can be simply replaced by '!irqchip_in_kernel()', get rid of the static key to avoid the mismanagement, which also helps with the syzbot issue. Cc: Reported-by: syzbot Suggested-by: Marc Zyngier Signed-off-by: Raghavendra Rao Ananta Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit aeca8577c9e557162176d506a4bd586e0ce93c54 Author: Kunkun Jiang Date: Thu Nov 7 13:41:37 2024 -0800 KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE commit 7602ffd1d5e8927fadd5187cb4aed2fdc9c47143 upstream. When DISCARD frees an ITE, it does not invalidate the corresponding ITE. In the scenario of continuous saves and restores, there may be a situation where an ITE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding ITE when DISCARD frees an ITE. Cc: stable@vger.kernel.org Fixes: eff484e0298d ("KVM: arm64: vgic-its: ITT save and restore") Signed-off-by: Kunkun Jiang [Jing: Update with entry write helper] Signed-off-by: Jing Zhang Link: https://lore.kernel.org/r/20241107214137.428439-6-jingzhangos@google.com Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 1e46460efe1ef9a31748de7675ff8fe0d8601af2 Author: Oliver Upton Date: Fri Oct 25 20:31:03 2024 +0000 KVM: arm64: Don't retire aborted MMIO instruction commit e735a5da64420a86be370b216c269b5dd8e830e2 upstream. Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp. Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC. Cc: stable@vger.kernel.org Fixes: da345174ceca ("KVM: arm/arm64: Allow user injection of external data aborts") Reported-by: Alexander Potapenko Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20241025203106.3529261-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 91991cfda279b4a5d5d518a3bd2cf9eb285415b8 Author: Raghavendra Rao Ananta Date: Tue Nov 19 16:52:29 2024 -0800 KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status commit 54bbee190d42166209185d89070c58a343bf514b upstream. DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow. Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt. Cc: stable@vger.kernel.org Fixes: 76d883c4e640 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating_system/test_pmu001.c Signed-off-by: Raghavendra Rao Ananta [ oliver: massaged changelog ] Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20241120005230.2335682-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit e196acc8a894cd34cf341ac70483defa4c0d5512 Author: Marc Zyngier Date: Sun Nov 17 16:57:54 2024 +0000 KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR commit d561491ba927cb5634094ff311795e9d618e9b86 upstream. Make sure we filter out non-LPI invalidation when handling writes to GICR_INVLPIR. Fixes: 4645d11f4a553 ("KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation") Reported-by: Alexander Potapenko Tested-by: Alexander Potapenko Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241117165757.247686-2-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman commit 33b1672f339d4cd17973ff2dd7da06d38740e91b Author: Gautam Menghani Date: Fri Nov 8 15:18:37 2024 +0530 powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector commit 44e5d21e6d3fd2a1fed7f0327cf72e99397e2eaf upstream. As per the kernel documentation[1], hardlockup detector should be disabled in KVM guests as it may give false positives. On PPC, hardlockup detector is enabled inside KVM guests because disable_hardlockup_detector() is marked as early_initcall and it relies on kvm_guest static key (is_kvm_guest()) which is initialized later during boot by check_kvm_guest(), which is a core_initcall. check_kvm_guest() is also called in pSeries_smp_probe(), which is called before initcalls, but it is skipped if KVM guest does not have doorbell support or if the guest is launched with SMT=1. Call check_kvm_guest() in disable_hardlockup_detector() so that is_kvm_guest() check goes through fine and hardlockup detector can be disabled inside the KVM guest. [1]: Documentation/admin-guide/sysctl/kernel.rst Fixes: 633c8e9800f3 ("powerpc/pseries: Enable hardlockup watchdog for PowerVM partitions") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Gautam Menghani Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241108094839.33084-1-gautam@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit dfd5c2f161cddf898057425f195ccf2920f72e4e Author: Sean Christopherson Date: Thu Oct 10 11:23:06 2024 -0700 KVM: x86/mmu: Skip the "try unsync" path iff the old SPTE was a leaf SPTE commit 2867eb782cf7f64c2ac427596133b6f9c3f64b7a upstream. Apply make_spte()'s optimization to skip trying to unsync shadow pages if and only if the old SPTE was a leaf SPTE, as non-leaf SPTEs in direct MMUs are always writable, i.e. could trigger a false positive and incorrectly lead to KVM creating a SPTE without write-protecting or marking shadow pages unsync. This bug only affects the TDP MMU, as the shadow MMU only overwrites a shadow-present SPTE when synchronizing SPTEs (and only 4KiB SPTEs can be unsync). Specifically, mmu_set_spte() drops any non-leaf SPTEs *before* calling make_spte(), whereas the TDP MMU can do a direct replacement of a page table with the leaf SPTE. Opportunistically update the comment to explain why skipping the unsync stuff is safe, as opposed to simply saying "it's someone else's problem". Cc: stable@vger.kernel.org Tested-by: Alex Bennée Signed-off-by: Sean Christopherson Tested-by: Dmitry Osipenko Signed-off-by: Paolo Bonzini Message-ID: <20241010182427.1434605-5-seanjc@google.com> Signed-off-by: Greg Kroah-Hartman commit 1a77ffcf84e0d1190821cc20ed26ee92bc0c916a Author: Paolo Bonzini Date: Fri Nov 8 04:56:31 2024 -0500 KVM: x86: switch hugepage recovery thread to vhost_task commit d96c77bd4eeba469bddbbb14323d2191684da82a upstream. kvm_vm_create_worker_thread() is meant to be used for kthreads that can consume significant amounts of CPU time on behalf of a VM or in response to how the VM behaves (for example how it accesses its memory). Therefore it wants to charge the CPU time consumed by that work to the VM's container. However, because of these threads, cgroups which have kvm instances inside never complete freezing. This can be trivially reproduced: root@test ~# mkdir /sys/fs/cgroup/test root@test ~# echo $$ > /sys/fs/cgroup/test/cgroup.procs root@test ~# qemu-system-x86_64 -nographic -enable-kvm and in another terminal: root@test ~# echo 1 > /sys/fs/cgroup/test/cgroup.freeze root@test ~# cat /sys/fs/cgroup/test/cgroup.events populated 1 frozen 0 The cgroup freezing happens in the signal delivery path but kvm_nx_huge_page_recovery_worker, while joining non-root cgroups, never calls into the signal delivery path and thus never gets frozen. Because the cgroup freezer determines whether a given cgroup is frozen by comparing the number of frozen threads to the total number of threads in the cgroup, the cgroup never becomes frozen and users waiting for the state transition may hang indefinitely. Since the worker kthread is tied to a user process, it's better if it behaves similarly to user tasks as much as possible, including being able to send SIGSTOP and SIGCONT. In fact, vhost_task is all that kvm_vm_create_worker_thread() wanted to be and more: not only it inherits the userspace process's cgroups, it has other niceties like being parented properly in the process tree. Use it instead of the homegrown alternative. Incidentally, the new code is also better behaved when you flip recovery back and forth to disabled and back to enabled. If your recovery period is 1 minute, it will run the next recovery after 1 minute independent of how many times you flipped the parameter. (Commit message based on emails from Tejun). Reported-by: Tejun Heo Reported-by: Luca Boccassi Acked-by: Tejun Heo Tested-by: Luca Boccassi Cc: stable@vger.kernel.org Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 49f7fd00bb85fdb10bedd9b72fd0578904ee563c Author: Eric Biggers Date: Wed Oct 16 17:00:42 2024 -0700 crypto: x86/aegis128 - access 32-bit arguments as 32-bit commit 3b2f2d22fb424e9bebda4dbf6676cbfc7f9f62cd upstream. Fix the AEGIS assembly code to access 'unsigned int' arguments as 32-bit values instead of 64-bit, since the upper bits of the corresponding 64-bit registers are not guaranteed to be zero. Note: there haven't been any reports of this bug actually causing incorrect behavior. Neither gcc nor clang guarantee zero-extension to 64 bits, but zero-extension is likely to happen in practice because most instructions that operate on 32-bit registers zero-extend to 64 bits. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Cc: stable@vger.kernel.org Reviewed-by: Ondrej Mosnacek Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 73e01790f4e3574c1359b19286dda65a3a0c5df7 Author: Adrian Hunter Date: Tue Oct 22 18:59:07 2024 +0300 perf/x86/intel/pt: Fix buffer full but size is 0 case commit 5b590160d2cf776b304eb054afafea2bd55e3620 upstream. If the trace data buffer becomes full, a truncated flag [T] is reported in PERF_RECORD_AUX. In some cases, the size reported is 0, even though data must have been added to make the buffer full. That happens when the buffer fills up from empty to full before the Intel PT driver has updated the buffer position. Then the driver calculates the new buffer position before calculating the data size. If the old and new positions are the same, the data size is reported as 0, even though it is really the whole buffer size. Fix by detecting when the buffer position is wrapped, and adjust the data size calculation accordingly. Example Use a very small buffer size (8K) and observe the size of truncated [T] data. Before the fix, it is possible to see records of 0 size. Before: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.105 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 5 19462712368111 0x19710 [0x40]: PERF_RECORD_AUX offset: 0 size: 0 flags: 0x1 [T] 5 19462712700046 0x19ba8 [0x40]: PERF_RECORD_AUX offset: 0x170 size: 0xe90 flags: 0x1 [T] After: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.040 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 1 113720802995 0x4948 [0x40]: PERF_RECORD_AUX offset: 0 size: 0x2000 flags: 0x1 [T] 1 113720979812 0x6b10 [0x40]: PERF_RECORD_AUX offset: 0x2000 size: 0x2000 flags: 0x1 [T] Fixes: 52ca9ced3f70 ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20241022155920.17511-2-adrian.hunter@intel.com Signed-off-by: Greg Kroah-Hartman commit 795021504dad91c7e4f9cdc0bc6cf91aba1ceaa9 Author: Claudiu Beznea Date: Wed Nov 6 10:18:17 2024 +0200 ASoC: da7213: Populate max_register to regmap_config commit 9d4f9f6a7bb1afbde57d08c98f2db4ff019ee19d upstream. On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped. Fixes: ef5c2eba2412 ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea Link: https://patch.msgid.link/20241106081826.1211088-23-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cafcd19ffcb01f87f48a7ec3270be7f6c3d576ec Author: Qiu-ji Chen Date: Mon Sep 30 18:12:16 2024 +0800 ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata() commit 1157733344651ca505e259d6554591ff156922fa upstream. An atomicity violation occurs when the validity of the variables da7219->clk_src and da7219->mclk_rate is being assessed. Since the entire assessment is not protected by a lock, the da7219 variable might still be in flux during the assessment, rendering this check invalid. To fix this issue, we recommend adding a lock before the block if ((da7219->clk_src == clk_id) && (da7219->mclk_rate == freq)) so that the legitimacy check for da7219->clk_src and da7219->mclk_rate is protected by the lock, ensuring the validity of the check. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 6d817c0e9fd7 ("ASoC: codecs: Add da7219 codec driver") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen Link: https://patch.msgid.link/20240930101216.23723-1-chenqiuji666@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4939ee00b642c8187b02cdd91d42de19845d078d Author: Ilya Zverev Date: Wed Nov 27 15:44:20 2024 +0200 ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5 21MES00B00 commit b682aa788e5f9f1ddacdfbb453e49fd3f4e83721 upstream. New ThinkPads need new quirk entries. Ilya has tested this one. Laptop product id is 21MES00B00, though the shorthand 21ME works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219533 Cc: stable@vger.kernel.org Signed-off-by: Ilya Zverev Link: https://patch.msgid.link/20241127134420.14471-1-ilya@zverev.info Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 676a787048aafd4d1b38a522b05a9cc77e1b0a33 Author: Artem Sadovnikov Date: Sat Oct 5 10:06:57 2024 +0000 jfs: xattr: check invalid xattr size more strictly commit d9f9d96136cba8fedd647d2c024342ce090133c2 upstream. Commit 7c55b78818cf ("jfs: xattr: fix buffer overflow for invalid xattr") also addresses this issue but it only fixes it for positive values, while ea_size is an integer type and can take negative values, e.g. in case of a corrupted filesystem. This still breaks validation and would overflow because of implicit conversion from int to size_t in print_hex_dump(). Fix this issue by clamping the ea_size value instead. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Signed-off-by: Artem Sadovnikov Signed-off-by: Dave Kleikamp Signed-off-by: Greg Kroah-Hartman commit a9a32b6bb47475e675d72494648ee37aaff77567 Author: Theodore Ts'o Date: Wed Oct 23 00:25:37 2024 -0400 ext4: fix FS_IOC_GETFSMAP handling commit 4a622e4d477bb12ad5ed4abbc7ad1365de1fa347 upstream. The original implementation ext4's FS_IOC_GETFSMAP handling only worked when the range of queried blocks included at least one free (unallocated) block range. This is because how the metadata blocks were emitted was as a side effect of ext4_mballoc_query_range() calling ext4_getfsmap_datadev_helper(), and that function was only called when a free block range was identified. As a result, this caused generic/365 to fail. Fix this by creating a new function ext4_getfsmap_meta_helper() which gets called so that blocks before the first free block range in a block group can get properly reported. Signed-off-by: Theodore Ts'o Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e95fed720c2c010b7559545b9fc77b6304821dd8 Author: Jeongjun Park Date: Thu Oct 3 21:53:37 2024 +0900 ext4: supress data-race warnings in ext4_free_inodes_{count,set}() commit 902cc179c931a033cd7f4242353aa2733bf8524c upstream. find_group_other() and find_group_orlov() read *_lo, *_hi with ext4_free_inodes_count without additional locking. This can cause data-race warning, but since the lock is held for most writes and free inodes value is generally not a problem even if it is incorrect, it is more appropriate to use READ_ONCE()/WRITE_ONCE() than to add locking. ================================================================== BUG: KCSAN: data-race in ext4_free_inodes_count / ext4_free_inodes_set write to 0xffff88810404300e of 2 bytes by task 6254 on cpu 1: ext4_free_inodes_set+0x1f/0x80 fs/ext4/super.c:405 __ext4_new_inode+0x15ca/0x2200 fs/ext4/ialloc.c:1216 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff88810404300e of 2 bytes by task 6257 on cpu 0: ext4_free_inodes_count+0x1c/0x80 fs/ext4/super.c:349 find_group_other fs/ext4/ialloc.c:594 [inline] __ext4_new_inode+0x6ec/0x2200 fs/ext4/ialloc.c:1017 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: stable@vger.kernel.org Signed-off-by: Jeongjun Park Reviewed-by: Andreas Dilger Link: https://patch.msgid.link/20241003125337.47283-1-aha310510@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b58f050f78e7609f062fc42ce682a0e74db59652 Author: Matti Vaittinen Date: Tue Aug 13 14:34:27 2024 +0300 irqdomain: Always associate interrupts for legacy domains commit 24d02c4e53e2f02da16b2ae8a1bc92553110ca25 upstream. The unification of irq_domain_create_legacy() missed the fact that interrupts must be associated even when the Linux interrupt number provided in the first_irq argument is 0. This breaks all call sites of irq_domain_create_legacy() which supply 0 as the first_irq argument. Enforce the association for legacy domains in __irq_domain_instantiate() to cure this. [ tglx: Massaged it slightly. ] Fixes: 70114e7f7585 ("irqdomain: Simplify simple and legacy domain creation") Reported-by: Jiaxun Yang Signed-off-by Matti Vaittinen Signed-off-by: Thomas Gleixner Tested-by: Jiaxun Yang Link: https://lore.kernel.org/all/c3379142-10bc-4f14-b8ac-a46927aeac38@gmail.com Signed-off-by: Greg Kroah-Hartman commit f7221ec081049426ef5c7c4815e138480349c02f Author: Manikanta Mylavarapu Date: Wed Oct 16 20:18:52 2024 +0530 soc: qcom: socinfo: fix revision check in qcom_socinfo_probe() commit 128fdbf36cddc2a901c4889ba1c89fa9f2643f2c upstream. In success case, the revision holds a non-null pointer. The current logic incorrectly returns an error for a non-null pointer, whereas it should return an error for a null pointer. The socinfo driver for IPQ9574 and IPQ5332 is currently broken, resulting in the following error message qcom-socinfo qcom-socinfo: probe with driver qcom-socinfo failed with error -12 Add a null check for the revision to ensure it returns an error only in failure case (null pointer). Fixes: e694d2b5c58b ("soc: qcom: Add check devm_kasprintf() returned value") Signed-off-by: Manikanta Mylavarapu Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20241016144852.2888679-1-quic_mmanikan@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit a9103a821f2c0e32ccc2f877c2a2cf6e05c02379 Author: Hans de Goede Date: Sat Oct 26 16:36:15 2024 +0200 ASoC: Intel: sst: Fix used of uninitialized ctx to log an error commit c1895ba181e560144601fafe46aeedbafdf4dbc4 upstream. Fix the new "LPE0F28" code path using the uninitialized ctx variable to log an error. Fixes: 6668610b4d8c ("ASoC: Intel: sst: Support LPE0F28 ACPI HID") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202410261106.EBx49ssy-lkp@intel.com/ Signed-off-by: Hans de Goede Link: https://patch.msgid.link/20241026143615.171821-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 368b7ec0ce88e94f7f071f73c3d00dbba5220f9a Author: Mikulas Patocka Date: Mon Nov 11 16:48:18 2024 +0100 dm-bufio: fix warnings about duplicate slab caches commit 42964e4b5e3ac95090bdd23ed7da2a941ccd902c upstream. The commit 4c39529663b9 adds a warning about duplicate cache names if CONFIG_DEBUG_VM is selected. These warnings are triggered by the dm-bufio code. The dm-bufio code allocates a slab cache with each client. It is not possible to preallocate the caches in the module init function because the size of auxiliary per-buffer data is not known at this point. So, this commit changes dm-bufio so that it appends a unique atomic value to the cache name, to avoid the warnings. Signed-off-by: Mikulas Patocka Fixes: 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y") Signed-off-by: Greg Kroah-Hartman commit 8f0ec8f21bc96b075571532ca41568b72525976f Author: Mikulas Patocka Date: Mon Nov 11 16:51:02 2024 +0100 dm-cache: fix warnings about duplicate slab caches commit 346dbf1b1345476a6524512892cceb931bee3039 upstream. The commit 4c39529663b9 adds a warning about duplicate cache names if CONFIG_DEBUG_VM is selected. These warnings are triggered by the dm-cache code. The dm-cache code allocates a slab cache for each device. This commit changes it to allocate just one slab cache in the module init function. Signed-off-by: Mikulas Patocka Fixes: 4c39529663b9 ("slab: Warn on duplicate cache names when DEBUG_VM=y") Signed-off-by: Greg Kroah-Hartman commit 9a5a8b5bd72169aa7a8ec800ef57be2f2cb4d9b2 Author: Dmitry Baryshkov Date: Sat Nov 9 02:04:14 2024 +0200 usb: typec: ucsi: glink: fix off-by-one in connector_status commit 4a22918810980897393fa1776ea3877e4baf8cca upstream. UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS. Correct the condition in the pmic_glink_ucsi_connector_status() callback, fixing Type-C orientation reporting for the third USB-C connector. Fixes: 76716fd5bf09 ("usb: typec: ucsi: glink: move GPIO reading into connector_status callback") Cc: stable@vger.kernel.org Reported-by: Abel Vesa Reviewed-by: Neil Armstrong Reviewed-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20241109-ucsi-glue-fixes-v2-1-8b21ff4f9fbe@linaro.org Signed-off-by: Greg Kroah-Hartman commit 5498c8792d927bac8bc067baeb51b697e09ca7a6 Author: Vitalii Mordan Date: Fri Nov 15 02:03:10 2024 +0300 usb: ehci-spear: fix call balance of sehci clk handling routines commit 40c974826734836402abfd44efbf04f63a2cc1c1 upstream. If the clock sehci->clk was not enabled in spear_ehci_hcd_drv_probe, it should not be disabled in any path. Conversely, if it was enabled in spear_ehci_hcd_drv_probe, it must be disabled in all error paths to ensure proper cleanup. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: 7675d6ba436f ("USB: EHCI: make ehci-spear a separate driver") Cc: stable@vger.kernel.org Signed-off-by: Vitalii Mordan Acked-by: Alan Stern Link: https://lore.kernel.org/r/20241114230310.432213-1-mordan@ispras.ru Signed-off-by: Greg Kroah-Hartman commit ea0fa76f61cf8e932d1d26e6193513230816e11d Author: Takashi Iwai Date: Mon Nov 25 15:46:16 2024 +0100 ALSA: usb-audio: Fix out of bounds reads when finding clock sources commit a3dd4d63eeb452cfb064a13862fb376ab108f6a6 upstream. The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. Reported-by: Benoît Sevens Cc: Link: https://lore.kernel.org/20241121140613.3651-1-bsevens@google.com Link: https://patch.msgid.link/20241125144629.20757-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 379d3b9799d9da953391e973b934764f01e03960 Author: Benoît Sevens Date: Wed Nov 20 12:41:44 2024 +0000 ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices commit b909df18ce2a998afef81d58bbd1a05dc0788c40 upstream. A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. Signed-off-by: Benoît Sevens Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@kernel.org Link: https://patch.msgid.link/20241120124144.3814457-1-bsevens@google.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 217bdce88b104269b73603b84d0ab4dd04f481bc Author: Qiu-ji Chen Date: Tue Nov 5 21:09:19 2024 +0800 xen: Fix the issue of resource not being properly released in xenbus_dev_probe() commit afc545da381ba0c651b2658966ac737032676f01 upstream. This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems. To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Fixes: 4bac07c993d0 ("xen: add the Xenbus sysfs and virtual device hotplug driver") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen Reviewed-by: Juergen Gross Message-ID: <20241105130919.4621-1-chenqiuji666@gmail.com> Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit acf2cd0ebb499f4be4812dd5824f9bbe73e84427 Author: Jakub Kicinski Date: Sat Nov 23 18:21:48 2024 -0800 net_sched: sch_fq: don't follow the fast path if Tx is behind now commit 122aba8c80618eca904490b1733af27fb8f07528 upstream. Recent kernels cause a lot of TCP retransmissions [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.24 GBytes 19.2 Gbits/sec 2767 442 KBytes [ 5] 1.00-2.00 sec 2.23 GBytes 19.1 Gbits/sec 2312 350 KBytes ^^^^ Replacing the qdisc with pfifo makes retransmissions go away. It appears that a flow may have a delayed packet with a very near Tx time. Later, we may get busy processing Rx and the target Tx time will pass, but we won't service Tx since the CPU is busy with Rx. If Rx sees an ACK and we try to push more data for the delayed flow we may fastpath the skb, not realizing that there are already "ready to send" packets for this flow sitting in the qdisc. Don't trust the fastpath if we are "behind" according to the projected Tx time for next flow waiting in the Qdisc. Because we consider anything within the offload window to be okay for fastpath we must consider the entire offload window as "now". Qdisc config: qdisc fq 8001: dev eth0 parent 1234:1 limit 10000p flow_limit 100p \ buckets 32768 orphan_mask 1023 bands 3 \ priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 \ weights 589824 196608 65536 quantum 3028b initial_quantum 15140b \ low_rate_threshold 550Kbit \ refill_delay 40ms timer_slack 10us horizon 10s horizon_drop For iperf this change seems to do fine, the reordering is gone. The fastpath still gets used most of the time: gc 0 highprio 0 fastpath 142614 throttled 418309 latency 19.1us xx_behind 2731 where "xx_behind" counts how many times we hit the new "return false". CC: stable@vger.kernel.org Fixes: 076433bd78d7 ("net_sched: sch_fq: add fast path for mostly idle qdisc") Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20241124022148.3126719-1-kuba@kernel.org Signed-off-by: Paolo Abeni [stable: drop the offload horizon, it's not supported / 0] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c1489651071ab1be46d2af1da8adb15c9fc3c069 Author: Niklas Schnelle Date: Mon Nov 25 16:02:38 2024 +0100 s390/pci: Fix potential double remove of hotplug slot [ Upstream commit c4a585e952ca403a370586d3f16e8331a7564901 ] In commit 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the device") the zpci_exit_slot() was moved from zpci_device_reserved() to zpci_release_device() with the intention of keeping the hotplug slot around until the device is actually removed. Now zpci_release_device() is only called once all references are dropped. Since the zPCI subsystem only drops its reference once the device is in the reserved state it follows that zpci_release_device() must only deal with devices in the reserved state. Despite that it contains code to tear down from both configured and standby state. For the standby case this already includes the removal of the hotplug slot so would cause a double removal if a device was ever removed in either configured or standby state. Instead of causing a potential double removal in a case that should never happen explicitly WARN_ON() if a device in non-reserved state is released and get rid of the dead code cases. Fixes: 6ee600bfbe0f ("s390/pci: remove hotplug slot when releasing the device") Reviewed-by: Matthew Rosato Reviewed-by: Gerd Bayer Tested-by: Gerd Bayer Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 376f4800f34a28def026ff5c5d4fc5e54e1744ff Author: Nícolas F. R. A. Prado Date: Tue Nov 26 15:09:43 2024 -0500 ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe [ Upstream commit 2f2020327cc8561d7c520d2f2d9acea84fa7b3a3 ] Following commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()"), COMP_DUMMY() became an array with zero length, and only gets populated with the dummy struct after the card is registered. Since the sound card driver's probe happens before the card registration, accessing any of the members of a dummy component during probe will result in undefined behavior. This can be observed in the mt8188 and mt8195 machine sound drivers. By omitting a dai link subnode in the sound card's node in the Devicetree, the default uninitialized dummy codec is used, and when its dai_name pointer gets passed to strcmp() it results in a null pointer dereference and a kernel panic. In addition to that, set_card_codec_info() in the generic helpers file, mtk-soundcard-driver.c, will populate a dai link with a dummy codec when a dai link node is present in DT but with no codec property. The result is that at probe time, a dummy codec can either be uninitialized with num_codecs = 0, or be an initialized dummy codec, with num_codecs = 1 and dai_name = "snd-soc-dummy-dai". In order to accommodate for both situations, check that num_codecs is not zero before accessing the codecs' fields but still check for the codec's dai name against "snd-soc-dummy-dai" as needed. While at it, also drop the check that dai_name is not null in the mt8192 driver, introduced in commit 4d4e1b6319e5 ("ASoC: mediatek: mt8192: Check existence of dai_name before dereferencing"), as it is actually redundant given the preceding num_codecs != 0 check. Fixes: 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") Signed-off-by: Nícolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Acked-by: Kuninori Morimoto Reviewed-by: Fei Shao Acked-by: Trevor Wu Link: https://patch.msgid.link/20241126-asoc-mtk-dummy-panic-v1-1-42d53e168d2e@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c92e92d3fdc5fb91baa12493a2aef6394130b476 Author: Venkata Prasad Potturu Date: Wed Nov 27 16:52:25 2024 +0530 ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry [ Upstream commit 4095cf872084ecfdfdb0e681f3e9ff9745acfa75 ] Add condition check to register ACP PDM sound card by reading _WOV acpi entry. Fixes: 5426f506b584 ("ASoC: amd: Add support for enabling DMIC on acp6x via _DSD") Signed-off-by: Venkata Prasad Potturu Link: https://patch.msgid.link/20241127112227.227106-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5486bf8abfe778b368d8fd1aa655dc01d0013ca Author: Zichen Xie Date: Tue Nov 26 13:24:49 2024 -0600 ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc() [ Upstream commit 9ad467a2b2716d4ed12f003b041aa6c776a13ff5 ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add NULL checks for all the kunit_kzalloc() in sound_kunit.c Fixes: 3e39acf56ede ("ALSA: core: Add sound core KUnit test") Signed-off-by: Zichen Xie Link: https://patch.msgid.link/20241126192448.12645-1-zichenxie0106@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2be9d38ad87252ada540d1a79b9d09142244da3a Author: chao liu Date: Tue Jun 27 10:03:16 2023 +0800 apparmor: fix 'Do simple duplicate message elimination' [ Upstream commit 9b897132424fe76bf6c61f22f9cf12af7f1d1e6a ] Multiple profiles shared 'ent->caps', so some logs missed. Fixes: 0ed3b28ab8bf ("AppArmor: mediation of non file objects") Signed-off-by: chao liu Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit e9770100f9da2a9b88e4b5165167d5d73c1c5a78 Author: Nirmoy Das Date: Thu Nov 14 16:05:37 2024 +0100 drm/xe/ufence: Wake up waiters after setting ufence->signalled [ Upstream commit 37a1cf288e4538eb39b38dbc745fe0da7ae53d94 ] If a previous ufence is not signalled, vm_bind will return -EBUSY. Delaying the modification of ufence->signalled can cause issues if the UMD reuses the same ufence so update ufence->signalled before waking up waiters. Cc: Matthew Brost Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3233 Fixes: 977e5b82e090 ("drm/xe: Expose user fence from xe_sync_entry") Reviewed-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20241114150537.4161573-1-nirmoy.das@intel.com Signed-off-by: Nirmoy Das (cherry picked from commit 553a5d14fcd927194c409b10faced6a6dbc678d1) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit c040cbe2e13da6454ae4748e04e53d885e1c9603 Author: Charles Han Date: Mon Nov 18 16:45:53 2024 +0800 ASoC: imx-audmix: Add NULL check in imx_audmix_probe [ Upstream commit e038f43edaf0083f6aa7c9415d86cf28dfd152f9 ] devm_kasprintf() can return a NULL pointer on failure,but this returned value in imx_audmix_probe() is not checked. Add NULL check in imx_audmix_probe(), to handle kernel NULL pointer dereference error. Fixes: 05d996e11348 ("ASoC: imx-audmix: Split capture device for audmix") Signed-off-by: Charles Han Link: https://patch.msgid.link/20241118084553.4195-1-hanchunchao@inspur.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0dd3d1de7a5957804ccd58c1b252f9e34710e3f6 Author: Zicheng Qu Date: Tue Nov 5 14:01:37 2024 +0000 drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp [ Upstream commit 2bc96c95070571c6c824e0d4c7783bee25a37876 ] This commit addresses a null pointer dereference issue in hwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Fixes: 0baae6246307 ("drm/amd/display: Refactor fast update to use new HWSS build sequence") Reviewed-by: Tom Chung Signed-off-by: Zicheng Qu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6b4ee2560d4d8de2688da68cd9581177035e0876 Author: Zicheng Qu Date: Tue Nov 5 14:01:36 2024 +0000 drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipe [ Upstream commit 6a057072ddd127255350357dd880903e8fa23f36 ] This commit addresses a null pointer dereference issue in dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") partially fixed the null pointer dereference issue. However, in dcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, and plane_state is accessed again through pipe_ctx. Multiple if statements directly call attributes of plane_state, leading to potential null pointer dereference issues. This patch adds necessary null checks to ensure stability. Fixes: 8e4ed3cf1642 ("drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe") Reviewed-by: Tom Chung Signed-off-by: Zicheng Qu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit db17ba5f9d240a4c0db430c8a3d463d2362ae77c Author: Steven 'Steve' Kendall Date: Fri Nov 15 21:17:58 2024 +0000 drm/radeon: Fix spurious unplug event on radeon HDMI [ Upstream commit 7037bb04265ef05c6ffad56d884b0df76f57b095 ] On several HP models (tested on HP 3125 and HP Probook 455 G2), spurious unplug events are emitted upon login on Chrome OS. This is likely due to the way Chrome OS restarts graphics upon login, so it's possible it's an issue on other distributions but not as common, though I haven't reproduced the issue elsewhere. Use logic from an earlier version of the merged change (see link below) which iterates over connectors and finds matching encoders, rather than the other way around. Also fixes an issue with screen mirroring on Chrome OS. I've deployed this patch on Fedora and did not observe any regression on these devices. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1569#note_1603002 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3771 Fixes: 20ea34710f7b ("drm/radeon: Add HD-audio component notifier support (v6)") Signed-off-by: Steven 'Steve' Kendall Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2cc72b7e54deeac0de3732a79c03b0332d83ce58 Author: Wu Hoi Pok Date: Sun Jun 30 12:59:21 2024 -0400 drm/radeon: change rdev->ddev to rdev_to_drm(rdev) [ Upstream commit fb1b5e1dd53fc834e12f69749cbc8484382599c4 ] This patch changes the way "drm_device" is accessed. It uses "rdev_to_drm(rdev)" instead of accessing the struct member directly. Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Signed-off-by: Wu Hoi Pok Signed-off-by: Alex Deucher Stable-dep-of: 7037bb04265e ("drm/radeon: Fix spurious unplug event on radeon HDMI") Signed-off-by: Sasha Levin commit 07b6186b5bd8834863a89d685217333b4e3dc152 Author: Wu Hoi Pok Date: Sun Jun 30 12:59:20 2024 -0400 drm/radeon: add helper rdev_to_drm(rdev) [ Upstream commit a6e23bec8ed184ed2a11080b28cdbd7a3024f0c0 ] Add helper rdev_to_drm(rdev), similar to amdgpu, most function should access the "drm_device" with "rdev_to_drm(rdev)" instead, where amdgpu has "adev_to_drm(adev)". It also makes changing from "*drm_device" to "drm_device" in "radeon_devicce" later on easier. Reviewed-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Signed-off-by: Wu Hoi Pok Signed-off-by: Alex Deucher Stable-dep-of: 7037bb04265e ("drm/radeon: Fix spurious unplug event on radeon HDMI") Signed-off-by: Sasha Levin commit c70d1fac935da166f94df316261b6f39195e5be7 Author: Kailang Yang Date: Thu Nov 14 15:21:09 2024 +0800 ALSA: hda/realtek: Update ALC256 depop procedure [ Upstream commit cc3d0b5dd989d3238d456f9fd385946379a9c13d ] Old procedure has a chance to meet Headphone no output. Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function") Signed-off-by: Kailang Yang Link: https://lore.kernel.org/463c5f93715d4714967041a0a8cec28e@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eb5d67d00ad17a5bd0920f455160dc2ccbd2dc78 Author: Gaosheng Cui Date: Wed Oct 16 19:03:35 2024 +0800 firmware_loader: Fix possible resource leak in fw_log_firmware_info() [ Upstream commit 369a9c046c2fdfe037f05b43b84c386bdbccc103 ] The alg instance should be released under the exception path, otherwise there may be resource leak here. To mitigate this, free the alg instance with crypto_free_shash when kmalloc fails. Fixes: 02fe26f25325 ("firmware_loader: Add debug message with checksum for FW file") Signed-off-by: Gaosheng Cui Reviewed-by: Amadeusz Sławiński Reviewed-by: Russ Weight Link: https://lore.kernel.org/r/20241016110335.3677924-1-cuigaosheng1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ef92cd55289a282910575c5b9d87f646f2d39b38 Author: Dan Carpenter Date: Mon Nov 11 14:08:06 2024 +0300 usb: typec: fix potential array underflow in ucsi_ccg_sync_control() [ Upstream commit e56aac6e5a25630645607b6856d4b2a17b2311a5 ] The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Signed-off-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/c69ef0b3-61b0-4dde-98dd-97b97f81d912@stanley.mountain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 58b093c95340007d00e8efbe153c60d4e6e30100 Author: Carl Vanderlip Date: Fri Oct 4 10:03:20 2024 -0700 bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian [ Upstream commit 23388a1b305e8aac714fafd5fdc72a580586bd0c ] Each of the __field() macros were triggering sparse warnings similar to: trace.h:87:1: sparse: sparse: cast to restricted __le64 trace.h:87:1: sparse: sparse: restricted __le64 degrades to integer trace.h:87:1: sparse: sparse: restricted __le64 degrades to integer Change each little endian type to its similarly sized native integer. Convert inputs into native endian. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402071859.8qMhgJEQ-lkp@intel.com/ Fixes: ceeb64f41fe6 ("bus: mhi: host: Add tracing support") Signed-off-by: Carl Vanderlip Reviewed-by: Jeffrey Hugo Reviewed-by: Mayank Rana Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20241004170321.4047492-1-quic_carlv@quicinc.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Sasha Levin commit ccae86fffcfd252782b9e2e4f8cb86e8e8f5a9da Author: Jiasheng Jiang Date: Mon Nov 4 19:40:59 2024 +0000 counter: ti-ecap-capture: Add check for clk_enable() [ Upstream commit 1437d9f1c56fce9c24e566508bce1d218dd5497a ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: 4e2f42aa00b6 ("counter: ti-ecap-capture: capture driver support for ECAP") Reviewed-by: Julien Panis Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20241104194059.47924-1-jiashengjiangcool@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit 7f343f245b30fa94bce0c6ff70a00878e9507c92 Author: Jiasheng Jiang Date: Mon Nov 4 19:18:25 2024 +0000 counter: stm32-timer-cnt: Add check for clk_enable() [ Upstream commit 842c3755a6bfbfcafa4a1438078d2485a9eb1d87 ] Add check for the return value of clk_enable() in order to catch the potential exception. Fixes: c5b8425514da ("counter: stm32-timer-cnt: add power management support") Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20241104191825.40155-1-jiashengjiangcool@gmail.com Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit 48d52d3168749e10c1c37cd4ceccd18625851741 Author: Charles Han Date: Fri Oct 25 15:07:44 2024 +0800 phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe [ Upstream commit bf373d2919d98f3d1fe1b19a0304f72fe74386d9 ] In rtk_usb3phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. Fixes: adda6e82a7de ("phy: realtek: usb: Add driver for the Realtek SoC USB 3.0 PHY") Signed-off-by: Charles Han Link: https://lore.kernel.org/r/20241025070744.149070-1-hanchunchao@inspur.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0b398b6b6c94315fd2ce3658e3cee96539dbd7b7 Author: Charles Han Date: Fri Oct 25 14:59:12 2024 +0800 phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe [ Upstream commit 04e3e9188291a183b27306ddb833722c0d083d6a ] In rtk_usb2phy_probe() devm_kzalloc() may return NULL but this returned value is not checked. Fixes: 134e6d25f6bd ("phy: realtek: usb: Add driver for the Realtek SoC USB 2.0 PHY") Signed-off-by: Charles Han Link: https://lore.kernel.org/r/20241025065912.143692-1-hanchunchao@inspur.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42ae9a02ba0b849d5566c20791f0c56458f51f6e Author: Raviteja Laggyshetty Date: Wed Sep 11 09:45:16 2024 +0000 interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock dependency [ Upstream commit 05123e3299dd6aa02508469b303262338c2a661c ] Return -EPROBE_DEFER from interconnect provider incase probe defer is received from devm_clk_bulk_get_all(). This would help in reattempting the inteconnect driver probe, once the required QoS clocks are available. Suggested-by: Bjorn Andersson Signed-off-by: Raviteja Laggyshetty Reviewed-by: Konrad Dybcio Fixes: 0a7be6b35da8 ("interconnect: qcom: icc-rpmh: Add QoS configuration support") Link: https://lore.kernel.org/r/20240911094516.16901-1-quic_rlaggysh@quicinc.com Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 588c74ae855823ad7415bec85a07d0c8a6eb2d71 Author: Michael Grzeschik Date: Wed Oct 16 15:58:06 2024 +0200 usb: gadget: uvc: wake pump everytime we update the free list [ Upstream commit adc292d54de9db2e6b8ecb7f81f278bbbaf713e9 ] Since the req_free list will updated if enqueuing one request was not possible it will be added back to the free list. With every available free request in the queue it is a valid case for the pump worker to use it and continue the pending bufferdata into requests for the req_ready list. Fixes: 6acba0345b68 ("usb:gadget:uvc Do not use worker thread to pump isoc usb requests") Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240403-uvc_request_length_by_interval-v7-1-e224bb1035f0@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1a09839f1ec310b1de960a143fc3bbdcac7a3c7a Author: Keita Morisaki Date: Sat Sep 28 20:50:05 2024 +0800 devres: Fix page faults when tracing devres from unloaded modules [ Upstream commit 765399553714e934a219d698953d435f4f99caa7 ] The devres ftrace event logs the name of the devres node, which is often a function name (e.g., "devm_work_drop") stringified by macros like devm_add_action. Currently, ftrace stores this name as a string literal address, which can become invalid when the module containing the string is unloaded. This results in page faults when ftrace tries to access the name. This behavior is problematic because the devres ftrace event is designed to trace resource management throughout a device driver's lifecycle, including during module unload. The event should be available even after the module is unloaded to properly diagnose resource issues. Fix the issue by copying the devres node name into the ftrace ring buffer using __assign_str(), instead of storing just the address. This ensures that ftrace can always access the name, even if the module is unloaded. This change increases the memory usage for each of the ftrace entry by 12-16 bytes assuming the average devres node name is 20 bytes long, depending on the size of const char *. Note that this change does not affect anything unless all of following conditions are met. - CONFIG_DEBUG_DEVRES is enabled - ftrace tracing is enabled - The devres event is enabled in ftrace tracing Fixes: 09705dcb63d2 ("devres: Enable trace events") Reviewed-by: Andy Shevchenko Signed-off-by: Keita Morisaki Link: https://lore.kernel.org/r/20240928125005.714781-1-keyz@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8de214b0f57193e0704b55748c8cd2e48e8c20bd Author: Jinjie Ruan Date: Mon Sep 23 11:55:56 2024 +0800 misc: apds990x: Fix missing pm_runtime_disable() [ Upstream commit 3c5d8b819d27012264edd17e6ae7fffda382fe44 ] The pm_runtime_disable() is missing in probe error path, so add it to fix it. Fixes: 92b1f84d46b2 ("drivers/misc: driver for APDS990X ALS and proximity sensors") Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/r/20240923035556.3009105-1-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0778d79e63ab077ab22fbe6eedf6b5c7ebec408b Author: Edward Adam Davis Date: Wed Oct 9 22:52:07 2024 +0800 USB: chaoskey: Fix possible deadlock chaoskey_list_lock [ Upstream commit d73dc7b182be4238b75278bfae16afb4c5564a58 ] [Syzbot reported two possible deadlocks] The first possible deadlock is: WARNING: possible recursive locking detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted -------------------------------------------- syz-executor363/2651 is trying to acquire lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x15d/0x2c0 drivers/usb/misc/chaoskey.c:322 but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x7f/0x2c0 drivers/usb/misc/chaoskey.c:299 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(chaoskey_list_lock); lock(chaoskey_list_lock); *** DEADLOCK *** The second possible deadlock is: WARNING: possible circular locking dependency detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted ------------------------------------------------------ kworker/0:2/804 is trying to acquire lock: ffffffff899dadb0 (minor_rwsem){++++}-{3:3}, at: usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186 but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_disconnect+0xa8/0x2a0 drivers/usb/misc/chaoskey.c:235 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (chaoskey_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x175/0x9c0 kernel/locking/mutex.c:752 chaoskey_open+0xdd/0x220 drivers/usb/misc/chaoskey.c:274 usb_open+0x186/0x220 drivers/usb/core/file.c:47 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x6cb/0x1390 fs/open.c:958 vfs_open+0x82/0x3f0 fs/open.c:1088 do_open fs/namei.c:3774 [inline] path_openat+0x1e6a/0x2d60 fs/namei.c:3933 do_filp_open+0x1dc/0x430 fs/namei.c:3960 do_sys_openat2+0x17a/0x1e0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (minor_rwsem){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain kernel/locking/lockdep.c:3904 [inline] __lock_acquire+0x250b/0x3ce0 kernel/locking/lockdep.c:5202 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5825 down_write+0x93/0x200 kernel/locking/rwsem.c:1577 usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186 chaoskey_disconnect+0xb7/0x2a0 drivers/usb/misc/chaoskey.c:236 usb_unbind_interface+0x1e8/0x970 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:569 [inline] device_remove+0x122/0x170 drivers/base/dd.c:561 __device_release_driver drivers/base/dd.c:1273 [inline] device_release_driver_internal+0x44a/0x610 drivers/base/dd.c:1296 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x396/0x9f0 drivers/base/core.c:3864 usb_disable_device+0x36c/0x7f0 drivers/usb/core/message.c:1418 usb_disconnect+0x2e1/0x920 drivers/usb/core/hub.c:2304 hub_port_connect drivers/usb/core/hub.c:5361 [inline] hub_port_connect_change drivers/usb/core/hub.c:5661 [inline] port_event drivers/usb/core/hub.c:5821 [inline] hub_event+0x1bed/0x4f40 drivers/usb/core/hub.c:5903 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(chaoskey_list_lock); lock(minor_rwsem); lock(chaoskey_list_lock); lock(minor_rwsem); *** DEADLOCK *** [Analysis] The first is AA lock, it because wrong logic, it need a unlock. The second is AB lock, it needs to rearrange the order of lock usage. Fixes: 422dc0a4d12d ("USB: chaoskey: fail open after removal") Reported-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=685e14d04fe35692d3bc Signed-off-by: Edward Adam Davis Tested-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/tencent_84EB865C89862EC22EE94CB3A7C706C59206@qq.com Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3811c580c128e89fd5207924f544896d774905e6 Author: Oliver Neukum Date: Wed Oct 2 15:21:41 2024 +0200 USB: chaoskey: fail open after removal [ Upstream commit 422dc0a4d12d0b80dd3aab3fe5943f665ba8f041 ] chaoskey_open() takes the lock only to increase the counter of openings. That means that the mutual exclusion with chaoskey_disconnect() cannot prevent an increase of the counter and chaoskey_open() returning a success. If that race is hit, chaoskey_disconnect() will happily free all resources associated with the device after it has dropped the lock, as it has read the counter as zero. To prevent this race chaoskey_open() has to check the presence of the device under the lock. However, the current per device lock cannot be used, because it is a part of the data structure to be freed. Hence an additional global mutex is needed. The issue is as old as the driver. Signed-off-by: Oliver Neukum Reported-by: syzbot+422188bce66e76020e55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55 Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Rule: add Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20241002132201.552578-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a91ca7a7889a5cf3083d8a221822b8d8dd5f82d3 Author: Oliver Neukum Date: Tue Sep 24 10:43:45 2024 +0200 usb: yurex: make waiting on yurex_write interruptible [ Upstream commit e0aa9614ab0fd35b404e4b16ebe879f9fc152591 ] The IO yurex_write() needs to wait for in order to have a device ready for writing again can take a long time time. Consequently the sleep is done in an interruptible state. Therefore others waiting for yurex_write() itself to finish should use mutex_lock_interruptible. Signed-off-by: Oliver Neukum Fixes: 6bc235a2e24a5 ("USB: add driver for Meywa-Denki & Kayac YUREX") Rule: add Link: https://lore.kernel.org/stable/20240924084415.300557-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20240924084415.300557-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42316ded03684fe89bfdfd3f4d673205f08881e9 Author: Jeongjun Park Date: Thu Sep 19 19:34:03 2024 +0900 usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read() [ Upstream commit 44feafbaa66ec86232b123bb8437a6a262442025 ] iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Signed-off-by: Jeongjun Park Link: https://lore.kernel.org/r/20240919103403.3986-1-aha310510@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d8ca07f2d897a196d2bfe13182bc55876196ec09 Author: Christophe JAILLET Date: Tue Sep 10 20:36:06 2024 +0200 iio: light: al3010: Fix an error handling path in al3010_probe() [ Upstream commit a4b7064d34186cf4970fe0333c3b27346cf8f819 ] If i2c_smbus_write_byte_data() fails in al3010_init(), al3010_set_pwr(false) is not called. In order to avoid such a situation, move the devm_add_action_or_reset() witch calls al3010_set_pwr(false) right after a successful al3010_set_pwr(true). Fixes: c36b5195ab70 ("iio: light: add Dyna-Image AL3010 driver") Signed-off-by: Christophe JAILLET Link: https://patch.msgid.link/ee5d10a2dd2b70f29772d5df33774d3974a80f30.1725993353.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8fd14b6518d358400ca3c2b4d5f55a475e05766f Author: Paolo Abeni Date: Sun Nov 24 16:40:58 2024 +0100 ipmr: fix tables suspicious RCU usage [ Upstream commit fc9c273d6daaa9866f349bbe8cae25c67764c456 ] Similar to the previous patch, plumb the RCU lock inside the ipmr_get_table(), provided a lockless variant and apply the latter in the few spots were the lock is already held. Fixes: 709b46e8d90b ("net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT") Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables") Reviewed-by: David Ahern Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 877a5fd85ebe7210a1e96f2ab2955f3dfb5f8e38 Author: Paolo Abeni Date: Sun Nov 24 16:40:57 2024 +0100 ip6mr: fix tables suspicious RCU usage [ Upstream commit f1553c9894b4dbeb10a2ab15ab1aa113b3b4047c ] Several places call ip6mr_get_table() with no RCU nor RTNL lock. Add RCU protection inside such helper and provide a lockless variant for the few callers that already acquired the relevant lock. Note that some users additionally reference the table outside the RCU lock. That is actually safe as the table deletion can happen only after all table accesses are completed. Fixes: e2d57766e674 ("net: Provide compat support for SIOCGETMIFCNT_IN6 and SIOCGETSGCNT_IN6.") Fixes: d7c31cbde4bc ("net: ip6mr: add RTM_GETROUTE netlink op") Reviewed-by: David Ahern Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit d0eb14cb8c08b00c36a3d5dc57a6f428b301f721 Author: Kuniyuki Iwashima Date: Sat Nov 23 09:42:36 2024 -0800 tcp: Fix use-after-free of nreq in reqsk_timer_handler(). [ Upstream commit c31e72d021db2714df03df6c42855a1db592716c ] The cited commit replaced inet_csk_reqsk_queue_drop_and_put() with __inet_csk_reqsk_queue_drop() and reqsk_put() in reqsk_timer_handler(). Then, oreq should be passed to reqsk_put() instead of req; otherwise use-after-free of nreq could happen when reqsk is migrated but the retry attempt failed (e.g. due to timeout). Let's pass oreq to reqsk_put(). Fixes: e8c526f2bdf1 ("tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().") Reported-by: Liu Jian Closes: https://lore.kernel.org/netdev/1284490f-9525-42ee-b7b8-ccadf6606f6d@huawei.com/ Signed-off-by: Kuniyuki Iwashima Reviewed-by: Vadim Fedorenko Reviewed-by: Liu Jian Reviewed-by: Eric Dumazet Reviewed-by: Martin KaFai Lau Link: https://patch.msgid.link/20241123174236.62438-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f4e28eb3698ffeffd37ba884e6463252afb43621 Author: Michal Luczaj Date: Tue Nov 19 14:31:42 2024 +0100 rxrpc: Improve setsockopt() handling of malformed user input [ Upstream commit 02020056647017e70509bb58c3096448117099e1 ] copy_from_sockptr() does not return negative value on error; instead, it reports the number of bytes that failed to copy. Since it's deprecated, switch to copy_safe_from_sockptr(). Note: Keeping the `optlen != sizeof(unsigned int)` check as copy_safe_from_sockptr() by itself would also accept optlen > sizeof(unsigned int). Which would allow a more lenient handling of inputs. Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: Michal Luczaj Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 033bcff65a76db2b5521b811d6c7838a243af63c Author: Michal Luczaj Date: Tue Nov 19 14:31:41 2024 +0100 llc: Improve setsockopt() handling of malformed user input [ Upstream commit 1465036b10be4b8b00eb31c879e86de633ad74c1 ] copy_from_sockptr() is used incorrectly: return value is the number of bytes that could not be copied. Since it's deprecated, switch to copy_safe_from_sockptr(). Note: Keeping the `optlen != sizeof(int)` check as copy_safe_from_sockptr() by itself would also accept optlen > sizeof(int). Which would allow a more lenient handling of inputs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Suggested-by: David Wei Signed-off-by: Michal Luczaj Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6a25ce9b4af6dc26ee2b9c32d6bd37620bf9739e Author: Luiz Augusto von Dentz Date: Thu Nov 21 11:09:22 2024 -0500 Bluetooth: MGMT: Fix possible deadlocks [ Upstream commit a66dfaf18fd61bb75ef8cee83db46b2aadf153d0 ] This fixes possible deadlocks like the following caused by hci_cmd_sync_dequeue causing the destroy function to run: INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000 Workqueue: hci0 hci_cmd_sync_work [bluetooth] Call Trace: __schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedule_preempt_disabled+0x1c/0x30 __mutex_lock.constprop.0+0x3ef/0x7a0 __mutex_lock_slowpath+0x13/0x20 mutex_lock+0x3c/0x50 mgmt_set_connectable_complete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hci_cmd_sync_dequeue+0xae/0x130 [bluetooth] ? __pfx_cmd_complete_rsp+0x10/0x10 [bluetooth] cmd_complete_rsp+0x26/0x80 [bluetooth] mgmt_pending_foreach+0x4d/0x70 [bluetooth] __mgmt_power_off+0x8d/0x180 [bluetooth] ? _raw_spin_unlock_irq+0x23/0x40 hci_dev_close_sync+0x445/0x5b0 [bluetooth] hci_set_powered_sync+0x149/0x250 [bluetooth] set_powered_sync+0x24/0x60 [bluetooth] hci_cmd_sync_work+0x90/0x150 [bluetooth] process_one_work+0x13e/0x300 worker_thread+0x2f7/0x420 ? __pfx_worker_thread+0x10/0x10 kthread+0x107/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3d/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Tested-by: Kiran K Fixes: f53e1c9c726d ("Bluetooth: MGMT: Fix possible crash on mgmt_index_removed") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 6b75f32bce90c085c89c45761373d940fdcff68c Author: Luiz Augusto von Dentz Date: Fri Nov 15 10:45:31 2024 -0500 Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync [ Upstream commit 0b882940665ca2849386ee459d4331aa2f8c4e7d ] This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 Read of size 8 at addr ffff888029b4dd18 by task kworker/u9:0/54 CPU: 1 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-01155-gf723224742fc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 q kasan_report+0x143/0x180 mm/kasan/report.c:601 set_powered_sync+0x3a/0xc0 net/bluetooth/mgmt.c:1353 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:328 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd10 kernel/workqueue.c:3389 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4193 kmalloc_noprof include/linux/slab.h:681 [inline] kzalloc_noprof include/linux/slab.h:807 [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 set_powered+0x3cd/0x5e0 net/bluetooth/mgmt.c:1394 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa72/0xc90 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5246: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x149/0x360 mm/slub.c:4598 settings_rsp+0x2bc/0x390 net/bluetooth/mgmt.c:1443 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 __mgmt_power_off+0x112/0x420 net/bluetooth/mgmt.c:9455 hci_dev_close_sync+0x665/0x11a0 net/bluetooth/hci_sync.c:5191 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 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:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83gv entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: syzbot+03d6270b6425df1605bf@syzkaller.appspotmail.com Tested-by: syzbot+03d6270b6425df1605bf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=03d6270b6425df1605bf Fixes: 275f3f648702 ("Bluetooth: Fix not checking MGMT cmd pending queue") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 08da5945ba2971f36c2ff78e5ff96cc40e54cd3b Author: Michael Chan Date: Fri Nov 22 14:45:46 2024 -0800 bnxt_en: Unregister PTP during PCI shutdown and suspend [ Upstream commit 3661c05c54e8db7064aa96a0774654740974dffc ] If we go through the PCI shutdown or suspend path, we shutdown the NIC but PTP remains registered. If the kernel continues to run for a little bit, the periodic PTP .do_aux_work() function may be called and it will read the PHC from the BAR register. Since the device has already been disabled, it will cause a PCIe completion timeout. Fix it by calling bnxt_ptp_clear() in the PCI shutdown/suspend handlers. bnxt_ptp_clear() will unregister from PTP and .do_aux_work() will be canceled. In bnxt_resume(), we need to re-initialize PTP. Fixes: a521c8a01d26 ("bnxt_en: Move bnxt_ptp_init() from bnxt_open() back to bnxt_init_one()") Cc: Richard Cochran Reviewed-by: Somnath Kotur Reviewed-by: Pavan Chebbi Reviewed-by: Kalesh AP Signed-off-by: Michael Chan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c62d4e0aa96a9ef527aa3fcc967d9d7e3b31174c Author: Michael Chan Date: Fri Nov 22 14:45:45 2024 -0800 bnxt_en: Refactor bnxt_ptp_init() [ Upstream commit 1e9614cd956268e10a669c0593e7e54d03d0c087 ] Instead of passing the 2nd parameter phc_cfg to bnxt_ptp_init(). Store it in bp->ptp_cfg so that the caller doesn't need to know what the value should be. In the next patch, we'll need to call bnxt_ptp_init() in bnxt_resume() and this will make it easier. Reviewed-by: Somnath Kotur Reviewed-by: Pavan Chebbi Reviewed-by: Kalesh AP Signed-off-by: Michael Chan Signed-off-by: Paolo Abeni Stable-dep-of: 3661c05c54e8 ("bnxt_en: Unregister PTP during PCI shutdown and suspend") Signed-off-by: Sasha Levin commit bf54a7660fc8d2166f41ff1d67a643b15d8b2250 Author: Shravya KN Date: Fri Nov 22 14:45:44 2024 -0800 bnxt_en: Fix receive ring space parameters when XDP is active [ Upstream commit 3051a77a09dfe3022aa012071346937fdf059033 ] The MTU setting at the time an XDP multi-buffer is attached determines whether the aggregation ring will be used and the rx_skb_func handler. This is done in bnxt_set_rx_skb_mode(). If the MTU is later changed, the aggregation ring setting may need to be changed and it may become out-of-sync with the settings initially done in bnxt_set_rx_skb_mode(). This may result in random memory corruption and crashes as the HW may DMA data larger than the allocated buffer size, such as: BUG: kernel NULL pointer dereference, address: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1 Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E_3A12 08/26/2021 RIP: 0010:bnxt_rx_pkt+0xe97/0x1ae0 [bnxt_en] Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __bnxt_poll_work+0x1c2/0x3e0 [bnxt_en] To address the issue, we now call bnxt_set_rx_skb_mode() within bnxt_change_mtu() to properly set the AGG rings configuration and update rx_skb_func based on the new MTU value. Additionally, BNXT_FLAG_NO_AGG_RINGS is cleared at the beginning of bnxt_set_rx_skb_mode() to make sure it gets set or cleared based on the current MTU. Fixes: 08450ea98ae9 ("bnxt_en: Fix max_mtu setting for multi-buf XDP") Co-developed-by: Somnath Kotur Signed-off-by: Somnath Kotur Signed-off-by: Shravya KN Signed-off-by: Michael Chan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 67f9837134caa7c96e4c9fc94b9017cebe782f83 Author: Shravya KN Date: Fri Nov 22 14:45:42 2024 -0800 bnxt_en: Set backplane link modes correctly for ethtool [ Upstream commit 5007991670941c132fb3bc0484c009cf4bcea30f ] Use the return value from bnxt_get_media() to determine the port and link modes. bnxt_get_media() returns the proper BNXT_MEDIA_KR when the PHY is backplane. This will correct the ethtool settings for backplane devices. Fixes: 5d4e1bf60664 ("bnxt_en: extend media types to supported and autoneg modes") Reviewed-by: Somnath Kotur Signed-off-by: Shravya KN Signed-off-by: Michael Chan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4e1922816da2462f0132713a15dc5bdb8b925260 Author: Saravanan Vajravel Date: Fri Nov 22 14:45:41 2024 -0800 bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down [ Upstream commit 5311598f7f3293683cdc761df71ae3469327332c ] After successful PCIe AER recovery, FW will reset all resource reservations. If it is IF_UP, the driver will call bnxt_open() and all resources will be reserved again. It it is IF_DOWN, we should call bnxt_reserve_rings() so that we can reserve resources including RoCE resources to allow RoCE to resume after AER. Without this patch, RoCE fails to resume in this IF_DOWN scenario. Later, if it becomes IF_UP, bnxt_open() will see that resources have been reserved and will not reserve again. Fixes: fb1e6e562b37 ("bnxt_en: Fix AER recovery.") Reviewed-by: Somnath Kotur Reviewed-by: Pavan Chebbi Reviewed-by: Kashyap Desai Signed-off-by: Saravanan Vajravel Signed-off-by: Michael Chan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c07727f2c2078b98c9cd2033203bf8b8f756a6ee Author: Eric Dumazet Date: Fri Nov 22 17:13:43 2024 +0000 net: hsr: fix hsr_init_sk() vs network/transport headers. [ Upstream commit 9cfb5e7f0ded2bfaabc270ceb5f91d13f0e805b9 ] Following sequence in hsr_init_sk() is invalid : skb_reset_mac_header(skb); skb_reset_mac_len(skb); skb_reset_network_header(skb); skb_reset_transport_header(skb); It is invalid because skb_reset_mac_len() needs the correct network header, which should be after the mac header. This patch moves the skb_reset_network_header() and skb_reset_transport_header() before the call to dev_hard_header(). As a result skb->mac_len is no longer set to a value close to 65535. Fixes: 48b491a5cc74 ("net: hsr: fix mac_len checks") Signed-off-by: Eric Dumazet Cc: George McCollister Link: https://patch.msgid.link/20241122171343.897551-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9620965856e58905ac5e1fb1d23ca1c83cf03387 Author: Csókás, Bence Date: Fri Nov 22 15:13:02 2024 +0100 spi: atmel-quadspi: Fix register name in verbose logging function [ Upstream commit 2ac40e6d0ccdd93031f8b1af61b0fe5cdd704923 ] `atmel_qspi_reg_name()` is used for pretty-printing register offsets for verbose logging of register accesses. However, due to a typo (likely a copy-paste error), QSPI_RD's offset prints as "MR", the name of the previous register. Fix this typo. Fixes: c528ecfbef04 ("spi: atmel-quadspi: Add verbose debug facilities to monitor register accesses") Signed-off-by: Csókás, Bence Reviewed-by: Alexander Dahl Link: https://patch.msgid.link/20241122141302.2599636-1-csokas.bence@prolan.hu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit af702d3fa0b60ce54cd9683a0c6f8161fc339ad8 Author: Hariprasad Kelam Date: Fri Nov 22 21:50:35 2024 +0530 octeontx2-af: Quiesce traffic before NIX block reset [ Upstream commit 762ca6eed026346d9d41ed5ac633083c4f1e5071 ] During initialization, the AF driver resets all blocks. The RPM (MAC) block and NIX block operate on a credit-based model. When the NIX block resets during active traffic flow, it doesn't release credits to the RPM block. This causes the RPM FIFO to overflow, leading to receive traffic struck. To address this issue, the patch introduces the following changes: 1. Stop receiving traffic at the MAC level during AF driver initialization. 2. Perform an X2P reset (prevents RXFIFO of all LMACS from pushing data) 3. Reset the NIX block. 4. Clear the X2P reset and re-enable receiving traffic. Fixes: 54d557815e15 ("octeontx2-af: Reset all RVU blocks") Signed-off-by: Hariprasad Kelam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e8db69869015dff2fa1caf3ced819140b45a2604 Author: Hariprasad Kelam Date: Fri Nov 22 21:50:34 2024 +0530 octeontx2-af: RPM: fix stale FCFEC counters [ Upstream commit 6fc2164108462b913a1290fa2c44054c70b060ef ] The corrected words register(FCFECX_VL0_CCW_LO)/Uncorrected words register (FCFECX_VL0_NCCW_LO) of FCFEC counter has different LMAC offset which needs to be accessed differently. Fixes: 84ad3642115d ("octeontx2-af: Add FEC stats for RPM/RPM_USX block") Signed-off-by: Hariprasad Kelam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c77181fa14815dde0e5f8a407104b6f98baef864 Author: Hariprasad Kelam Date: Fri Nov 22 21:50:33 2024 +0530 octeontx2-af: RPM: fix stale RSFEC counters [ Upstream commit 07cd1eb166a3fa7244afa74d48bd13c9df7c559d ] The earlier patch sets the 'Stats control register' for RPM receive/transmit statistics instead of RSFEC statistics, causing the driver to return stale FEC counters. Fixes: 84ad3642115d ("octeontx2-af: Add FEC stats for RPM/RPM_USX block") Signed-off-by: Hariprasad Kelam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5553788895e9166e40da381609c045cf9fcdb9f1 Author: Hariprasad Kelam Date: Fri Nov 22 21:50:32 2024 +0530 octeontx2-af: RPM: Fix low network performance [ Upstream commit d1e8884e050c1255a9ceb477f5ff926ee9214a23 ] Low network performance is observed even on RPMs with larger FIFO lengths. The cn10kb silicon has three RPM blocks with the following FIFO sizes: -------------------- | RPM0 | 256KB | | RPM1 | 256KB | | RPM2 | 128KB | -------------------- The current design stores the FIFO length in a common structure for all RPMs (mac_ops). As a result, the FIFO length of the last RPM is applied to all RPMs, leading to reduced network performance. This patch resolved the problem by storing the fifo length in per MAC structure (cgx). Fixes: b9d0fedc6234 ("octeontx2-af: cn10kb: Add RPM_USX MAC support") Signed-off-by: Hariprasad Kelam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0aa930225b452252bca81bdc6b34f228ee661d0d Author: Hariprasad Kelam Date: Fri Nov 22 21:50:31 2024 +0530 octeontx2-af: RPM: Fix mismatch in lmac type [ Upstream commit 7ebbbb23ea5b6d051509cb11399afac5042c9266 ] Due to a bug in the previous patch, there is a mismatch between the lmac type reported by the driver and the actual hardware configuration. Fixes: 3ad3f8f93c81 ("octeontx2-af: cn10k: MAC internal loopback support") Signed-off-by: Hariprasad Kelam Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f2db797fc6d20d0ab585ab9a1a759c5dd9763d62 Author: Maxime Chevallier Date: Fri Nov 22 15:12:55 2024 +0100 net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken [ Upstream commit 407618d66dba55e7db1278872e8be106808bbe91 ] On DWMAC3 and later, there's a RX Watchdog interrupt that's used for interrupt coalescing. It's known to be buggy on some platforms, and dwmac-socfpga appears to be one of them. Changing the interrupt coalescing from ethtool doesn't appear to have any effect here. Without disabling RIWT (Received Interrupt Watchdog Timer, I believe...), we observe latencies while receiving traffic that amount to around ~0.4ms. This was discovered with NTP but can be easily reproduced with a simple ping. Without this patch : 64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.657 ms With this patch : 64 bytes from 192.168.5.2: icmp_seq=1 ttl=64 time=0.254 ms Fixes: 801d233b7302 ("net: stmmac: Add SOCFPGA glue driver") Signed-off-by: Maxime Chevallier Link: https://patch.msgid.link/20241122141256.764578-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 70ca9b4008298f4855c994c61f47815d2c4da19a Author: Vitalii Mordan Date: Thu Nov 21 23:06:58 2024 +0300 marvell: pxa168_eth: fix call balance of pep->clk handling routines [ Upstream commit b032ae57d4fe2b2445e3bc190db6fcaa8c102f68 ] If the clock pep->clk was not enabled in pxa168_eth_probe, it should not be disabled in any path. Conversely, if it was enabled in pxa168_eth_probe, it must be disabled in all error paths to ensure proper cleanup. Use the devm_clk_get_enabled helper function to ensure proper call balance for pep->clk. Found by Linux Verification Center (linuxtesting.org) with Klever. Fixes: a49f37eed22b ("net: add Fast Ethernet driver for PXA168.") Signed-off-by: Vitalii Mordan Link: https://patch.msgid.link/20241121200658.2203871-1-mordan@ispras.ru Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 7c0f5d0eaf3325b3d6d677bf6fd792eca341c6a2 Author: Rosen Penev Date: Thu Nov 21 11:31:52 2024 -0800 net: mdio-ipq4019: add missing error check [ Upstream commit 9cc8d0ecdd2aad42e377e971e3bb114339df609e ] If an optional resource is found but fails to remap, return on failure. Avoids any potential problems when using the iomapped resource as the assumption is that it's available. Fixes: 23a890d493e3 ("net: mdio: Add the reset function for IPQ MDIO driver") Signed-off-by: Rosen Penev Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20241121193152.8966-1-rosenp@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 851b3bb105c595cc20b8dcc1b4de029061ce2b76 Author: Hangbin Liu Date: Wed Nov 20 09:51:07 2024 +0000 net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged [ Upstream commit 00b5b7aab9e422d00d5a9d03d7e0760a76b5d57f ] RFC8981 section 3.4 says that existing temporary addresses must have their lifetimes adjusted so that no temporary addresses should ever remain "valid" or "preferred" longer than the incoming SLAAC Prefix Information. This would strongly imply in Linux's case that if the "mngtmpaddr" address is deleted or un-flagged as such, its corresponding temporary addresses must be cleared out right away. But now the temporary address is renewed even after ‘mngtmpaddr’ is removed or becomes unmanaged as manage_tempaddrs() set temporary addresses prefered/valid time to 0, and later in addrconf_verify_rtnl() all checkings failed to remove the addresses. Fix this by deleting the temporary address directly for these situations. Fixes: 778964f2fdf0 ("ipv6/addrconf: fix timing bug in tempaddr regen") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 783c2c6e61c5a04eb8baea598753d5fa174dbe85 Author: Sidraya Jayagond Date: Tue Nov 19 16:22:19 2024 +0100 s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() [ Upstream commit ebaf81317e42aa990ad20b113cfe3a7b20d4e937 ] Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] Fixes: eac3731bd04c ("[S390]: Add AF_IUCV socket support") Reviewed-by: Alexandra Winter Reviewed-by: Thorsten Winkler Signed-off-by: Sidraya Jayagond Signed-off-by: Alexandra Winter Reviewed-by: David Wei Link: https://patch.msgid.link/20241119152219.3712168-1-wintera@linux.ibm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 416e60c4951c153aed64aa30ca82c249ff6bcb9a Author: Yuezhang Mo Date: Thu Oct 17 09:25:06 2024 +0800 exfat: fix file being changed by unaligned direct write [ Upstream commit 2e94e5bb94a3e641a25716a560bf474225fda83c ] Unaligned direct writes are invalid and should return an error without making any changes, rather than extending ->valid_size and then returning an error. Therefore, alignment checking is required before extending ->valid_size. Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength") Signed-off-by: Yuezhang Mo Co-developed-by: Namjae Jeon Signed-off-by: Namjae Jeon Signed-off-by: Sasha Levin commit 6406d0ce0414b807af5d2a4b781c3f3ee52b8a4d Author: Jakub Kicinski Date: Tue Nov 19 14:44:31 2024 -0800 netlink: fix false positive warning in extack during dumps [ Upstream commit 3bf39fa849ab8ed52abb6715922e6102d3df9f97 ] Commit under fixes extended extack reporting to dumps. It works under normal conditions, because extack errors are usually reported during ->start() or the first ->dump(), it's quite rare that the dump starts okay but fails later. If the dump does fail later, however, the input skb will already have the initiating message pulled, so checking if bad attr falls within skb->data will fail. Switch the check to using nlh, which is always valid. syzbot found a way to hit that scenario by filling up the receive queue. In this case we initiate a dump but don't call ->dump() until there is read space for an skb. WARNING: CPU: 1 PID: 5845 at net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 Call Trace: netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1073 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267 __do_sys_recvfrom net/socket.c:2285 [inline] __se_sys_recvfrom net/socket.c:2281 [inline] __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff37dd17a79 Reported-by: syzbot+d4373fa8042c06cefa84@syzkaller.appspotmail.com Fixes: 8af4f60472fc ("netlink: support all extack types in dumps") Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20241119224432.1713040-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e54f1237a8018bca25fe58cc3b5a0442051315d1 Author: Guenter Roeck Date: Tue Nov 19 13:32:02 2024 -0800 net: microchip: vcap: Add typegroup table terminators in kunit tests [ Upstream commit f164b296638d1eb1fb1c537e93ab5c8b49966546 ] VCAP API unit tests fail randomly with errors such as # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:387 Expected 134 + 7 == iter.offset, but 134 + 7 == 141 (0x8d) iter.offset == 17214 (0x433e) # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:388 Expected 5 == iter.reg_idx, but iter.reg_idx == 702 (0x2be) # vcap_api_iterator_init_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_kunit.c:389 Expected 11 == iter.reg_bitpos, but iter.reg_bitpos == 15 (0xf) # vcap_api_iterator_init_test: pass:0 fail:1 skip:0 total:1 Comments in the code state that "A typegroup table ends with an all-zero terminator". Add the missing terminators. Some of the typegroups did have a terminator of ".offset = 0, .width = 0, .value = 0,". Replace those terminators with "{ }" (no trailing ',') for consistency and to excplicitly state "this is a terminator". Fixes: 67d637516fa9 ("net: microchip: sparx5: Adding KUNIT test for the VCAP API") Cc: Steen Hegelund Signed-off-by: Guenter Roeck Reviewed-by: Daniel Machon Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20241119213202.2884639-1-linux@roeck-us.net Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2156f35c3eb6477c1f24be15de8ae5177dd30cad Author: Oleksij Rempel Date: Mon Nov 18 15:03:51 2024 +0100 net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL configuration [ Upstream commit e863ff806f72098bccaf8fa89c80d9ad6187c3b0 ] Validate Wake-on-LAN (WoL) options in `lan78xx_set_wol` before calling `usb_autopm_get_interface`. This prevents USB autopm refcounting issues and ensures the adapter can properly enter autosuspend when invalid WoL options are provided. Fixes: eb9ad088f966 ("lan78xx: Check for supported Wake-on-LAN modes") Signed-off-by: Oleksij Rempel Acked-by: Florian Fainelli Link: https://patch.msgid.link/20241118140351.2398166-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 79b64941f23929035c7d362e72b6b6e1596b1dcd Author: Pavan Chebbi Date: Mon Nov 18 21:57:41 2024 -0800 tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets [ Upstream commit 614f4d166eeeb9bd709b0ad29552f691c0f45776 ] The hardware on Broadcom 1G chipsets have a known limitation where they cannot handle DMA addresses that cross over 4GB. When such an address is encountered, the hardware sets the address overflow error bit in the DMA status register and triggers a reset. However, BCM57766 hardware is setting the overflow bit and triggering a reset in some cases when there is no actual underlying address overflow. The hardware team analyzed the issue and concluded that it is happening when the status block update has an address with higher (b16 to b31) bits as 0xffff following a previous update that had lowest bits as 0xffff. To work around this bug in the BCM57766 hardware, set the coherent dma mask from the current 64b to 31b. This will ensure that upper bits of the status block DMA address are always at most 0x7fff, thus avoiding the improper overflow check described above. This work around is intended for only status block and ring memories and has no effect on TX and RX buffers as they do not require coherent memory. Fixes: 72f2afb8a685 ("[TG3]: Add DMA address workaround") Reported-by: Salam Noureddine Reviewed-by: Kalesh AP Reviewed-by: Somnath Kotur Signed-off-by: Pavan Chebbi Reviewed-by: Michal Kubiak Link: https://patch.msgid.link/20241119055741.147144-1-pavan.chebbi@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b03d68c74244a4d613ec41abf15c3951f850e23b Author: Oleksij Rempel Date: Sat Nov 16 14:05:58 2024 +0100 net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device [ Upstream commit ae7370e61c5d8f5bcefc2d4fca724bd4e9bbf789 ] Add calls to `phy_device_free` after `fixed_phy_unregister` to fix a memory leak that occurs when the device is unplugged. This ensures proper cleanup of pseudo fixed-link PHYs. Fixes: 89b36fb5e532 ("lan78xx: Lan7801 Support for Fixed PHY") Cc: Raghuram Chary J Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20241116130558.1352230-2-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b09512aea6223eec756f52aa584fc29eeab57480 Author: Oleksij Rempel Date: Sat Nov 16 14:05:57 2024 +0100 net: usb: lan78xx: Fix double free issue with interrupt buffer allocation [ Upstream commit 03819abbeb11117dcbba40bfe322b88c0c88a6b6 ] In lan78xx_probe(), the buffer `buf` was being freed twice: once implicitly through `usb_free_urb(dev->urb_intr)` with the `URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This caused a double free issue. To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls to simplify the initialization sequence and removed the redundant `kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuring it is correctly managed by `usb_fill_int_urb()` and freed by `usb_free_urb()` as intended. Fixes: a6df95cae40b ("lan78xx: Fix memory allocation bug") Cc: John Efstathiades Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20241116130558.1352230-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ea0feef924c1dba5f982536064f9bfda07128123 Author: ChiYuan Huang Date: Wed Sep 25 16:32:59 2024 +0800 power: supply: rt9471: Use IC status regfield to report real charger status [ Upstream commit c46a9ee5c6210682611d3d4276436c23a95e1996 ] Use IC status regfield to rewrite the 'get_staus' function. The original one cannot cover some special scenario like as charger OTG or JEITA case. Fixes: 4a1a5f6781d8 ("power: supply: rt9471: Add Richtek RT9471 charger driver") Reported-by: Lucas Tsai Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/67ba92bb4a9c51d9cafadab30b788a3a2c3048e1.1727252762.git.cy_huang@richtek.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit eb9970037870d2bca8dac76970a5280cf9f2ade5 Author: ChiYuan Huang Date: Wed Sep 25 16:32:58 2024 +0800 power: supply: rt9471: Fix wrong WDT function regfield declaration [ Upstream commit d10ff07dd2b933e3864c592ca932996b07bbf22a ] Fix F_WDT and F_WDT_RST wrong regfield declaration. Fixes: 4a1a5f6781d8 ("power: supply: rt9471: Add Richtek RT9471 charger driver") Reported-by: Lucas Tsai Signed-off-by: ChiYuan Huang Link: https://lore.kernel.org/r/f862e23f220612f01fabb6d8e76cfaf63756c22b.1727252762.git.cy_huang@richtek.com Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c17b4ffa8aac05ab5f9b5b07e670154a3263a15b Author: Barnabás Czémán Date: Wed Oct 16 20:54:05 2024 +0200 power: supply: bq27xxx: Fix registers of bq27426 [ Upstream commit 34f99d3b706a519e556841f405c224ca708b1f54 ] Correct bq27426 registers, according to technical reference manual it does not have Design Capacity register so it is not register compatible with bq27421. Fixes: 5ef6a16033b47 ("power: supply: bq27xxx: Add support for BQ27426") Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/r/20241016-fix_bq27426-v2-1-aa6c0f51a9f6@mainlining.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e5bed0f4f56a7ee9ab793f35ef538dc198cd7a8e Author: Bart Van Assche Date: Tue Sep 17 12:39:14 2024 -0700 power: supply: core: Remove might_sleep() from power_supply_put() [ Upstream commit f6da4553ff24a5d1c959c9627c965323adc3d307 ] The put_device() call in power_supply_put() may call power_supply_dev_release(). The latter function does not sleep so power_supply_put() doesn't sleep either. Hence, remove the might_sleep() call from power_supply_put(). This patch suppresses false positive complaints about calling a sleeping function from atomic context if power_supply_put() is called from atomic context. Cc: Kyle Tso Cc: Krzysztof Kozlowski Fixes: 1a352462b537 ("power_supply: Add power_supply_put for decrementing device reference counter") Signed-off-by: Bart Van Assche Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240917193914.47566-1-bvanassche@acm.org Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 3b75f627b73d96787a493e2f1187543ba9c056a4 Author: Tiezhu Yang Date: Fri Nov 22 15:47:48 2024 +0800 LoongArch: BPF: Sign-extend return values [ Upstream commit 73c359d1d356cf10236ccd358bd55edab33e9424 ] (1) Description of Problem: When testing BPF JIT with the latest compiler toolchains on LoongArch, there exist some strange failed test cases, dmesg shows something like this: # dmesg -t | grep FAIL | head -1 ... ret -3 != -3 (0xfffffffd != 0xfffffffd)FAIL ... (2) Steps to Reproduce: # echo 1 > /proc/sys/net/core/bpf_jit_enable # modprobe test_bpf (3) Additional Info: There are no failed test cases compiled with the lower version of GCC such as 13.3.0, while the problems only appear with higher version of GCC such as 14.2.0. This is because the problems were hidden by the lower version of GCC due to redundant sign extension instructions generated by compiler, but with optimization of higher version of GCC, the sign extension instructions have been removed. (4) Root Cause Analysis: The LoongArch architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format. While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86). This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in LoongArch land), passed the return value up the kernel, for example: | int from_bpf(void); | | long foo(void) | { | return from_bpf(); | } Here, a0 would be 0xffffffff instead of the expected 0xffffffffffffffff. Internally, the LoongArch JIT uses a5 as a dedicated register for BPF return values. That is to say, the LoongArch BPF uses a5 for BPF return values, which are zero-extended, whereas the LoongArch ABI uses a0 which is sign-extended. (5) Final Solution: Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Because libbpf currently defines the return value of an ebpf program as a 32-bit unsigned integer, just use addi.w to extend bit 31 into bits 63 through 32 of a5 to a0. This is similar to commit 2f1b0d3d7331 ("riscv, bpf: Sign-extend return values"). Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") Acked-by: John Fastabend Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit b5197448f3ecc534e65abcffc4622cbcffedd8dc Author: Tiezhu Yang Date: Fri Nov 22 15:47:47 2024 +0800 LoongArch: Fix build failure with GCC 15 (-std=gnu23) [ Upstream commit 947d5d036c788156f09e83e7f16322ffe8124384 ] Whenever I try to build the kernel with upcoming GCC 15 which defaults to -std=gnu23 I get a build failure: CC arch/loongarch/vdso/vgetcpu.o In file included from ./include/uapi/linux/posix_types.h:5, from ./include/uapi/linux/types.h:14, from ./include/linux/types.h:6, from ./include/linux/kasan-checks.h:5, from ./include/asm-generic/rwonce.h:26, from ./arch/loongarch/include/generated/asm/rwonce.h:1, from ./include/linux/compiler.h:317, from ./include/asm-generic/bug.h:5, from ./arch/loongarch/include/asm/bug.h:60, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:6, from ./arch/loongarch/include/asm/vdso.h:10, from arch/loongarch/vdso/vgetcpu.c:6: ./include/linux/stddef.h:11:9: error: expected identifier before 'false' 11 | false = 0, | ^~~~~ ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers 35 | typedef _Bool bool; | ^~~~ ./include/linux/types.h:35:1: warning: useless type name in empty declaration 35 | typedef _Bool bool; | ^~~~~~~ The kernel builds explicitly with -std=gnu11 in top Makefile, but arch/loongarch/vdso does not use KBUILD_CFLAGS from the rest of the kernel, just add -std=gnu11 flag to arch/loongarch/vdso/Makefile. By the way, commit e8c07082a810 ("Kbuild: move to -std=gnu11") did a similar change for arch/arm64/kernel/vdso32/Makefile. Fixes: c6b99bed6b8f ("LoongArch: Add VDSO and VSYSCALL support") Signed-off-by: Tiezhu Yang Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 14954bf33657a060fea5a40bcab50f67e004b7f0 Author: Randy Dunlap Date: Mon Nov 25 13:50:21 2024 -0800 fs_parser: update mount_api doc to match function signature [ Upstream commit c66f759832a83cb273ba5a55c66dcc99384efa74 ] Add the missing 'name' parameter to the mount_api documentation for fs_validate_description(). Fixes: 96cafb9ccb15 ("fs_parser: remove fs_parameter_description name field") Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20241125215021.231758-1-rdunlap@infradead.org Cc: Eric Sandeen Cc: David Howells Cc: Al Viro Cc: Christian Brauner Cc: Jan Kara Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 949bee8065a85a5c6607c624dc05b5bc17119699 Author: Avihai Horon Date: Sun Nov 24 16:27:39 2024 +0200 vfio/pci: Properly hide first-in-list PCIe extended capability [ Upstream commit fe4bf8d0b6716a423b16495d55b35d3fe515905d ] There are cases where a PCIe extended capability should be hidden from the user. For example, an unknown capability (i.e., capability with ID greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally chosen to be hidden from the user. Hiding a capability is done by virtualizing and modifying the 'Next Capability Offset' field of the previous capability so it points to the capability after the one that should be hidden. The special case where the first capability in the list should be hidden is handled differently because there is no previous capability that can be modified. In this case, the capability ID and version are zeroed while leaving the next pointer intact. This hides the capability and leaves an anchor for the rest of the capability list. However, today, hiding the first capability in the list is not done properly if the capability is unknown, as struct vfio_pci_core_device->pci_config_map is set to the capability ID during initialization but the capability ID is not properly checked later when used in vfio_config_do_rw(). This leads to the following warning [1] and to an out-of-bounds access to ecap_perms array. Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct read only access instead of the ecap_perms array. Note that this is safe since the above is the only case where cap_id can exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which are already checked before). [1] WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1 (snip) Call Trace: ? show_regs+0x69/0x80 ? __warn+0x8d/0x140 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? report_bug+0x18f/0x1a0 ? handle_bug+0x63/0xa0 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core] ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core] vfio_pci_rw+0x101/0x1b0 [vfio_pci_core] vfio_pci_core_read+0x1d/0x30 [vfio_pci_core] vfio_device_fops_read+0x27/0x40 [vfio] vfs_read+0xbd/0x340 ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio] ? __rseq_handle_notify_resume+0xa4/0x4b0 __x64_sys_pread64+0x96/0xc0 x64_sys_call+0x1c3d/0x20d0 do_syscall_64+0x4d/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Signed-off-by: Avihai Horon Reviewed-by: Yi Liu Tested-by: Yi Liu Link: https://lore.kernel.org/r/20241124142739.21698-1-avihaih@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 74a730137c9cc01dd9552a11f36ff57dd259cfc3 Author: Andy Shevchenko Date: Mon Nov 18 11:27:07 2024 +0200 gpio: zevio: Add missed label initialisation [ Upstream commit 5bbed54ba66925ebca19092d0750630f943d7bf2 ] Initialise the GPIO chip label correctly as it was done by of_mm_gpiochip_add_data() before the below mentioned change. Fixes: cf8f4462e5fa ("gpio: zevio: drop of_gpio.h header") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241118092729.516736-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 0a4720b7c4f8826a7a5421cefa6d25635a8fa88f Author: Michael Ellerman Date: Sat Nov 16 00:41:14 2024 +1100 selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels [ Upstream commit f13242a46438e690067a4bf47068fde4d5719947 ] Currently the mount_setattr_test fails on machines with a 64K PAGE_SIZE, with errors such as: # RUN mount_setattr_idmapped.invalid_fd_negative ... mkfs.ext4: No space left on device while writing out and closing file system # mount_setattr_test.c:1055:invalid_fd_negative:Expected system("mkfs.ext4 -q /mnt/C/ext4.img") (256) == 0 (0) # invalid_fd_negative: Test terminated by assertion # FAIL mount_setattr_idmapped.invalid_fd_negative not ok 12 mount_setattr_idmapped.invalid_fd_negative The code creates a 100,000 byte tmpfs: ASSERT_EQ(mount("testing", "/mnt", "tmpfs", MS_NOATIME | MS_NODEV, "size=100000,mode=700"), 0); And then a little later creates a 2MB ext4 filesystem in that tmpfs: ASSERT_EQ(ftruncate(img_fd, 1024 * 2048), 0); ASSERT_EQ(system("mkfs.ext4 -q /mnt/C/ext4.img"), 0); At first glance it seems like that should never work, after all 2MB is larger than 100,000 bytes. However the filesystem image doesn't actually occupy 2MB on "disk" (actually RAM, due to tmpfs). On 4K kernels the ext4.img uses ~84KB of actual space (according to du), which just fits. However on 64K PAGE_SIZE kernels the ext4.img takes at least 256KB, which is too large to fit in the tmpfs, hence the errors. It seems fraught to rely on the ext4.img taking less space on disk than the allocated size, so instead create the tmpfs with a size of 2MB. With that all 21 tests pass on 64K PAGE_SIZE kernels. Fixes: 01eadc8dd96d ("tests: add mount_setattr() selftests") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20241115134114.1219555-1-mpe@ellerman.id.au Reviewed-by: Ritesh Harjani (IBM) Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 04113ad60fcb674e640d766461c65c70ec55e396 Author: Yishai Hadas Date: Thu Nov 14 11:53:18 2024 +0200 vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data() [ Upstream commit cb04444c243c001fc27f275e84792ff1c2b96867 ] Fix unwind flows in mlx5vf_pci_save_device_data() and mlx5vf_pci_resume_device_data() to avoid freeing the migf pointer at the 'end' label, as this will be handled by fput(migf->filp) through mlx5vf_release_file(). To ensure mlx5vf_release_file() functions correctly, move the initialization of migf fields (such as migf->lock) to occur before any potential unwind flow, as these fields may be accessed within mlx5vf_release_file(). Fixes: 9945a67ea4b3 ("vfio/mlx5: Refactor PD usage") Signed-off-by: Yishai Hadas Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20241114095318.16556-3-yishaih@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 769fe4ce444b646b0bf6ac308de80686c730c7df Author: Yishai Hadas Date: Thu Nov 14 11:53:17 2024 +0200 vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() [ Upstream commit 22e87bf3f77c18f5982c19ffe2732ef0c7a25f16 ] Fix an unwind issue in mlx5vf_add_migration_pages(). If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak. Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer(). Fixes: 6fadb021266d ("vfio/mlx5: Implement vfio_pci driver for mlx5 devices") Signed-off-by: Yishai Hadas Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20241114095318.16556-2-yishaih@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit c223e12397f56b6f57189be0afaba4590a90bfb6 Author: Si-Wei Liu Date: Mon Oct 21 16:40:40 2024 +0300 vdpa/mlx5: Fix suboptimal range on iotlb iteration [ Upstream commit 35025963326e44d8bced3eecd42d2f040f4f0024 ] The starting iova address to iterate iotlb map entry within a range was set to an irrelevant value when passing to the itree_next() iterator, although luckily it doesn't affect the outcome of finding out the granule of the smallest iotlb map size. Fix the code to make it consistent with the following for-loop. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Signed-off-by: Si-Wei Liu Signed-off-by: Dragos Tatulea Message-Id: <20241021134040.975221-3-dtatulea@nvidia.com> Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit c09cc46b17aa39b3d7b5b345b220be38338f1815 Author: Lorenzo Bianconi Date: Wed Sep 18 15:32:55 2024 +0200 phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions [ Upstream commit e56272f2bb8314eb13b0eb0a4e8055831c700255 ] Fix the following register definitions for REG_CSR_2L_RX{0,1}_REV0 registers: - CSR_2L_PXP_VOS_PNINV - CSR_2L_PXP_FE_GAIN_NORMAL_MODE - CSR_2L_PXP_FE_GAIN_TRAIN_MODE Fixes: d7d2818b9383 ("phy: airoha: Add PCIe PHY driver for EN7581 SoC.") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20240918-airoha-en7581-phy-fixes-v1-4-8291729a87f8@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d9f09a7dc7bc9839e3164b85f5ced34992d6b47b Author: Lorenzo Bianconi Date: Wed Sep 18 15:32:54 2024 +0200 phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in airoha_pcie_phy_init_ssc_jcpll() [ Upstream commit 6fd016c965d241673a2e62afbf9eeb4bcbfbbe45 ] Fix typo configuring REG_CSR_2L_JCPLL_SDM_HREN register in airoha_pcie_phy_init_ssc_jcpll routine. Fixes: d7d2818b9383 ("phy: airoha: Add PCIe PHY driver for EN7581 SoC.") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20240918-airoha-en7581-phy-fixes-v1-3-8291729a87f8@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit a96c5c0328296609bbfed169f860ac62bf698816 Author: Lorenzo Bianconi Date: Wed Sep 18 15:32:53 2024 +0200 phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in airoha_pcie_phy_init_csr_2l() [ Upstream commit f9c5d6369d3e8e36b7beb15e86b1ef0911ace85f ] Fix typos configuring REG_PCIE_PMA_TX_RESET register in airoha_pcie_phy_init_csr_2l routine for lane0 and lane1 Fixes: d7d2818b9383 ("phy: airoha: Add PCIe PHY driver for EN7581 SoC.") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20240918-airoha-en7581-phy-fixes-v1-2-8291729a87f8@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 155f272cecd8e5639c01672138a610f7c53453f4 Author: Lorenzo Bianconi Date: Wed Sep 18 15:32:52 2024 +0200 phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in airoha_pcie_phy_init_clk_out() [ Upstream commit 09a19fb75498985cbb598f1fa43a7d2416925c30 ] Fix typo configuring REG_CSR_2L_PLL_CMN_RESERVE0 register in airoha_pcie_phy_init_clk_out routine. Fixes: d7d2818b9383 ("phy: airoha: Add PCIe PHY driver for EN7581 SoC.") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20240918-airoha-en7581-phy-fixes-v1-1-8291729a87f8@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 16887f0e11a0ed2e18ab3a32669aa0f71aafe782 Author: Aleksa Savic Date: Sun Nov 24 16:27:24 2024 +0100 hwmon: (aquacomputer_d5next) Fix length of speed_input array [ Upstream commit 998b5a78a9ce1cc4378e7281e4ea310e37596170 ] Commit 120584c728a6 ("hwmon: (aquacomputer_d5next) Add support for Octo flow sensor") added support for reading Octo flow sensor, but didn't update the priv->speed_input array length. Since Octo has 8 fans, with the addition of the flow sensor the proper length for speed_input is 9. Reported by Arne Schwabe on Github [1], who received a UBSAN warning. Fixes: 120584c728a6 ("hwmon: (aquacomputer_d5next) Add support for Octo flow sensor") Closes: https://github.com/aleksamagicka/aquacomputer_d5next-hwmon/issues/100 [1] Reported-by: Arne Schwabe Signed-off-by: Aleksa Savic Message-ID: <20241124152725.7205-1-savicaleksa83@gmail.com> Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fa1d1e24fac5c28c81262b90d6856c2816d4f910 Author: Murad Masimov Date: Thu Nov 21 20:36:03 2024 +0300 hwmon: (tps23861) Fix reporting of negative temperatures [ Upstream commit de2bf507fabba9c0c678cf5ed54beb546f5ca29a ] Negative temperatures are reported as large positive temperatures due to missing sign extension from unsigned int to long. Cast unsigned raw register values to signed before performing the calculations to fix the problem. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: fff7b8ab2255 ("hwmon: add Texas Instruments TPS23861 driver") Signed-off-by: Murad Masimov Message-ID: <20241121173604.2021-1-m.masimov@maxima.ru> [groeck: Updated subject and description] Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit ae297718449fa09ddd4074eceb5ea645a72fe9ee Author: Chao Yu Date: Fri Nov 8 09:25:54 2024 +0800 f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow [ Upstream commit 3273d8ad947dea925a65a78ca29e5351c960c801 ] It missed to cast variable to unsigned long long type before bit shift, which will cause overflow, fix it. Fixes: f7ef9b83b583 ("f2fs: introduce macros to convert bytes and blocks in f2fs") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 07efe0b7d3bbb2608bf177696c140425fefba93f Author: Zhiguo Niu Date: Thu Aug 1 09:33:51 2024 +0800 f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS [ Upstream commit 8fb9f31984bdc0aaa1b0f7c7e7a27bd3137f8744 ] Use F2FS_BYTES_TO_BLK(bytes) and F2FS_BLK_TO_BYTES(blk) for cleanup Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Stable-dep-of: 3273d8ad947d ("f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow") Signed-off-by: Sasha Levin commit 48fd5cc01bc1d646306ce68da2fc0aff5a3b1ee2 Author: Chuck Lever Date: Thu Oct 31 09:40:03 2024 -0400 NFSD: Fix nfsd4_shutdown_copy() [ Upstream commit 62a8642ba00aa8ceb0a02ade942f5ec52e877c95 ] nfsd4_shutdown_copy() is just this: while ((copy = nfsd4_get_copy(clp)) != NULL) nfsd4_stop_copy(copy); nfsd4_get_copy() bumps @copy's reference count, preventing nfsd4_stop_copy() from releasing @copy. A while loop like this usually works by removing the first element of the list, but neither nfsd4_get_copy() nor nfsd4_stop_copy() alters the async_copies list. Best I can tell, then, is that nfsd4_shutdown_copy() continues to loop until other threads manage to remove all the items from this list. The spinning loop blocks shutdown until these items are gone. Possibly the reason we haven't seen this issue in the field is because client_has_state() prevents __destroy_client() from calling nfsd4_shutdown_copy() if there are any items on this list. In a subsequent patch I plan to remove that restriction. Fixes: e0639dc5805a ("NFSD introduce async copy feature") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ebf47215d46992caea660ec01cd618005d9e687a Author: Ye Bin Date: Thu Oct 24 09:55:20 2024 +0800 svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init() [ Upstream commit ce89e742a4c12b20f09a43fec1b21db33f2166cd ] There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the 'percpu_counters' list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL. Fixes: 1e7e55731628 ("svcrdma: Restore read and write stats") Fixes: 22df5a22462e ("svcrdma: Convert rdma_stat_sq_starve to a per-CPU counter") Fixes: df971cd853c0 ("svcrdma: Convert rdma_stat_recv to a per-CPU counter") Signed-off-by: Ye Bin Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2e4854599200f4d021df8ae17e69221d7c149f3e Author: Yang Erkun Date: Mon Oct 21 22:23:43 2024 +0800 nfsd: release svc_expkey/svc_export with rcu_work [ Upstream commit f8c989a0c89a75d30f899a7cabdc14d72522bb8d ] The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period. Fixes: 9ceddd9da134 ("knfsd: Allow lockless lookups of the exports") Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7fb32f3e47381dda25714ebf07eeedeaf581e610 Author: Chuck Lever Date: Thu Oct 17 11:03:56 2024 -0400 NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir() [ Upstream commit f64ea4af43161bb86ffc77e6aeb5bcf5c3229df0 ] It's only current caller already length-checks the string, but let's be safe. Fixes: 0964a3d3f1aa ("[PATCH] knfsd: nfsd4 reboot dirname fix") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 03178cd8f67227015debb700123987fe96275cd1 Author: Chuck Lever Date: Thu Oct 17 11:03:53 2024 -0400 NFSD: Prevent NULL dereference in nfsd4_process_cb_update() [ Upstream commit 1e02c641c3a43c88cecc08402000418e15578d38 ] @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. Fixes: dcbeaa68dbbd ("nfsd4: allow backchannel recovery") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit c8b9d6b7d62a444e0bca5b9ae28f9f2b0f52feef Author: Zhongqiu Han Date: Tue Nov 5 20:07:35 2024 +0800 PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio' [ Upstream commit 5089b3d874e9933d9842e90410d3af1520494757 ] If platform_get_resource_byname() fails and returns NULL because DT lacks an 'mmio' property for the MHI endpoint, dereferencing res->start will cause a NULL pointer access. Add a check to prevent it. Fixes: 1bf5f25324f7 ("PCI: endpoint: Add PCI Endpoint function driver for MHI bus") Link: https://lore.kernel.org/r/20241105120735.1240728-1-quic_zhonhan@quicinc.com Signed-off-by: Zhongqiu Han [kwilczynski: error message update per the review feedback] Signed-off-by: Krzysztof Wilczyński [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit beb65d1b97508161ae80c68f122165d8d13dae40 Author: Sibi Sankar Date: Mon Aug 19 13:00:20 2024 +0530 remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region [ Upstream commit 7b22b7719fc17d5979a991c918c868ab041be5c8 ] Any write access to the IMEM region when the Q6 is setting up XPU protection on it will result in a XPU violation. Fix this by ensuring IMEM writes related to the MBA post-mortem logs happen before the Q6 is brought out of reset. Fixes: 318130cc9362 ("remoteproc: qcom_q6v5_mss: Add MBA log extraction support") Signed-off-by: Sibi Sankar Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson Link: https://lore.kernel.org/r/20240819073020.3291287-1-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2db9eb98bbb18ac9e6c0c5a37659fc801592c8f5 Author: Jonathan Marek Date: Mon Oct 7 19:59:35 2024 -0400 rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length [ Upstream commit 06c59d97f63c1b8af521fa5aef8a716fb988b285 ] The name len field of the CMD_OPEN packet is only 16-bits and the upper 16-bits of "param2" are a different "prio" field, which can be nonzero in certain situations, and CMD_OPEN packets can be unexpectedly dropped because of this. Fix this by masking out the upper 16 bits of param2. Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver") Signed-off-by: Jonathan Marek Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20241007235935.6216-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit df50d2c14b6c2bb8352a49b2711c93fe4108d904 Author: Dmitry Baryshkov Date: Sun Oct 27 01:09:44 2024 +0300 remoteproc: qcom: pas: add minidump_id to SM8350 resources [ Upstream commit e8983156d54f59f57e648ecd44f01c16572da842 ] Specify minidump_id for the SM8350 DSPs. It was omitted for in the original commit e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs"). Fixes: e8b4e9a21af7 ("remoteproc: qcom: pas: Add SM8350 PAS remoteprocs") Signed-off-by: Dmitry Baryshkov Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20241027-sar2130p-adsp-v1-2-bd204e39d24e@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3587afcdf6e05259fa6556d97848e30f5a3444ae Author: Joe Hattori Date: Fri Nov 8 13:13:54 2024 +0900 remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe() [ Upstream commit fe80d3205e91e36e67f4d3d6c326793298d15766 ] Current implementation of adsp_probe() in qcom_q6v5_adsp.c and does not remove the subdevs of adsp on the error path. Fix this bug by calling qcom_remove_{ssr,sysmon,pdm,smd,glink}_subdev(), and qcom_q6v5_deinit() appropriately. Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Joe Hattori Link: https://lore.kernel.org/r/fed3df4219543d46b88bacf87990d947f3fac8d7.1731038950.git.joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3f12e325600744bbd48a25299d0876c7013057bb Author: Joe Hattori Date: Fri Nov 8 13:13:53 2024 +0900 remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe() [ Upstream commit 587b67cf62a91b10a47f41c20ed8ad71db375334 ] Current implementation of adsp_probe() in qcom_q6v5_pas.c does not remove the subdevs of adsp on the error path. Fix this bug by calling qcom_remove_{ssr,sysmon,pdm,smd,glink}_subdev(), qcom_q6v5_deinit(), and adsp_unassign_memory_region() appropriately. Fixes: 4b48921a8f74 ("remoteproc: qcom: Use common SMD edge handler") Signed-off-by: Joe Hattori Link: https://lore.kernel.org/r/a1cabc64240022a7f1d5237aa2aa6f72d8fb7052.1731038950.git.joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 59f038b6659fa9948b10e6df06c31499453eefa5 Author: Benjamin Peterson Date: Thu Nov 7 23:21:27 2024 +0000 perf trace: Avoid garbage when not printing a syscall's arguments [ Upstream commit 1302e352b26f34991b619b5d0b621b76d20a3883 ] syscall__scnprintf_args may not place anything in the output buffer (e.g., because the arguments are all zero). If that happened in trace__fprintf_sys_enter, its fprintf would receive an unitialized buffer leading to garbage output. Fix the problem by passing the (possibly zero) bounds of the argument buffer to the output fprintf. Fixes: a98392bb1e169a04 ("perf trace: Use beautifiers on syscalls:sys_enter_ handlers") Signed-off-by: Benjamin Peterson Tested-by: Arnaldo Carvalho de Melo Tested-by: Howard Chu Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241107232128.108981-2-benjamin@engflow.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d19478d25150e80c1f5b3c4304489089740a8442 Author: Benjamin Peterson Date: Thu Nov 7 23:21:26 2024 +0000 perf trace: Do not lose last events in a race [ Upstream commit 3fd7c36973a250e17a4ee305a31545a9426021f4 ] If a perf trace event selector specifies a maximum number of events to output (i.e., "/nr=N/" syntax), the event printing handler, trace__event_handler, disables the event selector after the maximum number events are printed. Furthermore, trace__event_handler checked if the event selector was disabled before doing any work. This avoided exceeding the maximum number of events to print if more events were in the buffer before the selector was disabled. However, the event selector can be disabled for reasons other than exceeding the maximum number of events. In particular, when the traced subprocess exits, the main loop disables all event selectors. This meant the last events of a traced subprocess might be lost to the printing handler's short-circuiting logic. This nondeterministic problem could be seen by running the following many times: $ perf trace -e syscalls:sys_enter_exit_group true trace__event_handler should simply check for exceeding the maximum number of events to print rather than the state of the event selector. Fixes: a9c5e6c1e9bff42c ("perf trace: Introduce per-event maximum number of events property") Signed-off-by: Benjamin Peterson Tested-by: Howard Chu Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241107232128.108981-1-benjamin@engflow.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e30d5d424c6d28bf65215adeb13a8961f857da9b Author: Howard Chu Date: Tue Oct 29 22:24:31 2024 -0700 perf trace: Fix tracing itself, creating feedback loops [ Upstream commit fe4f9b4124967ffb75d66994520831231b779550 ] There exists a pids_filtered map in augmented_raw_syscalls.bpf.c that ceases to provide functionality after the BPF skeleton migration done in: 5e6da6be3082f77b ("perf trace: Migrate BPF augmentation to use a skeleton") Before the migration, pid_filtered map works, courtesy of Arnaldo Carvalho de Melo : ⬢ [acme@toolbox perf-tools]$ git log --oneline -5 6f769c3458b6cf2d (HEAD) perf tests trace+probe_vfs_getname.sh: Accept quotes surrounding the filename 7777ac3dfe29f55d perf test trace+probe_vfs_getname.sh: Remove stray \ before / 33d9c5062113a4bd perf script python: Add stub for PMU symbol to the python binding e59fea47f83e8a9a perf symbols: Fix DSO kernel load and symbol process to correctly map DSO to its long_name, type and adjust_symbols 878460e8d0ff84a0 perf build: Remove -Wno-unused-but-set-variable from the flex flags when building with clang < 13.0.0 root@x1:/home/acme/git/perf-tools# perf trace -e /tmp/augmented_raw_syscalls.o -e write* --max-events=30 & [1] 180632 root@x1:/home/acme/git/perf-tools# 0.000 ( 0.051 ms): NetworkManager/1127 write(fd: 3, buf: 0x7ffeb508ef70, count: 8) = 8 0.115 ( 0.010 ms): NetworkManager/1127 write(fd: 3, buf: 0x7ffeb508ef70, count: 8) = 8 0.916 ( 0.068 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 246) = 246 1.699 ( 0.047 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 2.167 ( 0.041 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 2.739 ( 0.042 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 3.138 ( 0.027 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 3.477 ( 0.027 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 3.738 ( 0.023 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 3.946 ( 0.024 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 4.195 ( 0.024 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 121) = 121 4.212 ( 0.026 ms): NetworkManager/1127 write(fd: 3, buf: 0x7ffeb508ef70, count: 8) = 8 4.285 ( 0.006 ms): NetworkManager/1127 write(fd: 3, buf: 0x7ffeb508ef70, count: 8) = 8 4.445 ( 0.018 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 260) = 260 4.508 ( 0.009 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 124) = 124 4.592 ( 0.010 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 116) = 116 4.666 ( 0.009 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 130) = 130 4.715 ( 0.010 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 95) = 95 4.765 ( 0.007 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 102) = 102 4.815 ( 0.009 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 79) = 79 4.890 ( 0.008 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 57) = 57 4.937 ( 0.007 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 89) = 89 5.009 ( 0.010 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 112) = 112 5.059 ( 0.010 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 112) = 112 5.116 ( 0.007 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 79) = 79 5.152 ( 0.009 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 33) = 33 5.215 ( 0.008 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 37) = 37 5.293 ( 0.010 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 128) = 128 5.339 ( 0.009 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 89) = 89 5.384 ( 0.008 ms): sudo/156867 write(fd: 8, buf: 0x55cb4cd2f650, count: 100) = 100 [1]+ Done perf trace -e /tmp/augmented_raw_syscalls.o -e write* --max-events=30 root@x1:/home/acme/git/perf-tools# No events for the 'perf trace' (pid 180632), i.e. no feedback loop. If we leave it running: root@x1:/home/acme/git/perf-tools# perf trace -e /tmp/augmented_raw_syscalls.o -e landlock_add_rule & [1] 181068 root@x1:/home/acme/git/perf-tools# And then look at what maps it sets up: root@x1:/home/acme/git/perf-tools# bpftool map | grep pids_filtered -A3 1190: hash name pids_filtered flags 0x0 key 4B value 1B max_entries 64 memlock 7264B btf_id 1613 pids perf(181068) root@x1:/home/acme/git/perf-tools# And ask for dumping its contents: We see that we are _also_ setting it to filter those: root@x1:/home/acme/git/perf-tools# bpftool map dump id 1190 [{ "key": 181068, "value": 1 },{ "key": 156801, "value": 1 } ] Now testing the migration commit: perf $ git log commit 5e6da6be3082f77be06894a1a94d52a90b4007dc (HEAD) Author: Ian Rogers Date: Thu Aug 10 11:48:51 2023 -0700 perf trace: Migrate BPF augmentation to use a skeleton perf $ ./perf trace -e write --max-events=10 & echo #! [1] 1808653 perf $ 0.000 ( 0.010 ms): :1808671/1808671 write(fd: 1, buf: 0x6003f5b26fc0, count: 11) = 11 0.162 ( ): perf/1808653 write(fd: 2, buf: 0x7fffc2174e50, count: 11) ... 0.174 ( ): perf/1808653 write(fd: 2, buf: 0x74ce21804563, count: 1) ... 0.184 ( ): perf/1808653 write(fd: 2, buf: 0x57b936589052, count: 5) The feedback loop is there. Keep it running, look into the bpf map: perf $ bpftool map | grep pids_filtered 10675: hash name pids_filtered flags 0x0 perf $ bpftool map dump id 10675 [] The map is empty. Now, this commit: 64917f4df048a064 ("perf trace: Use heuristic when deciding if a syscall tracepoint "const char *" field is really a string") Temporarily fixed the feedback loop for perf trace -e write, that's because before using the heuristic, write is hooked to sys_enter_openat: perf $ git log commit 83a0943b1870944612a8aa0049f910826ebfd4f7 (HEAD) Author: Arnaldo Carvalho de Melo Date: Thu Aug 17 12:11:51 2023 -0300 perf trace: Use the augmented_raw_syscall BPF skel only for tracing syscalls perf $ ./perf trace -e write --max-events=10 -v 2>&1 | grep Reusing Reusing "openat" BPF sys_enter augmenter for "write" And after the heuristic fix, it's unaugmented: perf $ git log commit 64917f4df048a0649ea7901c2321f020e71e6f24 (HEAD) Author: Arnaldo Carvalho de Melo Date: Thu Aug 17 15:14:21 2023 -0300 perf trace: Use heuristic when deciding if a syscall tracepoint "const char *" field is really a string perf $ ./perf trace -e write --max-events=10 -v 2>&1 | grep Reusing perf $ After using the heuristic, write is hooked to syscall_unaugmented, which returns 1. SEC("tp/raw_syscalls/sys_enter") int syscall_unaugmented(struct syscall_enter_args *args) { return 1; } If the BPF program returns 1, the tracepoint filter will filter it (since the tracepoint filter for perf is correctly set), but before the heuristic, when it was hooked to a sys_enter_openat(), which is a BPF program that calls bpf_perf_event_output() and writes to the buffer, it didn't get filtered, thus creating feedback loop. So switching write to unaugmented accidentally fixed the problem. But some syscalls are not so lucky, for example newfstatat: perf $ ./perf trace -e newfstatat --max-events=100 & echo #! [1] 2166948 457.718 ( ): perf/2166948 newfstatat(dfd: CWD, filename: "/proc/self/ns/mnt", statbuf: 0x7fff0132a9f0) ... 457.749 ( ): perf/2166948 newfstatat(dfd: CWD, filename: "/proc/2166950/ns/mnt", statbuf: 0x7fff0132aa80) ... 457.962 ( ): perf/2166948 newfstatat(dfd: CWD, filename: "/proc/self/ns/mnt", statbuf: 0x7fff0132a9f0) ... Currently, write is augmented by the new BTF general augmenter (which calls bpf_perf_event_output()). The problem, which luckily got fixed, resurfaced, and that’s how it was discovered. Fixes: 5e6da6be3082f77b ("perf trace: Migrate BPF augmentation to use a skeleton") Signed-off-by: Howard Chu Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241030052431.2220130-1-howardchu95@gmail.com [ Check if trace->skel is non-NULL, as it is only initialized if trace->trace_syscalls is set ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit dba9863fb56153eec6d8b7be45aee51d06746085 Author: Jean-Philippe Romain Date: Fri Nov 8 18:58:01 2024 -0800 perf list: Fix topic and pmu_name argument order [ Upstream commit d99b3125726aade4f5ec4aae04805134ab4b0abd ] Fix function definitions to match header file declaration. Fix two callers to pass the arguments in the right order. On Intel Tigerlake, before: ``` $ perf list -j|grep "\"Topic\""|sort|uniq "Topic": "cache", "Topic": "cpu", "Topic": "floating point", "Topic": "frontend", "Topic": "memory", "Topic": "other", "Topic": "pfm icl", "Topic": "pfm ix86arch", "Topic": "pfm perf_raw", "Topic": "pipeline", "Topic": "tool", "Topic": "uncore interconnect", "Topic": "uncore memory", "Topic": "uncore other", "Topic": "virtual memory", $ perf list -j|grep "\"Unit\""|sort|uniq "Unit": "cache", "Unit": "cpu", "Unit": "cstate_core", "Unit": "cstate_pkg", "Unit": "i915", "Unit": "icl", "Unit": "intel_bts", "Unit": "intel_pt", "Unit": "ix86arch", "Unit": "msr", "Unit": "perf_raw", "Unit": "power", "Unit": "tool", "Unit": "uncore_arb", "Unit": "uncore_clock", "Unit": "uncore_imc_free_running_0", "Unit": "uncore_imc_free_running_1", ``` After: ``` $ perf list -j|grep "\"Topic\""|sort|uniq "Topic": "cache", "Topic": "floating point", "Topic": "frontend", "Topic": "memory", "Topic": "other", "Topic": "pfm icl", "Topic": "pfm ix86arch", "Topic": "pfm perf_raw", "Topic": "pipeline", "Topic": "tool", "Topic": "uncore interconnect", "Topic": "uncore memory", "Topic": "uncore other", "Topic": "virtual memory", $ perf list -j|grep "\"Unit\""|sort|uniq "Unit": "cpu", "Unit": "cstate_core", "Unit": "cstate_pkg", "Unit": "i915", "Unit": "icl", "Unit": "intel_bts", "Unit": "intel_pt", "Unit": "ix86arch", "Unit": "msr", "Unit": "perf_raw", "Unit": "power", "Unit": "tool", "Unit": "uncore_arb", "Unit": "uncore_clock", "Unit": "uncore_imc_free_running_0", "Unit": "uncore_imc_free_running_1", ``` Fixes: e5c6109f4813246a ("perf list: Reorganize to use callbacks to allow honouring command line options") Reviewed-by: Kan Liang Signed-off-by: Jean-Philippe Romain Tested-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Junhao He Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20241109025801.560378-1-irogers@google.com [ I fixed the two callers and added it to Jean-Phillippe's original change. ] Signed-off-by: Ian Rogers Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1a227429d8cc82367af23c0daeb3428353af5fb9 Author: Jeff Layton Date: Mon Nov 11 11:01:13 2024 -0500 nfsd: drop inode parameter from nfsd4_change_attribute() [ Upstream commit f67eef8da0e8c54709fefdecd16ad8d70f0c9d20 ] The inode that nfs4_open_delegation() passes to this function is wrong, which throws off the result. The inode will end up getting a directory-style change attr instead of a regular-file-style one. Fix up nfs4_delegation_stat() to fetch STATX_MODE, and then drop the inode parameter from nfsd4_change_attribute(), since it's no longer needed. Fixes: c5967721e106 ("NFSD: handle GETATTR conflict with write delegation") Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 4cbc3ba6dc2f746497cade60bcbaa82ae3696689 Author: Chuck Lever Date: Tue Sep 17 12:15:29 2024 -0400 svcrdma: Address an integer overflow [ Upstream commit 3c63d8946e578663b868cb9912dac616ea68bfd0 ] Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 /* A bogus segcount causes this buffer overflow check to fail. */ > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode(). Reported-by: Dan Carpenter Fixes: 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data structure") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit cad49f6a45bdbca6ac12994c6fe9a3307db7ff91 Author: Antonio Quartulli Date: Tue Oct 29 22:43:15 2024 +0100 m68k: coldfire/device.c: only build FEC when HW macros are defined [ Upstream commit 63a24cf8cc330e5a68ebd2e20ae200096974c475 ] When CONFIG_FEC is set (due to COMPILE_TEST) along with CONFIG_M54xx, coldfire/device.c has compile errors due to missing MCFEC_* and MCF_IRQ_FEC_* symbols. Make the whole FEC blocks dependent on having the HW macros defined, rather than on CONFIG_FEC itself. This fix is very similar to commit e6e1e7b19fa1 ("m68k: coldfire/device.c: only build for MCF_EDMA when h/w macros are defined") Fixes: b7ce7f0d0efc ("m68knommu: merge common ColdFire FEC platform setup code") To: Greg Ungerer To: Geert Uytterhoeven Cc: linux-m68k@lists.linux-m68k.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Antonio Quartulli Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 95dd7fe63bd00fde23f72799927ae34517669f45 Author: Jean-Michel Hautbois Date: Wed Oct 16 09:24:35 2024 +0200 m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x [ Upstream commit f212140962c93cd5da43283a18e31681540fc23d ] Fix a typo in the CONFIG_M5441x preprocessor condition, where the GPIO register offset was incorrectly set to 8 instead of 0. This prevented proper GPIO configuration for m5441x targets. Fixes: bea8bcb12da0 ("m68knommu: Add support for the Coldfire m5441x.") Signed-off-by: Jean-Michel Hautbois Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 557a91bd42a28946b404ce5cc4a1dd85f03258d5 Author: Benjamin Peterson Date: Sun Nov 3 20:48:16 2024 +0000 perf trace: avoid garbage when not printing a trace event's arguments [ Upstream commit 5fb8e56542a3cf469fdf25d77f50e21cbff3ae7e ] trace__fprintf_tp_fields may not print any tracepoint arguments. E.g., if the argument values are all zero. Previously, this would result in a totally uninitialized buffer being passed to fprintf, which could lead to garbage on the console. Fix the problem by passing the number of initialized bytes fprintf. Fixes: f11b2803bb88 ("perf trace: Allow choosing how to augment the tracepoint arguments") Signed-off-by: Benjamin Peterson Tested-by: Howard Chu Tested-by: Arnaldo Carvalho de Melo Link: https://lore.kernel.org/r/20241103204816.7834-1-benjamin@engflow.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 0df890cb2a60b95557fd27f0e0cd1591cab08698 Author: Chao Yu Date: Mon Nov 4 09:50:16 2024 +0800 f2fs: fix to avoid forcing direct write to use buffered IO on inline_data inode [ Upstream commit 26e6f59d0bbaac76fa3413462d780bd2b5f9f653 ] Jinsu Lee reported a performance regression issue, after commit 5c8764f8679e ("f2fs: fix to force buffered IO on inline_data inode"), we forced direct write to use buffered IO on inline_data inode, it will cause performace regression due to memory copy and data flush. It's fine to not force direct write to use buffered IO, as it can convert inline inode before committing direct write IO. Fixes: 5c8764f8679e ("f2fs: fix to force buffered IO on inline_data inode") Reported-by: Jinsu Lee Closes: https://lore.kernel.org/linux-f2fs-devel/af03dd2c-e361-4f80-b2fd-39440766cf6e@kernel.org Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 90a097f35f5c3e86a4e1a02f1bea9aabe5652b25 Author: Chao Yu Date: Mon Nov 4 09:35:51 2024 +0800 f2fs: fix to map blocks correctly for direct write [ Upstream commit 5dd00ebda337b9295e7027691fa70540da369ff2 ] f2fs_map_blocks() supports to map continuous holes or preallocated address, we should avoid setting F2FS_MAP_MAPPED for these cases only, otherwise, it may fail f2fs_iomap_begin(), and make direct write fallbacking to use buffered IO and flush, result in performance regression. Fixes: 9f0f6bf42714 ("f2fs: support to map continuous holes or preallocated address") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202409122103.e45aa13b-oliver.sang@intel.com Cc: Cyril Hrubis Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 60457ed6c67625c87861f96912b4179dc2293896 Author: Long Li Date: Mon Nov 4 10:05:42 2024 +0800 f2fs: fix race in concurrent f2fs_stop_gc_thread [ Upstream commit 7b0033dbc48340a1c1c3f12448ba17d6587ca092 ] In my test case, concurrent calls to f2fs shutdown report the following stack trace: Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths: [CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAF The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions. Fix it by converting to write lock of s_umount in f2fs_do_shutdown(). Fixes: 7950e9ac638e ("f2fs: stop gc/discard thread after fs shutdown") Signed-off-by: Long Li Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0df0e939d5e7580ab45b8301786a0e9d44ce2b28 Author: Yicong Yang Date: Thu Oct 24 21:32:36 2024 +0800 perf build: Add missing cflags when building with custom libtraceevent [ Upstream commit d5a0a4ab4af4c27de097b78d6f1b7e7f7e31908f ] When building with custom libtraceevent, below errors occur: $ make -C tools/perf NO_LIBPYTHON=1 PKG_CONFIG_PATH= In file included from util/session.h:5, from builtin-buildid-list.c:17: util/trace-event.h:153:10: fatal error: traceevent/event-parse.h: No such file or directory 153 | #include | ^~~~~~~~~~~~~~~~~~~~~~~~~~ This is because the include path is missed in the cflags. Add it. Fixes: 0f0e1f445690 ("perf build: Use pkg-config for feature check for libtrace{event,fs}") Signed-off-by: Yicong Yang Reviewed-by: Leo Yan Reviewed-by: Guilherme Amadio Cc: linuxarm@huawei.com Link: https://lore.kernel.org/r/20241024133236.31016-1-yangyicong@huawei.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 1b790cd35929663f41171fe0ef70aba6a002fd76 Author: Siddharth Vadapalli Date: Mon Nov 4 13:14:20 2024 +0530 PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds [ Upstream commit 22a9120479a40a56c13c5e473a0100fad2e017c0 ] According to Section 2.2 of the PCI Express Card Electromechanical Specification (Revision 5.1), in order to ensure that the power and the reference clock are stable, PERST# has to be deasserted after a delay of 100 milliseconds (TPVPERL). Currently, it is being assumed that the power is already stable, which is not necessarily true. Hence, change the delay to PCIE_T_PVPERL_MS to guarantee that power and reference clock are stable. Fixes: f3e25911a430 ("PCI: j721e: Add TI J721E PCIe driver") Fixes: f96b69713733 ("PCI: j721e: Use T_PERST_CLK_US macro") Link: https://lore.kernel.org/r/20241104074420.1862932-1-s-vadapalli@ti.com Signed-off-by: Siddharth Vadapalli Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 47f82c6925fcd9b5402912c98b4fa22b9bd481b6 Author: Théo Lebrun Date: Wed Jun 19 12:15:15 2024 +0200 PCI: j721e: Add suspend and resume support [ Upstream commit c538d40f365b5b6d7433d371710f58e8b266fb19 ] Add suspend and resume support. Only the Root Complex mode is supported. During the suspend stage PERST# is asserted, then deasserted during the resume stage. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-7-a2f9156da6c3@bootlin.com Signed-off-by: Théo Lebrun Signed-off-by: Thomas Richard [kwilczynski: commit log, update references to the PCI SIG specification] Signed-off-by: Krzysztof Wilczyński Reviewed-by: Siddharth Vadapalli Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit ebd19cb3488c8259a0d032977483f78ad3477aac Author: Thomas Richard Date: Wed Jun 19 12:15:14 2024 +0200 PCI: j721e: Use T_PERST_CLK_US macro [ Upstream commit f96b6971373382855bc964f1c067bd6dc41cf0ab ] Use the T_PERST_CLK_US macro, and the fsleep() function instead of usleep_range(). Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-6-a2f9156da6c3@bootlin.com Signed-off-by: Thomas Richard Signed-off-by: Krzysztof Wilczyński Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit 5da1c5ef41e05561d5baac934cc1d0397e6504f5 Author: Théo Lebrun Date: Wed Jun 19 12:15:12 2024 +0200 PCI: j721e: Add reset GPIO to struct j721e_pcie [ Upstream commit b8600b8791cb2b7c8be894846b1ecddba7291680 ] Add reset GPIO to struct j721e_pcie, so it can be used at suspend and resume stages. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-4-a2f9156da6c3@bootlin.com Signed-off-by: Théo Lebrun Signed-off-by: Thomas Richard Signed-off-by: Krzysztof Wilczyński Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit 985516106428242139fa010f613c6c572a0e5745 Author: Thomas Richard Date: Wed Jun 19 12:15:10 2024 +0200 PCI: cadence: Set cdns_pcie_host_init() global [ Upstream commit 063c938928dc80c2bfd66f34df48344db22e009b ] During the resume sequence of the host, cdns_pcie_host_init() needs to be called, so set it global. The dev function parameter is removed, as it isn't used. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-2-a2f9156da6c3@bootlin.com Signed-off-by: Thomas Richard Signed-off-by: Krzysztof Wilczyński Reviewed-by: Siddharth Vadapalli Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit e7f2f2e259f8ea5cda99854efe907ec69cd263f1 Author: Thomas Richard Date: Wed Jun 19 12:15:09 2024 +0200 PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup() [ Upstream commit d1b6f2e2ce4d8b17d9f3558c98a1517b864bfd03 ] The function cdns_pcie_host_setup() mixes probe structure and link setup. The link setup must be done during the resume sequence. So extract it from cdns_pcie_host_setup() and create a dedicated function. Link: https://lore.kernel.org/linux-pci/20240102-j7200-pcie-s2r-v7-1-a2f9156da6c3@bootlin.com Signed-off-by: Thomas Richard Signed-off-by: Krzysztof Wilczyński Reviewed-by: Siddharth Vadapalli Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit 70212c2300971506e986d95000d2745529cac9d7 Author: Manivannan Sadhasivam Date: Sat Aug 17 11:09:04 2024 +0530 PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert() [ Upstream commit 40e2125381dc11379112485e3eefdd25c6df5375 ] Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the tegra194 endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup functions can cause the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. But that is not always possible as some of the endpoint designs do require the endpoint to consume refclk from the host. Thus, fix this crash by moving the controller cleanups to the start of the pex_ep_event_pex_rst_deassert() function. This function is called whenever the host has deasserted PERST# and it is guaranteed that the refclk would be active at this point. So at the start of this function (after enabling resources) the controller cleanup can be performed. Once finished, rest of the code execution for PERST# deassert can continue as usual. Fixes: 473b2cf9c4d1 ("PCI: endpoint: Introduce 'epc_deinit' event and notify the EPF drivers") Fixes: 570d7715eed8 ("PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST#") Link: https://lore.kernel.org/r/20240817-pci-qcom-ep-cleanup-v1-2-d6b958226559@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Cc: Jonathan Hunter Cc: Thierry Reding Cc: Vidya Sagar Cc: linux-tegra@vger.kernel.org Signed-off-by: Sasha Levin commit e03b5f1615c84f4139cb53ef8659f4cdb8d6a563 Author: Manivannan Sadhasivam Date: Sat Aug 17 11:09:03 2024 +0530 PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert() [ Upstream commit 7d7cf89b119af433354f865fc01017b9f8aa411a ] Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF deinit notify function pci_epc_deinit_notify() are called during the execution of qcom_pcie_perst_assert() i.e., when the host has asserted PERST#. But quickly after this step, refclk will also be disabled by the host. All of the Qcom endpoint SoCs supported as of now depend on the refclk from the host for keeping the controller operational. Due to this limitation, any access to the hardware registers in the absence of refclk will result in a whole endpoint crash. Unfortunately, most of the controller cleanups require accessing the hardware registers (like eDMA cleanup performed in dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup functions are currently causing the crash in the endpoint SoC once host asserts PERST#. One way to address this issue is by generating the refclk in the endpoint itself and not depending on the host. But that is not always possible as some of the endpoint designs do require the endpoint to consume refclk from the host (as I was told by the Qcom engineers). Thus, fix this crash by moving the controller cleanups to the start of the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is called whenever the host has deasserted PERST# and it is guaranteed that the refclk would be active at this point. So at the start of this function (after enabling resources), the controller cleanup can be performed. Once finished, rest of the code execution for PERST# deassert can continue as usual. Fixes: 473b2cf9c4d1 ("PCI: endpoint: Introduce 'epc_deinit' event and notify the EPF drivers") Fixes: 570d7715eed8 ("PCI: dwc: ep: Introduce dw_pcie_ep_cleanup() API for drivers supporting PERST#") Link: https://lore.kernel.org/r/20240817-pci-qcom-ep-cleanup-v1-1-d6b958226559@linaro.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 98ce98d4d5e9b82fafbcf3634e1f832b02955229 Author: Zhiguo Niu Date: Tue Oct 29 11:12:49 2024 +0800 f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or GC_URGENT_MID [ Upstream commit 296b8cb34e65fa93382cf919be5a056f719c9a26 ] If gc_mode is set to GC_URGENT_LOW or GC_URGENT_MID, cost benefit GC approach should be used, but if ATGC is enabled at the same time, Age-threshold approach will be selected, which can only do amount of GC and it is much less than the numbers of CB approach. some traces: f2fs_gc-254:48-396 [007] ..... 2311600.684028: f2fs_gc_begin: dev = (254,48), gc_type = Background GC, no_background_GC = 0, nr_free_secs = 0, nodes = 1053, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0 f2fs_gc-254:48-396 [007] ..... 2311600.684527: f2fs_get_victim: dev = (254,48), type = No TYPE, policy = (Background GC, LFS-mode, Age-threshold), victim = 10, cost = 4294364975, ofs_unit = 1, pre_victim_secno = -1, prefree = 0, free = 44898 f2fs_gc-254:48-396 [007] ..... 2311600.714835: f2fs_gc_end: dev = (254,48), ret = 0, seg_freed = 0, sec_freed = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0 f2fs_gc-254:48-396 [007] ..... 2311600.714843: f2fs_background_gc: dev = (254,48), wait_ms = 50, prefree = 0, free = 44898 f2fs_gc-254:48-396 [007] ..... 2311600.771785: f2fs_gc_begin: dev = (254,48), gc_type = Background GC, no_background_GC = 0, nr_free_secs = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg: f2fs_gc-254:48-396 [007] ..... 2311600.772275: f2fs_gc_end: dev = (254,48), ret = -61, seg_freed = 0, sec_freed = 0, nodes = 1562, dents = 2, imeta = 18, free_sec:44898, free_seg:44898, rsv_seg:239, prefree_seg:0 Fixes: 0e5e81114de1 ("f2fs: add GC_URGENT_LOW mode in gc_urgent") Fixes: d98af5f45520 ("f2fs: introduce gc_urgent_mid mode") Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1539a088b108996bcdaddb7775070b5163b14233 Author: Chao Yu Date: Tue Oct 22 16:36:23 2024 +0800 f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason() [ Upstream commit f10a890308a7cd8794e21f646f09827c6cb4bf5d ] syzbot reports deadlock issue of f2fs as below: ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc3-syzkaller-00087-gc964ced77262 #0 Not tainted ------------------------------------------------------ kswapd0/79 is trying to acquire lock: ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] ffff888011824088 (&sbi->sb_lock){++++}-{3:3}, at: f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068 but task is already holding lock: ffff88804bd92610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (sb_internal#2){.+.+}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 percpu_down_read include/linux/percpu-rwsem.h:51 [inline] __sb_start_write include/linux/fs.h:1716 [inline] sb_start_intwrite+0x4d/0x1c0 include/linux/fs.h:1899 f2fs_evict_inode+0x662/0x15c0 fs/f2fs/inode.c:842 evict+0x4e8/0x9b0 fs/inode.c:725 f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807 evict+0x4e8/0x9b0 fs/inode.c:725 dispose_list fs/inode.c:774 [inline] prune_icache_sb+0x239/0x2f0 fs/inode.c:963 super_cache_scan+0x38c/0x4b0 fs/super.c:223 do_shrink_slab+0x701/0x1160 mm/shrinker.c:435 shrink_slab+0x1093/0x14d0 mm/shrinker.c:662 shrink_one+0x43b/0x850 mm/vmscan.c:4818 shrink_many mm/vmscan.c:4879 [inline] lru_gen_shrink_node mm/vmscan.c:4957 [inline] shrink_node+0x3799/0x3de0 mm/vmscan.c:5937 kswapd_shrink_node mm/vmscan.c:6765 [inline] balance_pgdat mm/vmscan.c:6957 [inline] kswapd+0x1ca3/0x3700 mm/vmscan.c:7226 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #1 (fs_reclaim){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __fs_reclaim_acquire mm/page_alloc.c:3834 [inline] fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3848 might_alloc include/linux/sched/mm.h:318 [inline] prepare_alloc_pages+0x147/0x5b0 mm/page_alloc.c:4493 __alloc_pages_noprof+0x16f/0x710 mm/page_alloc.c:4722 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 alloc_pages_noprof mm/mempolicy.c:2345 [inline] folio_alloc_noprof+0x128/0x180 mm/mempolicy.c:2352 filemap_alloc_folio_noprof+0xdf/0x500 mm/filemap.c:1010 do_read_cache_folio+0x2eb/0x850 mm/filemap.c:3787 read_mapping_folio include/linux/pagemap.h:1011 [inline] f2fs_commit_super+0x3c0/0x7d0 fs/f2fs/super.c:4032 f2fs_record_stop_reason+0x13b/0x1d0 fs/f2fs/super.c:4079 f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174 f2fs_write_inode+0x35f/0x4d0 fs/f2fs/inode.c:785 write_inode fs/fs-writeback.c:1503 [inline] __writeback_single_inode+0x711/0x10d0 fs/fs-writeback.c:1723 writeback_single_inode+0x1f3/0x660 fs/fs-writeback.c:1779 sync_inode_metadata+0xc4/0x120 fs/fs-writeback.c:2849 f2fs_release_file+0xa8/0x100 fs/f2fs/file.c:1941 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:228 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop kernel/entry/common.c:114 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&sbi->sb_lock){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 down_write+0x99/0x220 kernel/locking/rwsem.c:1577 f2fs_down_write fs/f2fs/f2fs.h:2199 [inline] f2fs_record_stop_reason+0x52/0x1d0 fs/f2fs/super.c:4068 f2fs_handle_critical_error+0x2ac/0x5c0 fs/f2fs/super.c:4174 f2fs_evict_inode+0xa61/0x15c0 fs/f2fs/inode.c:883 evict+0x4e8/0x9b0 fs/inode.c:725 f2fs_evict_inode+0x1a4/0x15c0 fs/f2fs/inode.c:807 evict+0x4e8/0x9b0 fs/inode.c:725 dispose_list fs/inode.c:774 [inline] prune_icache_sb+0x239/0x2f0 fs/inode.c:963 super_cache_scan+0x38c/0x4b0 fs/super.c:223 do_shrink_slab+0x701/0x1160 mm/shrinker.c:435 shrink_slab+0x1093/0x14d0 mm/shrinker.c:662 shrink_one+0x43b/0x850 mm/vmscan.c:4818 shrink_many mm/vmscan.c:4879 [inline] lru_gen_shrink_node mm/vmscan.c:4957 [inline] shrink_node+0x3799/0x3de0 mm/vmscan.c:5937 kswapd_shrink_node mm/vmscan.c:6765 [inline] balance_pgdat mm/vmscan.c:6957 [inline] kswapd+0x1ca3/0x3700 mm/vmscan.c:7226 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 other info that might help us debug this: Chain exists of: &sbi->sb_lock --> fs_reclaim --> sb_internal#2 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(sb_internal#2); lock(fs_reclaim); lock(sb_internal#2); lock(&sbi->sb_lock); Root cause is there will be potential deadlock in between below tasks: Thread A Kswapd - f2fs_ioc_commit_atomic_write - mnt_want_write_file -- down_read lock A - balance_pgdat - __fs_reclaim_acquire -- lock B - shrink_node - prune_icache_sb - dispose_list - f2fs_evict_inode - sb_start_intwrite -- down_read lock A - f2fs_do_sync_file - f2fs_write_inode - f2fs_handle_critical_error - f2fs_record_stop_reason - f2fs_commit_super - read_mapping_folio - filemap_alloc_folio_noprof - fs_reclaim_acquire -- lock B Both threads try to acquire read lock of lock A, then its upcoming write lock grabber will trigger deadlock. Let's always create an asynchronous task in f2fs_handle_critical_error() rather than calling f2fs_record_stop_reason() synchronously to avoid this potential deadlock issue. Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption") Reported-by: syzbot+be4a9983e95a5e25c8d3@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/6704d667.050a0220.1e4d62.0081.GAE@google.com Signed-off-by: Chao Yu Reviewed-by: Daejun Park Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9075aeef6a269322ac3632cf4f97cef3cef158dd Author: Zeng Heng Date: Wed Oct 23 17:48:50 2024 +0800 f2fs: Fix not used variable 'index' [ Upstream commit 0c3a38a4b442893f8baca72e44a2a27d52d6cc75 ] Fix the following compilation warning: fs/f2fs/data.c:2391:10: warning: variable ‘index’ set but not used [-Wunused-but-set-variable] 2391 | pgoff_t index; Only define and set the variable index when the CONFIG_F2FS_FS_COMPRESSION is enabled. Fixes: db92e6c729d8 ("f2fs: convert f2fs_mpage_readpages() to use folio") Signed-off-by: Zeng Heng Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 464b84626313610b38e3d7bd2a8a98b4f64aba00 Author: Yongpeng Yang Date: Mon Oct 21 12:48:01 2024 +0800 f2fs: check curseg->inited before write_sum_page in change_curseg [ Upstream commit 43563069e1c1df417d2eed6eca8a22fc6b04691d ] In the __f2fs_init_atgc_curseg->get_atssr_segment calling, curseg->segno is NULL_SEGNO, indicating that there is no summary block that needs to be written. Fixes: 093749e296e2 ("f2fs: support age threshold based garbage collection") Signed-off-by: Yongpeng Yang Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fcd83b9adf17dad2b7074ed0c1a0051d66da4e18 Author: LongPing Wei Date: Mon Oct 21 10:31:47 2024 +0800 f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block [ Upstream commit c3af1f13476ec23fd99c98d060a89be28c1e8871 ] This f2fs_bug_on was introduced by commit 2c1905042c8c ("f2fs: check segment type in __f2fs_replace_block") when there were only 6 curseg types. After commit d0b9e42ab615 ("f2fs: introduce inmem curseg") was introduced, the condition should be changed to checking curseg->seg_type. Fixes: d0b9e42ab615 ("f2fs: introduce inmem curseg") Signed-off-by: LongPing Wei Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4e4cdb109fe6ea89687d9a75a9ab8106f84d5fb3 Author: Frank Li Date: Tue Oct 1 12:22:32 2024 -0400 i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin [ Upstream commit 36faa04ce3d9c962b4b29d285ad07ca29e2988e4 ] When a new device hotjoins, a new dynamic address is assigned. i3c_master_add_i3c_dev_locked() identifies that the device was previously attached to the bus and locates the olddev. i3c_master_add_i3c_dev_locked() { ... olddev = i3c_master_search_i3c_dev_duplicate(newdev); ... if (olddev) { ... i3c_dev_disable_ibi_locked(olddev); ^^^^^^ The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So remove it. } i3c_dev_free_ibi_locked(olddev); ^^^^^^^^ This function internally calls i3c_dev_disable_ibi_locked() function causing to send DISEC command with old Address. The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So, update the olddev->ibi->enabled flag to false to avoid DISEC with OldAddr. } Include part of Ravindra Yashvant Shinde's work: https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry") Co-developed-by: Ravindra Yashvant Shinde Signed-off-by: Ravindra Yashvant Shinde Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 9d1a84063ab61e6efb25fae51367955dd4de0ada Author: Arnaldo Carvalho de Melo Date: Tue Oct 29 16:29:02 2024 -0300 perf ftrace latency: Fix unit on histogram first entry when using --use-nsec [ Upstream commit 064d569e20e82c065b1dec9d20c29c7087bb1a00 ] The use_nsec arg wasn't being taken into account when printing the first histogram entry, fix it: root@number:~# perf ftrace latency --use-nsec -T switch_mm_irqs_off -a sleep 2 # DURATION | COUNT | GRAPH | 0 - 1 us | 0 | | 1 - 2 ns | 0 | | 2 - 4 ns | 0 | | 4 - 8 ns | 0 | | 8 - 16 ns | 0 | | 16 - 32 ns | 0 | | 32 - 64 ns | 125 | | 64 - 128 ns | 335 | | 128 - 256 ns | 2155 | #### | 256 - 512 ns | 9996 | ################### | 512 - 1024 ns | 4958 | ######### | 1 - 2 us | 4636 | ######### | 2 - 4 us | 1053 | ## | 4 - 8 us | 15 | | 8 - 16 us | 1 | | 16 - 32 us | 0 | | 32 - 64 us | 0 | | 64 - 128 us | 0 | | 128 - 256 us | 0 | | 256 - 512 us | 0 | | 512 - 1024 us | 0 | | 1 - ... ms | 0 | | root@number:~# After: root@number:~# perf ftrace latency --use-nsec -T switch_mm_irqs_off -a sleep 2 # DURATION | COUNT | GRAPH | 0 - 1 ns | 0 | | 1 - 2 ns | 0 | | 2 - 4 ns | 0 | | 4 - 8 ns | 0 | | 8 - 16 ns | 0 | | 16 - 32 ns | 0 | | 32 - 64 ns | 19 | | 64 - 128 ns | 94 | | 128 - 256 ns | 2191 | #### | 256 - 512 ns | 9719 | #################### | 512 - 1024 ns | 5330 | ########### | 1 - 2 us | 4104 | ######## | 2 - 4 us | 807 | # | 4 - 8 us | 9 | | 8 - 16 us | 0 | | 16 - 32 us | 0 | | 32 - 64 us | 0 | | 64 - 128 us | 0 | | 128 - 256 us | 0 | | 256 - 512 us | 0 | | 512 - 1024 us | 0 | | 1 - ... ms | 0 | | root@number:~# Fixes: 84005bb6148618cc ("perf ftrace latency: Add -n/--use-nsec option") Signed-off-by: Arnaldo Carvalho de Melo Cc: Gabriele Monaco Link: https://lore.kernel.org/r/ZyE3frB-hMXHCnMO@x1 Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9a8fde56d4b6d51930936ed50f6370a9097328d1 Author: Hou Tao Date: Sat Aug 31 17:37:49 2024 +0800 virtiofs: use pages instead of pointer for kernel direct IO [ Upstream commit 41748675c0bf252b3c5f600a95830f0936d366c1 ] When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first. 2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter(). 3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever. A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel. So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data. After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations. It may seem necessary to introduce another field in fuse_conn to indicate that these KVEC_IO pages are used for DMA, However, considering that virtio-fs is currently the only user of use_pages_for_kvec_io, just reuse use_pages_for_kvec_io to indicate that these pages will be used for DMA. Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem") Signed-off-by: Hou Tao Tested-by: Jingbo Xu Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 8601f214db8c3436932f976ddb7d2cfa0857ecd4 Author: Li Huafei Date: Sat Oct 19 23:41:55 2024 +0800 perf disasm: Use disasm_line__free() to properly free disasm_line [ Upstream commit b4e0e9a1e30059f4523c9b6a1f8045ad89b5db8a ] The structure disasm_line contains members that require dynamically allocated memory and need to be freed correctly using disasm_line__free(). This patch fixes the incorrect release in symbol__disassemble_capstone(). Fixes: 6d17edc113de ("perf annotate: Use libcapstone to disassemble") Signed-off-by: Li Huafei Tested-by: Athira Rajeev Cc: sesse@google.com Cc: kjain@linux.ibm.com Link: https://lore.kernel.org/r/20241019154157.282038-1-lihuafei1@huawei.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit d54984e20b97285ca4a9ea39f953d548bc40ca63 Author: Francesco Zardi Date: Tue Sep 3 19:30:29 2024 +0200 rust: block: fix formatting of `kernel::block::mq::request` module [ Upstream commit 28e848386b92645f93b9f2fdba5882c3ca7fb3e2 ] Fix several issues with rustdoc formatting for the `kernel::block::mq::Request` module, in particular: - An ordered list not rendering correctly, fixed by using numbers prefixes instead of letters. - Code snippets formatted as regular text, fixed by wrapping the code with `back-ticks`. - References to types missing intra-doc links, fixed by wrapping the types with [square brackets]. Reported-by: Miguel Ojeda Closes: https://github.com/Rust-for-Linux/linux/issues/1108 Signed-off-by: Francesco Zardi Acked-by: Andreas Hindborg Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Link: https://lore.kernel.org/r/20240903173027.16732-3-frazar00@gmail.com [ Added an extra intra-doc link. Took the chance to add some periods for consistency. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit d16a004f9a2ce9719364be9fb59ce0e55162a372 Author: Ilpo Järvinen Date: Tue Oct 22 12:11:37 2024 +0300 PCI: cpqphp: Fix PCIBIOS_* return value confusion [ Upstream commit e2226dbc4a4919d9c8bd9293299b532090bdf020 ] Code in and related to PCI_RefinedAccessConfig() has three types of return type confusion: - PCI_RefinedAccessConfig() tests pci_bus_read_config_dword() return value against -1. - PCI_RefinedAccessConfig() returns both -1 and PCIBIOS_* return codes. - Callers of PCI_RefinedAccessConfig() only test for -1. Make PCI_RefinedAccessConfig() return PCIBIOS_* codes consistently and adapt callers accordingly. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/r/20241022091140.3504-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit babd60f2da2db9e711eefb5d118eab6ad249b739 Author: weiyufeng Date: Tue Aug 6 14:50:50 2024 +0800 PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads [ Upstream commit 87d5403378cccc557af9e02a8a2c8587ad8b7e9a ] Use PCI_POSSIBLE_ERROR() to check the response we get when we read data from hardware. This unifies PCI error response checking and makes error checks consistent and easier to find. Link: https://lore.kernel.org/r/20240806065050.28725-1-412574090@163.com Signed-off-by: weiyufeng Signed-off-by: Bjorn Helgaas Stable-dep-of: e2226dbc4a49 ("PCI: cpqphp: Fix PCIBIOS_* return value confusion") Signed-off-by: Sasha Levin commit c2b0d5a281d9e15b9ab28dac5c3ad74bfd4e9960 Author: Paolo Bonzini Date: Sat Oct 19 09:22:08 2024 +0200 rust: macros: fix documentation of the paste! macro [ Upstream commit 15541c9263ce34ff95a06bc68f45d9bc5c990bcd ] One of the example in this section uses a curious mix of the constant and function declaration syntaxes; fix it. Signed-off-by: Paolo Bonzini Reviewed-by: Alice Ryhl Fixes: 823d4737d4c2 ("rust: macros: add `paste!` proc macro") Link: https://lore.kernel.org/r/20241019072208.1016707-1-pbonzini@redhat.com Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit ce4d41f999fe4f9bc1de14ba49e404481bcb992c Author: Yutaro Ohno Date: Mon Oct 21 11:58:47 2024 +0900 rust: kernel: fix THIS_MODULE header path in ThisModule doc comment [ Upstream commit 8b55dc8610acf816a66373be53ca6e3bbe2d313a ] The doc comment for `ThisModule` incorrectly states the C header file for `THIS_MODULE` as `include/linux/export.h`, while the correct path is `include/linux/init.h`. This is because `THIS_MODULE` was moved in commit 5b20755b7780 ("init: move THIS_MODULE from to "). Update the doc comment for `ThisModule` to reflect the correct header file path for `THIS_MODULE`. Fixes: 5b20755b7780 ("init: move THIS_MODULE from to ") Signed-off-by: Yutaro Ohno Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/ZxXDZwxWgoEiIYkj@ohnotp Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 8c956c530ad4012d57d203b7ec68b4594b6b79d0 Author: Leo Yan Date: Sat Oct 12 15:14:32 2024 +0100 perf probe: Correct demangled symbols in C++ program [ Upstream commit 314909f13cc12d47c468602c37dace512d225eeb ] An issue can be observed when probe C++ demangled symbol with steps: # nm test_cpp_mangle | grep print_data 0000000000000c94 t _GLOBAL__sub_I__Z10print_datai 0000000000000afc T _Z10print_datai 0000000000000b38 T _Z10print_dataR5Point # perf probe -x /home/niayan01/test_cpp_mangle -F --demangle ... print_data(Point&) print_data(int) ... # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)" probe-definition(0): test=print_data(int) symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Open Debuginfo file: /home/niayan01/test_cpp_mangle Try to find probe point from debuginfo. Symbol print_data(int) address found : afc Matched function: print_data [2ccf] Probe point found: print_data+0 Found 1 probe_trace_events. Opening /sys/kernel/tracing//uprobe_events write=1 Opening /sys/kernel/tracing//README write=0 Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xb38 ... When tried to probe symbol "print_data(int)", the log shows: Symbol print_data(int) address found : afc The found address is 0xafc - which is right with verifying the output result from nm. Afterwards when write event, the command uses offset 0xb38 in the last log, which is a wrong address. The dwarf_diename() gets a common function name, in above case, it returns string "print_data". As a result, the tool parses the offset based on the common name. This leads to probe at the wrong symbol "print_data(Point&)". To fix the issue, use the die_get_linkage_name() function to retrieve the distinct linkage name - this is the mangled name for the C++ case. Based on this unique name, the tool can get a correct offset for probing. Based on DWARF doc, it is possible the linkage name is missed in the DIE, it rolls back to use dwarf_diename(). After: # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)" probe-definition(0): test=print_data(int) symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Open Debuginfo file: /home/niayan01/test_cpp_mangle Try to find probe point from debuginfo. Symbol print_data(int) address found : afc Matched function: print_data [2d06] Probe point found: print_data+0 Found 1 probe_trace_events. Opening /sys/kernel/tracing//uprobe_events write=1 Opening /sys/kernel/tracing//README write=0 Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xafc Added new event: probe_test_cpp_mangle:test (on print_data(int) in /home/niayan01/test_cpp_mangle) You can now use it in all perf tools, such as: perf record -e probe_test_cpp_mangle:test -aR sleep 1 # perf --debug verbose=3 probe -x test_cpp_mangle --add "test2=print_data(Point&)" probe-definition(0): test2=print_data(Point&) symbol:print_data(Point&) file:(null) line:0 offset:0 return:0 lazy:(null) 0 arguments Open Debuginfo file: /home/niayan01/test_cpp_mangle Try to find probe point from debuginfo. Symbol print_data(Point&) address found : b38 Matched function: print_data [2ccf] Probe point found: print_data+0 Found 1 probe_trace_events. Opening /sys/kernel/tracing//uprobe_events write=1 Parsing probe_events: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0x0000000000000afc Group:probe_test_cpp_mangle Event:test probe:p Opening /sys/kernel/tracing//README write=0 Writing event: p:probe_test_cpp_mangle/test2 /home/niayan01/test_cpp_mangle:0xb38 Added new event: probe_test_cpp_mangle:test2 (on print_data(Point&) in /home/niayan01/test_cpp_mangle) You can now use it in all perf tools, such as: perf record -e probe_test_cpp_mangle:test2 -aR sleep 1 Fixes: fb1587d869a3 ("perf probe: List probes with line number and file name") Signed-off-by: Leo Yan Acked-by: Masami Hiramatsu (Google) Link: https://lore.kernel.org/r/20241012141432.877894-1-leo.yan@arm.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8e5196dab39f8877d17cbb2abbfc60f9c00ee2c6 Author: Ian Rogers Date: Wed Oct 16 16:56:22 2024 -0700 perf probe: Fix libdw memory leak [ Upstream commit 4585038b8e186252141ef86e9f0d8e97f11dce8d ] Add missing dwarf_cfi_end to free memory associated with probe_finder cfi_eh which is allocated and owned via a call to dwarf_getcfi_elf. Confusingly cfi_dbg shouldn't be freed as its memory is owned by the passed in debuginfo struct. Add comments to highlight this. This addresses leak sanitizer issues seen in: tools/perf/tests/shell/test_uprobe_from_different_cu.sh Fixes: 270bde1e76f4 ("perf probe: Search both .eh_frame and .debug_frame sections for probe location") Signed-off-by: Ian Rogers Cc: David S. Miller Cc: Steinar H. Gunderson Cc: Alexander Lobakin Cc: Masami Hiramatsu (Google) Cc: Kajol Jain Cc: Athira Rajeev Cc: Hemant Kumar Link: https://lore.kernel.org/r/20241016235622.52166-3-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 7893c38ab2c7f42a8ebd8ba2ff1704e7c6f589a3 Author: Veronika Molnarova Date: Thu Oct 10 16:48:36 2024 +0200 perf dso: Fix symtab_type for kmod compression [ Upstream commit 05a62936e6b14c005db3b0c9c7d8b93d825dd9ca ] During the rework of the dso structure in patch ee756ef7491eafd an increment was forgotten for the symtab_type in case the data for the kernel module are compressed. This affects the probing of the kernel modules, which fails if the data are not already cached. Increment the value of the symtab_type to its compressed variant so the data could be recovered successfully. Fixes: ee756ef7491eafd7 ("perf dso: Add reference count checking and accessor functions") Signed-off-by: Veronika Molnarova Acked-by: Michael Petlan Acked-by: Namhyung Kim Tested-by: Michael Petlan Link: https://lore.kernel.org/r/20241010144836.16424-1-vmolnaro@redhat.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 9313b85ddc120e2d2f0efaf86d0204d4c98d60b1 Author: Chao Yu Date: Tue Oct 15 11:43:39 2024 +0800 f2fs: fix to account dirty data in __get_secs_required() [ Upstream commit 1acd73edbbfef2c3c5b43cba4006a7797eca7050 ] It will trigger system panic w/ testcase in [1]: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2752! RIP: 0010:new_curseg+0xc81/0x2110 Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is if checkpoint_disabling and lfs_mode are both on, it will trigger OPU for all overwritten data, it may cost more free segment than expected, so f2fs must account those data correctly to calculate cosumed free segments later, and return ENOSPC earlier to avoid run out of free segment during block allocation. [1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/ Fixes: 4354994f097d ("f2fs: checkpoint disabling") Cc: Daniel Rosenberg Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 32f5e291b7677495f98246eec573767430321c08 Author: Ye Bin Date: Sat Oct 12 00:44:50 2024 +0800 f2fs: fix null-ptr-deref in f2fs_submit_page_bio() [ Upstream commit b7d0a97b28083084ebdd8e5c6bccd12e6ec18faa ] There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register "f2fs_fs_type". To address above issue just register "f2fs_fs_type" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized. Fixes: f543805fcd60 ("f2fs: introduce private bioset") Signed-off-by: Ye Bin Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 9073773005e3f40d36918c3aa13a7c72fca12bf6 Author: Qi Han Date: Sun Sep 29 02:00:10 2024 -0600 f2fs: compress: fix inconsistent update of i_blocks in release_compress_blocks and reserve_compress_blocks [ Upstream commit 26413ce18e85de3dda2cd3d72c3c3e8ab8f4f996 ] After release a file and subsequently reserve it, the FSCK flag is set when the file is deleted, as shown in the following backtrace: F2FS-fs (dm-48): Inconsistent i_blocks, ino:401231, iblocks:1448, sectors:1472 fs_rec_info_write_type+0x58/0x274 f2fs_rec_info_write+0x1c/0x2c set_sbi_flag+0x74/0x98 dec_valid_block_count+0x150/0x190 f2fs_truncate_data_blocks_range+0x2d4/0x3cc f2fs_do_truncate_blocks+0x2fc/0x5f0 f2fs_truncate_blocks+0x68/0x100 f2fs_truncate+0x80/0x128 f2fs_evict_inode+0x1a4/0x794 evict+0xd4/0x280 iput+0x238/0x284 do_unlinkat+0x1ac/0x298 __arm64_sys_unlinkat+0x48/0x68 invoke_syscall+0x58/0x11c For clusters of the following type, i_blocks are decremented by 1 and i_compr_blocks are incremented by 7 in release_compress_blocks, while updates to i_blocks and i_compr_blocks are skipped in reserve_compress_blocks. raw node: D D D D D D D D after compress: C D D D D D D D after reserve: C D D D D D D D Let's update i_blocks and i_compr_blocks properly in reserve_compress_blocks. Fixes: eb8fbaa53374 ("f2fs: compress: fix to check unreleased compressed cluster") Signed-off-by: Qi Han Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 8306708b2e4b63e5fa28c9c51089116db32c2337 Author: Veronika Molnarova Date: Mon Mar 11 09:16:11 2024 +0100 perf test attr: Add back missing topdown events [ Upstream commit 6bff76af9635411214ca44ea38fc2781e78064b6 ] With the patch 0b6c5371c03c "Add missing topdown metrics events" eight topdown metric events with numbers ranging from 0x8000 to 0x8700 were added to the test since they were added as 'perf stat' default events. Later the patch 951efb9976ce "Update no event/metric expectations" kept only 4 of those events(0x8000-0x8300). Currently, the topdown events with numbers 0x8400 to 0x8700 are missing from the list of expected events resulting in a failure. Add back the missing topdown events. Fixes: 951efb9976ce ("perf test attr: Update no event/metric expectations") Signed-off-by: Veronika Molnarova Tested-by: Ian Rogers Cc: mpetlan@redhat.com Link: https://lore.kernel.org/r/20240311081611.7835-1-vmolnaro@redhat.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2c0c584c9ce8a5f3551a95c8bcfc6e0090b368d0 Author: Michael Petlan Date: Fri Sep 27 17:19:26 2024 +0200 perf trace: Keep exited threads for summary [ Upstream commit d29d92df410e2fb523f640478b18f70c1823e55e ] Since 9ffa6c7512ca ("perf machine thread: Remove exited threads by default") perf cleans exited threads up, but as said, sometimes they are necessary to be kept. The mentioned commit does not cover all the cases, we also need the information to construct the summary table in perf-trace. Before: # perf trace -s true Summary of events: After: # perf trace -s -- true Summary of events: true (383382), 64 events, 91.4% syscall calls errors total min avg max stddev (msec) (msec) (msec) (msec) (%) --------------- -------- ------ -------- --------- --------- --------- ------ mmap 8 0 0.150 0.013 0.019 0.031 11.90% mprotect 3 0 0.045 0.014 0.015 0.017 6.47% openat 2 0 0.014 0.006 0.007 0.007 9.73% munmap 1 0 0.009 0.009 0.009 0.009 0.00% access 1 1 0.009 0.009 0.009 0.009 0.00% pread64 4 0 0.006 0.001 0.001 0.002 4.53% fstat 2 0 0.005 0.001 0.002 0.003 37.59% arch_prctl 2 1 0.003 0.001 0.002 0.002 25.91% read 1 0 0.003 0.003 0.003 0.003 0.00% close 2 0 0.003 0.001 0.001 0.001 3.86% brk 1 0 0.002 0.002 0.002 0.002 0.00% rseq 1 0 0.001 0.001 0.001 0.001 0.00% prlimit64 1 0 0.001 0.001 0.001 0.001 0.00% set_robust_list 1 0 0.001 0.001 0.001 0.001 0.00% set_tid_address 1 0 0.001 0.001 0.001 0.001 0.00% execve 1 0 0.000 0.000 0.000 0.000 0.00% [namhyung: simplified the condition] Fixes: 9ffa6c7512ca ("perf machine thread: Remove exited threads by default") Reported-by: Veronika Molnarova Signed-off-by: Michael Petlan Link: https://lore.kernel.org/r/20240927151926.399474-1-mpetlan@redhat.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 2d7b331451563bf8076b941a9e988cc059616659 Author: Ian Rogers Date: Mon Sep 30 22:23:24 2024 -0700 perf stat: Fix affinity memory leaks on error path [ Upstream commit 7f6ccb70e465bd8c9cf8973aee1c01224e4bdb3c ] Missed cleanup when an error occurs. Fixes: 49de179577e7 ("perf stat: No need to setup affinities when starting a workload") Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20241001052327.7052-2-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 6c7386e1d1cea87296dcb9fd31f6b42c525106fa Author: Levi Yun Date: Wed Sep 25 14:20:21 2024 +0100 perf stat: Close cork_fd when create_perf_stat_counter() failed [ Upstream commit e880a70f8046df0dd9089fa60dcb866a2cc69194 ] When create_perf_stat_counter() failed, it doesn't close workload.cork_fd open in evlist__prepare_workload(). This could make too many open file error while __run_perf_stat() repeats. Introduce evlist__cancel_workload to close workload.cork_fd and wait workload.child_pid until exit to clear child process when create_perf_stat_counter() is failed. Signed-off-by: Levi Yun Reviewed-by: James Clark Reviewed-by: Andi Kleen Cc: nd@arm.com Cc: howardchu95@gmail.com Link: https://lore.kernel.org/r/20240925132022.2650180-2-yeoreum.yun@arm.com Signed-off-by: Namhyung Kim Stable-dep-of: 7f6ccb70e465 ("perf stat: Fix affinity memory leaks on error path") Signed-off-by: Sasha Levin commit 543d0eb40e45c6a51f1bff02f417b602e54472d5 Author: Todd Kjos Date: Tue Oct 1 23:11:47 2024 +0000 PCI: Fix reset_method_store() memory leak [ Upstream commit 2985b1844f3f3447f2d938eff1ef6762592065a5 ] In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces: while ((name = strsep(&options, " ")) != NULL) { If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup(). Fix by using a separate tmp_options to iterate with strsep() so options is preserved. Link: https://lore.kernel.org/r/20241001231147.3583649-1-tkjos@google.com Fixes: d88f521da3ef ("PCI: Allow userspace to query and set device reset mechanism") Signed-off-by: Todd Kjos Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 734118ac8aeec068afa66d307cc8be87e6719fa6 Author: Thomas Falcon Date: Thu Sep 26 09:40:40 2024 -0500 perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC} [ Upstream commit 4f23fc34cc68812c68c3a3dec15e26e87565f430 ] With commit 8ec9497d3ef34 ("tools/include: Sync uapi/linux/perf.h with the kernel sources"), 'perf mem report' gives an incorrect memory access string. ... 0.02% 1 3644 L5 hit [.] 0x0000000000009b0e mlc [.] 0x00007fce43f59480 ... This occurs because, if no entry exists in mem_lvlnum, perf_mem__lvl_scnprintf will default to 'L%d, lvl', which in this case for PERF_MEM_LVLNUM_L2_MHB is 0x05. Add entries for PERF_MEM_LVLNUM_L2_MHB and PERF_MEM_LVLNUM_MSC to mem_lvlnum, so that the correct strings are printed. ... 0.02% 1 3644 L2 MHB hit [.] 0x0000000000009b0e mlc [.] 0x00007fce43f59480 ... Fixes: 8ec9497d3ef34 ("tools/include: Sync uapi/linux/perf.h with the kernel sources") Suggested-by: Kan Liang Signed-off-by: Thomas Falcon Reviewed-by: Leo Yan Link: https://lore.kernel.org/r/20240926144040.77897-1-thomas.falcon@intel.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 46b18f03b5ae4d142a9615168ab29ec77ff1e82f Author: Weilin Wang Date: Sat Jul 20 02:21:01 2024 -0400 perf test: Add test for Intel TPEBS counting mode [ Upstream commit b2738fda24543777a623a7d1cc2a9985ab81b448 ] Intel TPEBS sampling mode is supported through perf record. The counting mode code uses perf record to capture retire_latency value and use it in metric calculation. This test checks the counting mode code on Intel platforms. Committer testing: root@x1:~# perf test tpebs 123: test Intel TPEBS counting mode : Ok root@x1:~# set -o vi root@x1:~# perf test tpebs 123: test Intel TPEBS counting mode : Ok root@x1:~# perf test -v tpebs 123: test Intel TPEBS counting mode : Ok root@x1:~# perf test -vvv tpebs 123: test Intel TPEBS counting mode: --- start --- test child forked, pid 16603 Testing without --record-tpebs Testing with --record-tpebs ---- end(0) ---- 123: test Intel TPEBS counting mode : Ok root@x1:~# Reviewed-by: Namhyung Kim Signed-off-by: Weilin Wang Acked-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Caleb Biggers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Perry Taylor Cc: Peter Zijlstra Cc: Samantha Alt Link: https://lore.kernel.org/r/20240720062102.444578-9-weilin.wang@intel.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: 057f8bfc6f70 ("perf stat: Uniquify event name improvements") Signed-off-by: Sasha Levin commit fc4aee33f7fb3e5547069a1dbf46ff1cfdc4b116 Author: Andreas Gruenbacher Date: Mon Aug 26 20:06:21 2024 +0200 gfs2: Fix unlinked inode cleanup [ Upstream commit 7c6f714d88475ceae5342264858a641eafa19632 ] Before commit f0e56edc2ec7 ("gfs2: Split the two kinds of glock "delete" work"), function delete_work_func() was used to trigger the eviction of in-memory inodes from remote as well as deleting unlinked inodes at a later point. These two kinds of work were then split into two kinds of work, and the two places in the code were deferred deletion of inodes is required accidentally ended up queuing the wrong kind of work. This caused unlinked inodes to be left behind, which could in the worst case fill up filesystems and require a filesystem check to recover. Fix that by queuing the right kind of work in try_rgrp_unlink() and gfs2_drop_inode(). Fixes: f0e56edc2ec7 ("gfs2: Split the two kinds of glock "delete" work") Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit b32d468ccbc2555ec0954539a5a275ba7461dde4 Author: Andreas Gruenbacher Date: Tue Sep 24 18:38:00 2024 +0200 gfs2: Allow immediate GLF_VERIFY_DELETE work [ Upstream commit 160bc9555d8654464cbbd7bb1f6687048471d2f6 ] Add an argument to gfs2_queue_verify_delete() that allows it to queue GLF_VERIFY_DELETE work for immediate execution. This is used in the next patch. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 7c6f714d8847 ("gfs2: Fix unlinked inode cleanup") Signed-off-by: Sasha Levin commit 1d50b457c6eaed2a7067f92ab3ae06baa35dfc83 Author: Andreas Gruenbacher Date: Wed Aug 21 22:02:05 2024 +0200 gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE [ Upstream commit 820ce8ed53ce2111aa5171f7349f289d7e9d0693 ] Rename the GLF_VERIFY_EVICT flag to GLF_VERIFY_DELETE: that flag indicates that we want to delete an inode / verify that it has been deleted. To match, rename gfs2_queue_verify_evict() to gfs2_queue_verify_delete(). Signed-off-by: Andreas Gruenbacher Stable-dep-of: 7c6f714d8847 ("gfs2: Fix unlinked inode cleanup") Signed-off-by: Sasha Levin commit f1296ff3b07d648e9e40c0044894e34a4a0a3254 Author: James Clark Date: Mon Sep 16 14:57:32 2024 +0100 perf cs-etm: Don't flush when packet_queue fills up [ Upstream commit 5afd032961e8465808c4bc385c06e7676fbe1951 ] cs_etm__flush(), like cs_etm__sample() is an operation that generates a sample and then swaps the current with the previous packet. Calling flush after processing the queues results in two swaps which corrupts the next sample. Therefore it wasn't appropriate to call flush here so remove it. Flushing is still done on a discontinuity to explicitly clear the last branch buffer, but when the packet_queue fills up before reaching a timestamp, that's not a discontinuity and the call to cs_etm__process_traceid_queue() already generated samples and drained the buffers correctly. This is visible by looking for a branch that has the same target as the previous branch and the following source is before the address of the last target, which is impossible as execution would have had to have gone backwards: ffff800080849d40 _find_next_and_bit+0x78 => ffff80008011cadc update_sg_lb_stats+0x94 (packet_queue fills here before a timestamp, resulting in a flush and branch target ffff80008011cadc is duplicated.) ffff80008011cb1c update_sg_lb_stats+0xd4 => ffff80008011cadc update_sg_lb_stats+0x94 ffff8000801117c4 cpu_util+0x24 => ffff8000801117d4 cpu_util+0x34 After removing the flush the correct branch target is used for the second sample, and ffff8000801117c4 is no longer before the previous address: ffff800080849d40 _find_next_and_bit+0x78 => ffff80008011cadc update_sg_lb_stats+0x94 ffff80008011cb1c update_sg_lb_stats+0xd4 => ffff8000801117a0 cpu_util+0x0 ffff8000801117c4 cpu_util+0x24 => ffff8000801117d4 cpu_util+0x34 Make sure that a final branch stack is output at the end of the trace by calling cs_etm__end_block(). This is already done for both the timeless decode paths. Fixes: 21fe8dc1191a ("perf cs-etm: Add support for CPU-wide trace scenarios") Reported-by: Ganapatrao Kulkarni Closes: https://lore.kernel.org/all/20240719092619.274730-1-gankulkarni@os.amperecomputing.com/ Reviewed-by: Leo Yan Signed-off-by: James Clark Tested-by: Ganapatrao Kulkarni Cc: Ben Gainey Cc: Suzuki K Poulose Cc: Will Deacon Cc: Mathieu Poirier Cc: Mike Leach Cc: Ruidong Tian Cc: Benjamin Gray Cc: linux-arm-kernel@lists.infradead.org Cc: coresight@lists.linaro.org Cc: John Garry Cc: scclevenger@os.amperecomputing.com Link: https://lore.kernel.org/r/20240916135743.1490403-2-james.clark@linaro.org Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin commit 8e25f014473c8c9baf37431eb41fdffe7c9ef4d1 Author: David Laight Date: Sun Nov 24 15:39:00 2024 +0000 x86: fix off-by-one in access_ok() [ Upstream commit 573f45a9f9a47fed4c7957609689b772121b33d7 ] When the size isn't a small constant, __access_ok() will call valid_user_address() with the address after the last byte of the user buffer. It is valid for a buffer to end with the last valid user address so valid_user_address() must allow accesses to the base of the guard page. [ This introduces an off-by-one in the other direction for the plain non-sized accesses, but since we have that guard region that is a whole page, those checks "allowing" accesses to that guard region don't really matter. The access will fault anyway, whether to the guard page or if the address has been masked to all ones - Linus ] Fixes: 86e6b1547b3d0 ("x86: fix user address masking non-canonical speculation issue") Signed-off-by: David Laight Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 28014e25dc94536121d6c93fa865790aaed1be7d Author: Dan Carpenter Date: Thu Nov 14 12:00:12 2024 +0300 mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb() [ Upstream commit 192a16a3430ca459c4e986f3d10758c4d6b1aa29 ] Both the inner and outer loops in this code use the "i" iterator. The inner loop should really use a different iterator. It doesn't affect things in practice because the data comes from the device tree. The "protocol" and "windows" variables are going to be zero. That means we're always going to hit the "return &chans[channel];" statement and we're not going to want to iterate through the outer loop again. Still it's worth fixing this for future use cases. Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver") Signed-off-by: Dan Carpenter Acked-by: Viresh Kumar Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 31986fad0cfdda8d8893230da04f5eb0774854d9 Author: Yang Yingliang Date: Tue Oct 29 21:16:28 2024 +0800 mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks() [ Upstream commit 271ee263cc8771982809185007181ca10346fe73 ] It should be size of the struct clk_bulk_data, not data pointer pass to devm_kcalloc(). Fixes: aa1609f571ca ("mailbox: mtk-cmdq: Dynamically allocate clk_bulk_data structure") Signed-off-by: Yang Yingliang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit edbb3262e7e332009b812a80ff1dbf0670bc768d Author: Paul Aurich Date: Fri Nov 8 14:29:02 2024 -0800 smb: cached directories can be more than root file handle [ Upstream commit 128630e1dbec8074c7707aad107299169047e68f ] Update this log message since cached fids may represent things other than the root of a mount. Fixes: e4029e072673 ("cifs: find and use the dentry for cached non-root directories also") Signed-off-by: Paul Aurich Reviewed-by: Bharath SM Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 44a85879cf14c0016a3313bb19bc3d690d12dabb Author: Tomas Glozar Date: Mon Oct 21 14:31:40 2024 +0200 rtla/timerlat: Do not set params->user_workload with -U [ Upstream commit fcbc60d7dc4b125c8de130aa1512e5d20726c06e ] Since commit fb9e90a67ee9 ("rtla/timerlat: Make user-space threads the default"), rtla-timerlat has been defaulting to params->user_workload if neither that or params->kernel_workload is set. This has unintentionally made -U, which sets only params->user_hist/top but not params->user_workload, to behave like -u unless -k is set, preventing the user from running a custom workload. Example: $ rtla timerlat hist -U -c 0 & [1] 7413 $ python sample/timerlat_load.py 0 Error opening timerlat fd, did you run timerlat -U? $ ps | grep timerlatu 7415 pts/4 00:00:00 timerlatu/0 Fix the issue by checking for params->user_top/hist instead of params->user_workload when setting default thread mode. Link: https://lore.kernel.org/20241021123140.14652-1-tglozar@redhat.com Fixes: fb9e90a67ee9 ("rtla/timerlat: Make user-space threads the default") Signed-off-by: Tomas Glozar Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit ca9cf0f3586510ad951f3289ab1cb220694971da Author: zhang jiao Date: Wed Nov 13 15:12:01 2024 +0800 pinctrl: k210: Undef K210_PC_DEFAULT [ Upstream commit 7e86490c5dee5c41a55f32d0dc34269e200e6909 ] When the temporary macro K210_PC_DEFAULT is not needed anymore, use its name in the #undef statement instead of the incorrect "DEFAULT" name. Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver") Signed-off-by: zhang jiao Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/20241113071201.5440-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d5b9cb9044302605e916d57374b2ff552a9d5144 Author: Konrad Dybcio Date: Sat Nov 16 12:31:18 2024 +0100 arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw [ Upstream commit 5df30684415d5a902f23862ab5bbed2a2df7fbf1 ] Comply with bindings guidelines and get rid of errors such as: cpufreq@18323000: compatible: 'oneOf' conditional failed, one must be fixed: ['qcom,cpufreq-hw'] is too short Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b2f7056f544eb342965729a73180aa26466c5d59 Author: Nuno Sa Date: Tue Oct 29 14:59:42 2024 +0100 clk: clk-axi-clkgen: make sure to enable the AXI bus clock [ Upstream commit c64ef7e4851d1a9abbb7f7833e4936973ac5ba79 ] In order to access the registers of the HW, we need to make sure that the AXI bus clock is enabled. Hence let's increase the number of clocks by one. In order to keep backward compatibility and make sure old DTs still work we check if clock-names is available or not. If it is, then we can disambiguate between really having the AXI clock or a parent clock and so we can enable the bus clock. If not, we fallback to what was done before and don't explicitly enable the AXI bus clock. Note that if clock-names is given, the axi clock must be the last one in the phandle array (also enforced in the DT bindings) so that we can reuse as much code as possible. Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-2-bc5e0733ad76@analog.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 73eb212658fb20dded68ba3959b94ebcac26953f Author: Nuno Sa Date: Tue Oct 29 14:59:41 2024 +0100 dt-bindings: clock: axi-clkgen: include AXI clk [ Upstream commit 47f3f5a82a31527e027929c5cec3dd1ef5ef30f5 ] In order to access the registers of the HW, we need to make sure that the AXI bus clock is enabled. Hence let's increase the number of clocks by one and add clock-names to differentiate between parent clocks and the bus clock. Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20241029-axi-clkgen-fix-axiclk-v2-1-bc5e0733ad76@analog.com Reviewed-by: Conor Dooley Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5a340eea4f7e962e05dfbad268f8a5bde29ceff1 Author: Lorenzo Bianconi Date: Tue Nov 12 01:08:52 2024 +0100 clk: en7523: fix estimation of fixed rate for EN7581 [ Upstream commit f98eded9e9ab048c88ff59c5523e703a6ced5523 ] Introduce en7581_base_clks array in order to define per-SoC fixed-rate clock parameters and fix wrong parameters for emi, npu and crypto EN7581 clocks Fixes: 66bc47326ce2 ("clk: en7523: Add EN7581 support") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-5-8ada5e394ae4@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 19f247e80d6ec84034d0bf57dde5d16acfc490cb Author: Lorenzo Bianconi Date: Tue Nov 12 01:08:51 2024 +0100 clk: en7523: introduce chip_scu regmap [ Upstream commit f72fc22038dd544fa4d39c06e8c81c09c0041ed4 ] Introduce chip_scu regmap pointer since EN7581 SoC will access chip-scu memory area via a syscon node. Remove first memory region mapping for EN7581 SoC. This patch does not introduce any backward incompatibility since the dts for EN7581 SoC is not upstream yet. Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-4-8ada5e394ae4@kernel.org Signed-off-by: Stephen Boyd Stable-dep-of: f98eded9e9ab ("clk: en7523: fix estimation of fixed rate for EN7581") Signed-off-by: Sasha Levin commit 62acb701fa465a7f94c00cfbd85f0c0723bb0cb7 Author: Lorenzo Bianconi Date: Tue Nov 12 01:08:50 2024 +0100 clk: en7523: move clock_register in hw_init callback [ Upstream commit b8bdfc666bc5f58caf46e67b615132fccbaca3d4 ] Move en7523_register_clocks routine in hw_init callback. Introduce en7523_clk_hw_init callback for EN7523 SoC. This is a preliminary patch to differentiate IO mapped region between EN7523 and EN7581 SoCs in order to access chip-scu IO region <0x1fa20000 0x384> on EN7581 SoC as syscon device since it contains miscellaneous registers needed by multiple devices (clock, pinctrl ..). Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-3-8ada5e394ae4@kernel.org Signed-off-by: Stephen Boyd Stable-dep-of: f98eded9e9ab ("clk: en7523: fix estimation of fixed rate for EN7581") Signed-off-by: Sasha Levin commit a43c8bbc89cb1dd5fa3b78769c84ddca76f506fa Author: Lorenzo Bianconi Date: Tue Nov 12 01:08:49 2024 +0100 clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration [ Upstream commit c31d1cdd7bff1d2c13d435bb9d0c76bfaa332097 ] REG_PCIE*_MEM and REG_PCIE*_MEM_MASK regs (PBUS_CSR memory region) are not part of the scu block on the EN7581 SoC and they are used to select the PCIE ports on the PBUS, so remove this configuration from the clock driver and set these registers in the PCIE host driver instead. This patch does not introduce any backward incompatibility since the dts for EN7581 SoC is not upstream yet. Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/20241112-clk-en7581-syscon-v2-2-8ada5e394ae4@kernel.org Signed-off-by: Stephen Boyd Stable-dep-of: f98eded9e9ab ("clk: en7523: fix estimation of fixed rate for EN7581") Signed-off-by: Sasha Levin commit fe09d609f2304c7775789090e3f006d786852148 Author: Sergio Paracuellos Date: Tue Sep 10 06:40:23 2024 +0200 clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs [ Upstream commit d34db686a3d74bd564bfce2ada15011c556269fc ] Base clocks are the first in being probed and are real dependencies of the rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880, RT305x and RT3883 'xtal' must be defined first since in any other case, when fixed clocks are probed they are delayed until 'xtal' is probed so the following warning appears: WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0 Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000 ... Call Trace: [<800065d0>] show_stack+0x64/0xf4 [<804bca14>] dump_stack_lvl+0x38/0x60 [<800218ac>] __warn+0x94/0xe4 [<8002195c>] warn_slowpath_fmt+0x60/0x94 [<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138 [<80254530>] __clk_register+0x568/0x688 [<80254838>] of_clk_hw_register+0x18/0x2c [<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594 [<8070b628>] of_clk_init+0x1c0/0x23c [<806fc448>] plat_time_init+0x58/0x18c [<806fdaf0>] time_init+0x10/0x6c [<806f9bc4>] start_kernel+0x458/0x67c ---[ end trace 0000000000000000 ]--- When this driver was mainlined we could not find any active users of old ralink SoCs so we cannot perform any real tests for them. Now, one user of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and reported some issues in openWRT: - https://github.com/openwrt/openwrt/issues/16054 Thus, define a 'rt2880_xtal_recalc_rate()' just returning the expected frequency 40Mhz and use it along the old ralink SoCs to have a correct boot trace with no warnings and a working clock plan from the beggining. Fixes: 6f3b15586eef ("clk: ralink: add clock and reset driver for MTMIPS SoCs") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20240910044024.120009-3-sergio.paracuellos@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 9afb8e46bbc4b6f9f16f8bf3ca21d1c55232e990 Author: Sergio Paracuellos Date: Tue Sep 10 06:40:22 2024 +0200 clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883 [ Upstream commit 33239152305567b3e9bf052f71fd4baecd626341 ] Clock plan for Ralink SoC RT3883 needs an extra 'periph' clock to properly set some peripherals that has this clock as their parent. When this driver was mainlined we could not find any active users of this SoC so we cannot perform any real tests for it. Now, one user of a Belkin f9k1109 version 1 device which uses this SoC appear and reported some issues in openWRT: - https://github.com/openwrt/openwrt/issues/16054 The peripherals that are wrong are 'uart', 'i2c', 'i2s' and 'uartlite' which has a not defined 'periph' clock as parent. Hence, introduce it to have a properly working clock plan for this SoC. Fixes: 6f3b15586eef ("clk: ralink: add clock and reset driver for MTMIPS SoCs") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20240910044024.120009-2-sergio.paracuellos@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 066c14619e8379c1bafbbf8196fd38eac303472b Author: Charles Han Date: Thu Nov 14 15:28:20 2024 +0800 clk: clk-apple-nco: Add NULL check in applnco_probe [ Upstream commit 969c765e2b508cca9099d246c010a1e48dcfd089 ] Add NULL check in applnco_probe, to handle kernel NULL pointer dereference error. Fixes: 6641057d5dba ("clk: clk-apple-nco: Add driver for Apple NCO") Signed-off-by: Charles Han Link: https://lore.kernel.org/r/20241114072820.3071-1-hanchunchao@inspur.com Reviewed-by: Martin Povišer Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 542bd62b7a7f37182c9ef192c2bd25d118c144e4 Author: Patrisious Haddad Date: Wed Nov 13 13:23:19 2024 +0200 RDMA/mlx5: Move events notifier registration to be after device registration [ Upstream commit ede132a5cf559f3ab35a4c28bac4f4a6c20334d8 ] Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]--- Fixes: 7722f47e71e5 ("IB/mlx5: Create GSI transmission QPs when P_Key table is changed") Signed-off-by: Patrisious Haddad Reviewed-by: Michael Guralnik Link: https://patch.msgid.link/d271ceeff0c08431b3cbbbb3e2d416f09b6d1621.1731496944.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit d10cd53e5a7fb3b7c6f83d4d9a5ea1d97a3ed9a5 Author: Zhen Lei Date: Sat Oct 26 11:56:34 2024 +0800 fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() [ Upstream commit f89d17ae2ac42931be2a0153fecbf8533280c927 ] When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver") Signed-off-by: Zhen Lei Reviewed-by: Dmitry Baryshkov Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit a153942d2512ad087c0f19c8e37a0cac66626ed2 Author: Zhang Zekun Date: Mon Sep 30 15:56:28 2024 +0800 powerpc/kexec: Fix return of uninitialized variable [ Upstream commit 83b5a407fbb73e6965adfb4bd0a803724bf87f96 ] of_property_read_u64() can fail and leave the variable uninitialized, which will then be used. Return error if reading the property failed. Fixes: 2e6bd221d96f ("powerpc/kexec_file: Enable early kernel OPAL calls") Signed-off-by: Zhang Zekun Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20240930075628.125138-1-zhangzekun11@huawei.com Signed-off-by: Sasha Levin commit 9172658027865c7f2014e271b5db01b7f388d0f9 Author: Kajol Jain Date: Thu Nov 14 14:20:20 2024 +0530 KVM: PPC: Book3S HV: Fix kmv -> kvm typo [ Upstream commit 590d2f9347f7974d7954400e5d937672fd844a8b ] Fix typo in the following kvm function names from: kmvhv_counters_tracepoint_regfunc -> kvmhv_counters_tracepoint_regfunc kmvhv_counters_tracepoint_unregfunc -> kvmhv_counters_tracepoint_unregfunc Fixes: e1f288d2f9c6 ("KVM: PPC: Book3S HV nestedv2: Add support for reading VPA counters for pseries guests") Reported-by: Madhavan Srinivasan Reviewed-by: Ritesh Harjani (IBM) Reviewed-by: Amit Machhiwal Signed-off-by: Kajol Jain Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241114085020.1147912-1-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 84707ec6f651df98a141cad59f726d30e6f15574 Author: Feng Fang Date: Tue Nov 12 13:55:53 2024 +0800 RDMA/hns: Fix different dgids mapping to the same dip_idx [ Upstream commit faa62440a5772b40bb7d78bf9e29556a82ecf153 ] DIP algorithm requires a one-to-one mapping between dgid and dip_idx. Currently a queue 'spare_idx' is used to store QPN of QPs that use DIP algorithm. For a new dgid, use a QPN from spare_idx as dip_idx. This method lacks a mechanism for deduplicating QPN, which may result in different dgids sharing the same dip_idx and break the one-to-one mapping requirement. This patch replaces spare_idx with xarray and introduces a refcnt of a dip_idx to indicate the number of QPs that using this dip_idx. The state machine for dip_idx management is implemented as: * The entry at an index in xarray is empty -- This indicates that the corresponding dip_idx hasn't been created. * The entry at an index in xarray is not empty but with 0 refcnt -- This indicates that the corresponding dip_idx has been created but not used as dip_idx yet. * The entry at an index in xarray is not empty and with non-0 refcnt -- This indicates that the corresponding dip_idx is being used by refcnt number of DIP QPs. Fixes: eb653eda1e91 ("RDMA/hns: Bugfix for incorrect association between dip_idx and dgid") Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Signed-off-by: Feng Fang Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20241112055553.3681129-1-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit aa2d9f3c642b825cd9d84521808b22890c55b125 Author: Michal Suchanek Date: Tue Oct 1 15:03:49 2024 +0200 powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static [ Upstream commit a26c4dbb3d9c1821cb0fc11cb2dbc32d5bf3463b ] These functions are not used outside of sstep.c Fixes: 350779a29f11 ("powerpc: Handle most loads and stores in instruction emulation code") Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241001130356.14664-1-msuchanek@suse.de Signed-off-by: Sasha Levin commit 9d7a0340221790447d84a2272e037f06757aad1d Author: Gautam Menghani Date: Sat Nov 9 12:02:57 2024 +0530 KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending doorbells [ Upstream commit 26686db69917399fa30e3b3135360771e90f83ec ] Commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes") dropped the use of vcore->dpdes for msgsndp / SMT emulation. Prior to that commit, the below code at L1 level (see [1] for terminology) was responsible for setting vc->dpdes for the respective L2 vCPU: if (!nested) { kvmppc_core_prepare_to_enter(vcpu); if (vcpu->arch.doorbell_request) { vc->dpdes = 1; smp_wmb(); vcpu->arch.doorbell_request = 0; } L1 then sent vc->dpdes to L0 via kvmhv_save_hv_regs(), and while servicing H_ENTER_NESTED at L0, the below condition at L0 level made sure to abort and go back to L1 if vcpu->arch.doorbell_request = 1 so that L1 sets vc->dpdes as per above if condition: } else if (vcpu->arch.pending_exceptions || vcpu->arch.doorbell_request || xive_interrupt_pending(vcpu)) { vcpu->arch.ret = RESUME_HOST; goto out; } This worked fine since vcpu->arch.doorbell_request was used more like a flag and vc->dpdes was used to pass around the doorbell state. But after Commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes"), vcpu->arch.doorbell_request is the only variable used to pass around doorbell state. With the plumbing for handling doorbells for nested guests updated to use vcpu->arch.doorbell_request over vc->dpdes, the above "else if" stops doorbells from working correctly as L0 aborts execution of L2 and instead goes back to L1. Remove vcpu->arch.doorbell_request from the above "else if" condition as it is no longer needed for L0 to correctly handle the doorbell status while running L2. [1] Terminology 1. L0 : PowerNV linux running with HV privileges 2. L1 : Pseries KVM guest running on top of L0 2. L2 : Nested KVM guest running on top of L1 Fixes: 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes") Signed-off-by: Gautam Menghani Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241109063301.105289-4-gautam@linux.ibm.com Signed-off-by: Sasha Levin commit 20cf8f8ef8bae62d779ea2ab3bcac644eefc7546 Author: Gautam Menghani Date: Sat Nov 9 12:02:56 2024 +0530 KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests [ Upstream commit 0d3c6b28896f9889c8864dab469e0343a0ad1c0c ] commit 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes") introduced an optimization to use only vcpu->doorbell_request for SMT emulation for Power9 and above guests, but the code for nested guests still relies on the old way of handling doorbells, due to which an L2 guest (see [1]) cannot be booted with XICS with SMT>1. The command to repro this issue is: // To be run in L1 qemu-system-ppc64 \ -drive file=rhel.qcow2,format=qcow2 \ -m 20G \ -smp 8,cores=1,threads=8 \ -cpu host \ -nographic \ -machine pseries,ic-mode=xics -accel kvm Fix the plumbing to utilize vcpu->doorbell_request instead of vcore->dpdes for nested KVM guests on P9 and above. [1] Terminology 1. L0 : PowerNV linux running with HV privileges 2. L1 : Pseries KVM guest running on top of L0 2. L2 : Nested KVM guest running on top of L1 Fixes: 6398326b9ba1 ("KVM: PPC: Book3S HV P9: Stop using vc->dpdes") Signed-off-by: Gautam Menghani Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241109063301.105289-3-gautam@linux.ibm.com Signed-off-by: Sasha Levin commit f485aa069cc23ccf37b245928a70e6caf78338aa Author: Harshit Mogalapalli Date: Thu Oct 17 03:11:25 2024 -0700 dax: delete a stale directory pmem [ Upstream commit b8e6d7ce50673c39514921ac61f7af00bbb58b87 ] After commit: 83762cb5c7c4 ("dax: Kill DEV_DAX_PMEM_COMPAT") the pmem/ directory is not needed anymore and Makefile changes were made accordingly in this commit, but there is a Makefile and pmem.c in pmem/ which are now stale and pmem.c is empty, remove them. Fixes: 83762cb5c7c4 ("dax: Kill DEV_DAX_PMEM_COMPAT") Suggested-by: Vegard Nossum Signed-off-by: Harshit Mogalapalli Reviewed-by: Dan Williams Reviewed-by: Ira Weiny Link: https://patch.msgid.link/20241017101144.1654085-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Ira Weiny Signed-off-by: Sasha Levin commit 366c933c2ab34dd6551acc03b4872726b7605143 Author: Dmitry Antipov Date: Tue Oct 29 12:17:36 2024 +0300 ocfs2: fix uninitialized value in ocfs2_file_read_iter() [ Upstream commit adc77b19f62d7e80f98400b2fca9d700d2afdd6f ] Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'. Link: https://lkml.kernel.org/r/20241029091736.1501946-1-dmantipov@yandex.ru Fixes: 7cdfc3a1c397 ("ocfs2: Remember rw lock level during direct io") Signed-off-by: Dmitry Antipov Reported-by: syzbot+a73e253cca4f0230a5a5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a73e253cca4f0230a5a5 Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Joseph Qi Cc: Changwei Ge Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit a8cc8a82297c0005f8850162385232c99d36046a Author: Dan Carpenter Date: Mon Nov 4 20:16:30 2024 +0300 kunit: skb: use "gfp" variable instead of hardcoding GFP_KERNEL [ Upstream commit fd0a5afb5455b4561bfc6dfb0c4b2d8226f9ccfe ] The intent here was clearly to use the gfp variable flags instead of hardcoding GFP_KERNEL. All the callers pass GFP_KERNEL as the gfp flags so this doesn't affect runtime. Fixes: b3231d353a51 ("kunit: add a convenience allocation wrapper for SKBs") Signed-off-by: Dan Carpenter Reviewed-by: David Gow Reviewed-by: Kuan-Wei Chiu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 93b69473a727f6400a0bdcc7668211c73a7efd80 Author: Sabyrzhan Tasbolatov Date: Wed Oct 16 18:18:00 2024 +0500 kasan: move checks to do_strncpy_from_user [ Upstream commit ae193dd79398970ee760e0c8129ac42ef8f5c6ff ] Patch series "kasan: migrate the last module test to kunit", v4. copy_user_test() is the last KUnit-incompatible test with CONFIG_KASAN_MODULE_TEST requirement, which we are going to migrate to KUnit framework and delete the former test and Kconfig as well. In this patch series: - [1/3] move kasan_check_write() and check_object_size() to do_strncpy_from_user() to cover with KASAN checks with multiple conditions in strncpy_from_user(). - [2/3] migrated copy_user_test() to KUnit, where we can also test strncpy_from_user() due to [1/4]. KUnits have been tested on: - x86_64 with CONFIG_KASAN_GENERIC. Passed - arm64 with CONFIG_KASAN_SW_TAGS. 1 fail. See [1] - arm64 with CONFIG_KASAN_HW_TAGS. 1 fail. See [1] [1] https://lore.kernel.org/linux-mm/CACzwLxj21h7nCcS2-KA_q7ybe+5pxH0uCDwu64q_9pPsydneWQ@mail.gmail.com/ - [3/3] delete CONFIG_KASAN_MODULE_TEST and documentation occurrences. This patch (of 3): Since in the commit 2865baf54077("x86: support user address masking instead of non-speculative conditional") do_strncpy_from_user() is called from multiple places, we should sanitize the kernel *dst memory and size which were done in strncpy_from_user() previously. Link: https://lkml.kernel.org/r/20241016131802.3115788-1-snovitoll@gmail.com Link: https://lkml.kernel.org/r/20241016131802.3115788-2-snovitoll@gmail.com Fixes: 2865baf54077 ("x86: support user address masking instead of non-speculative conditional") Signed-off-by: Sabyrzhan Tasbolatov Reviewed-by: Andrey Konovalov Cc: Alexander Potapenko Cc: Alex Shi Cc: Andrey Ryabinin Cc: Dmitry Vyukov Cc: Hu Haowen <2023002089@link.tyut.edu.cn> Cc: Jonathan Corbet Cc: Marco Elver Cc: Vincenzo Frascino Cc: Yanteng Si Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit c0f847dd01be673f295535ea91586fd10e46f59c Author: Jinjie Ruan Date: Wed Nov 6 09:01:11 2024 +0800 cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power() [ Upstream commit b51eb0874d8170028434fbd259e80b78ed9b8eca ] cppc_get_cpu_power() return 0 if the policy is NULL. Then in em_create_perf_table(), the later zero check for power is not valid as power is uninitialized. As Quentin pointed out, kernel energy model core check the return value of active_power() first, so if the callback failed it should tell the core. So return -EINVAL to fix it. Fixes: a78e72075642 ("cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()") Signed-off-by: Jinjie Ruan Suggested-by: Quentin Perret Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit cbbeafbef7c5223696c5c13ee92a53635e3b9da9 Author: Jinjie Ruan Date: Wed Nov 6 09:12:38 2024 +0800 cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost() [ Upstream commit be392aa80f1e5b0b65ccc2a540b9304fefcfe3d8 ] cppc_get_cpu_cost() return 0 if the policy is NULL. Then in em_compute_costs(), the later zero check for cost is not valid as cost is uninitialized. As Quentin pointed out, kernel energy model core check the return value of get_cost() first, so if the callback failed it should tell the core. Return -EINVAL to fix it. Fixes: 1a1374bb8c59 ("cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/c4765377-7830-44c2-84fa-706b6e304e10@stanley.mountain/ Signed-off-by: Jinjie Ruan Suggested-by: Quentin Perret Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit f1b91e6920465256b65186fda0faf8feaf6f99c7 Author: Andy Shevchenko Date: Thu Oct 31 15:46:34 2024 +0200 cpufreq: loongson3: Check for error code from devm_mutex_init() call [ Upstream commit db01e46689e9a986ca6b5d2f41b57d7a81551a4f ] Even if it's not critical, the avoidance of checking the error code from devm_mutex_init() call today diminishes the point of using devm variant of it. Tomorrow it may even leak something. Add the missed check. Fixes: ccf51454145b ("cpufreq: Add Loongson-3 CPUFreq driver support") Signed-off-by: Andy Shevchenko Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 71becb0e9df78a8d43dfd0efcef18c830a0af477 Author: Junxian Huang Date: Fri Nov 8 15:57:43 2024 +0800 RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg() [ Upstream commit 6b526d17eed850352d880b93b9bf20b93006bd92 ] ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument. The driver needs to check whether it is a NULL pointer before dereferencing it. Fixes: d387d4b54eb8 ("RDMA/hns: Fix missing pagesize and alignment check in FRMR") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20241108075743.2652258-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit ecc5802fd707d635e25dff935ba8b6bc81e730ac Author: Junxian Huang Date: Fri Nov 8 15:57:42 2024 +0800 RDMA/hns: Fix out-of-order issue of requester when setting FENCE [ Upstream commit 5dbcb1c1900f45182b5651c89257c272f1f3ead7 ] The FENCE indicator in hns WQE doesn't ensure that response data from a previous Read/Atomic operation has been written to the requester's memory before the subsequent Send/Write operation is processed. This may result in the subsequent Send/Write operation accessing the original data in memory instead of the expected response data. Unlike FENCE, the SO (Strong Order) indicator blocks the subsequent operation until the previous response data is written to memory and a bresp is returned. Set the SO indicator instead of FENCE to maintain strict order. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Junxian Huang Link: https://patch.msgid.link/20241108075743.2652258-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 6fc8f37f501a70dc93744da3fd3a4281d9ddfa5a Author: Sourabh Jain Date: Thu Nov 7 11:28:17 2024 +0530 fadump: reserve param area if below boot_mem_top [ Upstream commit fb90dca828b6070709093934c6dec56489a2d91d ] The param area is a memory region where the kernel places additional command-line arguments for fadump kernel. Currently, the param memory area is reserved in fadump kernel if it is above boot_mem_top. However, it should be reserved if it is below boot_mem_top because the fadump kernel already reserves memory from boot_mem_top to the end of DRAM. Currently, there is no impact from not reserving param memory if it is below boot_mem_top, as it is not used after the early boot phase of the fadump kernel. However, if this changes in the future, it could lead to issues in the fadump kernel. Fixes: 3416c9daa6b1 ("powerpc/fadump: pass additional parameters when fadump is active") Acked-by: Hari Bathini Signed-off-by: Sourabh Jain Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241107055817.489795-2-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit 01368e5ecaba6b13a9ae00934446f2e7d143d82f Author: Hari Bathini Date: Thu Nov 7 11:28:16 2024 +0530 powerpc/fadump: allocate memory for additional parameters early [ Upstream commit f4892c68ecc1cf45e41a78820dd2eebccc945b66 ] Memory for passing additional parameters to fadump capture kernel is allocated during subsys_initcall level, using memblock. But as slab is already available by this time, allocation happens via the buddy allocator. This may work for radix MMU but is likely to fail in most cases for hash MMU as hash MMU needs this memory in the first memory block for it to be accessible in real mode in the capture kernel (second boot). So, allocate memory for additional parameters area as soon as MMU mode is obvious. Fixes: 683eab94da75 ("powerpc/fadump: setup additional parameters for dump capture kernel") Reported-by: Venkat Rao Bagalkote Closes: https://lore.kernel.org/lkml/a70e4064-a040-447b-8556-1fd02f19383d@linux.vnet.ibm.com/T/#u Signed-off-by: Hari Bathini Signed-off-by: Sourabh Jain Tested-by: Venkat Rao Bagalkote Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241107055817.489795-1-sourabhjain@linux.ibm.com Signed-off-by: Sasha Levin commit b179ecd7959493e69534a67e925f74aa1b32ed57 Author: Kirill A. Shutemov Date: Mon Nov 4 12:38:02 2024 +0200 x86/tdx: Dynamically disable SEPT violations from causing #VEs [ Upstream commit f65aa0ad79fca4ace921da0701644f020129043d ] Memory access #VEs are hard for Linux to handle in contexts like the entry code or NMIs. But other OSes need them for functionality. There's a static (pre-guest-boot) way for a VMM to choose one or the other. But VMMs don't always know which OS they are booting, so they choose to deliver those #VEs so the "other" OSes will work. That, unfortunately has left us in the lurch and exposed to these hard-to-handle #VEs. The TDX module has introduced a new feature. Even if the static configuration is set to "send nasty #VEs", the kernel can dynamically request that they be disabled. Once they are disabled, access to private memory that is not in the Mapped state in the Secure-EPT (SEPT) will result in an exit to the VMM rather than injecting a #VE. Check if the feature is available and disable SEPT #VE if possible. If the TD is allowed to disable/enable SEPT #VEs, the ATTR_SEPT_VE_DISABLE attribute is no longer reliable. It reflects the initial state of the control for the TD, but it will not be updated if someone (e.g. bootloader) changes it before the kernel starts. Kernel must check TDCS_TD_CTLS bit to determine if SEPT #VEs are enabled or disabled. [ dhansen: remove 'return' at end of function ] Fixes: 373e715e31bf ("x86/tdx: Panic on bad configs that #VE on "private" memory access") Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Acked-by: Kai Huang Link: https://lore.kernel.org/all/20241104103803.195705-4-kirill.shutemov%40linux.intel.com Signed-off-by: Sasha Levin commit 4dda73c5cdf84af0098f2c60a74770dfb16df33f Author: Kirill A. Shutemov Date: Mon Nov 4 12:38:01 2024 +0200 x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup() [ Upstream commit b064043d9565786b385f85e6436ca5716bbd5552 ] Rename tdx_parse_tdinfo() to tdx_setup() and move setting NOTIFY_ENABLES there. The function will be extended to adjust TD configuration. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Kai Huang Link: https://lore.kernel.org/all/20241104103803.195705-3-kirill.shutemov%40linux.intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit 25b0ceef95aad3f1dbca475901325aec63e99dec Author: Kirill A. Shutemov Date: Mon Nov 4 12:38:00 2024 +0200 x86/tdx: Introduce wrappers to read and write TD metadata [ Upstream commit 5081e8fadb809253c911b349b01d87c5b4e3fec5 ] The TDG_VM_WR TDCALL is used to ask the TDX module to change some TD-specific VM configuration. There is currently only one user in the kernel of this TDCALL leaf. More will be added shortly. Refactor to make way for more users of TDG_VM_WR who will need to modify other TD configuration values. Add a wrapper for the TDG_VM_RD TDCALL that requests TD-specific metadata from the TDX module. There are currently no users for TDG_VM_RD. Mark it as __maybe_unused until the first user appears. This is preparation for enumeration and enabling optional TD features. Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Link: https://lore.kernel.org/all/20241104103803.195705-2-kirill.shutemov%40linux.intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit c9161e718262f801fc6d639f12ca67ba860fa58e Author: Bart Van Assche Date: Wed Oct 30 15:03:10 2024 -0700 scsi: sg: Enable runtime power management [ Upstream commit 4045de893f691f75193c606aec440c365cf7a7be ] In 2010, runtime power management support was implemented in the SCSI core. The description of patch "[SCSI] implement runtime Power Management" mentions that the sg driver is skipped but not why. This patch enables runtime power management even if an instance of the sg driver is held open. Enabling runtime PM for the sg driver is safe because all interactions of the sg driver with the SCSI device pass through the block layer (blk_execute_rq_nowait()) and the block layer already supports runtime PM. Cc: Alan Stern Cc: Douglas Gilbert Fixes: bc4f24014de5 ("[SCSI] implement runtime Power Management") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20241030220310.1373569-1-bvanassche@acm.org Acked-by: Alan Stern Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cfc76acaf2c4b43d1e140f1e4cbde15adb540bc5 Author: Zhen Lei Date: Sat Oct 26 20:57:11 2024 +0800 scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() [ Upstream commit 95bbdca4999bc59a72ebab01663d421d6ce5775d ] Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20241026125711.484-3-thunder.leizhen@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0e04bd5a11dffe8c1c0e4c9fc79f7d3cd6182dd5 Author: Zhen Lei Date: Sat Oct 26 20:57:10 2024 +0800 scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() [ Upstream commit c62c30429db3eb4ced35c7fcf6f04a61ce3a01bb ] Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20241026125711.484-2-thunder.leizhen@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a3fc624548c1f49cc255aa3555d88d0e7cc77076 Author: Zeng Heng Date: Thu Oct 24 16:44:17 2024 +0800 scsi: fusion: Remove unused variable 'rc' [ Upstream commit bd65694223f7ad11c790ab63ad1af87a771192ee ] The return value of scsi_device_reprobe() is currently ignored in _scsih_reprobe_lun(). Fixing the calling code to deal with the potential error is non-trivial, so for now just WARN_ON(). The handling of scsi_device_reprobe()'s return value refers to _scsih_reprobe_lun() and the following link: https://lore.kernel.org/all/094fdbf57487af4f395238c0525b2a560c8f68f0.1469766027.git.calvinowens@fb.com/ Fixes: f99be43b3024 ("[SCSI] fusion: power pc and miscellaneous bug fixs") Signed-off-by: Zeng Heng Link: https://lore.kernel.org/r/20241024084417.154655-1-zengheng4@huawei.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1ffdde30a90bf8efe8f270407f486706962b3292 Author: Ye Bin Date: Wed Oct 23 09:18:09 2024 +0800 scsi: bfa: Fix use-after-free in bfad_im_module_exit() [ Upstream commit 178b8f38932d635e90f5f0e9af1986c6f4a89271 ] BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed. Fixes: 7725ccfda597 ("[SCSI] bfa: Brocade BFA FC SCSI driver") Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20241023011809.63466-1-yebin@huaweicloud.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3c8ecbaa39f8e81044b8c107ac6cd5338b760bc7 Author: Baolin Liu Date: Wed Oct 30 10:18:00 2024 +0800 scsi: target: Fix incorrect function name in pscsi_create_type_disk() [ Upstream commit da5aeca99dd0b6c7bf6679382756ea6bda195f72 ] In pr_err(), bdev_open_by_path() should be renamed to bdev_file_open_by_path() Fixes: 034f0cf8fdf9 ("target: port block device access to file") Signed-off-by: Baolin Liu Link: https://lore.kernel.org/r/20241030021800.234980-1-liubaolin12138@163.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit be482f550a9cbaf4e8912dcfa3de52fe38b01162 Author: Mirsad Todorovac Date: Tue Oct 29 06:46:52 2024 +0100 fs/proc/kcore.c: fix coccinelle reported ERROR instances [ Upstream commit 82e33f249f1126cf3c5f39a31b850d485ac33bc3 ] Coccinelle complains about the nested reuse of the pointer `iter' with different pointer type: ./fs/proc/kcore.c:515:26-30: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:534:23-27: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:550:40-44: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:568:27-31: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:581:28-32: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:599:27-31: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:607:38-42: ERROR: invalid reference to the index variable of the iterator on line 499 ./fs/proc/kcore.c:614:26-30: ERROR: invalid reference to the index variable of the iterator on line 499 Replacing `struct kcore_list *iter' with `struct kcore_list *tmp' doesn't change the scope and the functionality is the same and coccinelle seems happy. NOTE: There was an issue with using `struct kcore_list *pos' as the nested iterator. The build did not work! [akpm@linux-foundation.org: s/tmp/pos/] Link: https://lkml.kernel.org/r/20241029054651.86356-2-mtodorovac69@gmail.com Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Link: https://lkml.kernel.org/r/20220331223700.902556-1-jakobkoschel@gmail.com Fixes: 04d168c6d42d ("fs/proc/kcore.c: remove check of list iterator against head past the loop body") Signed-off-by: Jakob Koschel Signed-off-by: Mirsad Todorovac Cc: Mike Rapoport Cc: David Hildenbrand Cc: Oscar Salvador Cc: "Brian Johannesmeyer" Cc: Cristiano Giuffrida Cc: "Bos, H.J." Cc: Alexey Dobriyan Cc: Andrew Morton Cc: Yang Li Cc: Baoquan He Cc: Hari Bathini Cc: Yan Zhen Cc: Alexander Gordeev Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 0cd2384e617f88513c5e1937a3f5a3031e47ce17 Author: Raymond Hackley Date: Sun Nov 3 08:35:16 2024 +0000 leds: ktd2692: Set missing timing properties [ Upstream commit 95c65546f03f888481eda98b499947252e1f3b20 ] props.timing is not set after commit b5a8c50e5c18 ("leds: ktd2692: Convert to use ExpressWire library"). Set it with ktd2692_timing. Fixes: b5a8c50e5c18 ("leds: ktd2692: Convert to use ExpressWire library") Signed-off-by: Raymond Hackley Acked-by: Duje Mihanović Link: https://lore.kernel.org/r/20241103083505.49648-1-raymondhackley@protonmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 072d5a70e5767dc6c89eae6ea143cc5480cc83a0 Author: Javier Carrasco Date: Thu Oct 31 17:30:30 2024 +0100 leds: max5970: Fix unreleased fwnode_handle in probe function [ Upstream commit 02f58f97419c828f58e30f24f54395ac9be159c0 ] An object initialized via device_get_named_child_node() requires calls to fwnode_handle_put() when it is no longer required to avoid leaking memory. Add the automatic cleanup facility for 'led_node' to ensure that fwnode_handle_put() is called in all execution paths. Fixes: 736214b4b02a ("leds: max5970: Add support for max5970") Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20241031-max5970-of_node_put-v2-1-0ffe1f1d3bc9@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b46f0aff25a378bc8917b902d141335e92eb5b46 Author: Zhang Changzhong Date: Wed Oct 30 23:41:06 2024 +0800 mfd: rt5033: Fix missing regmap_del_irq_chip() [ Upstream commit d256d612f47529ed0b332298e2d5ea981a4dd5b8 ] Fix missing call to regmap_del_irq_chip() in error handling path by using devm_regmap_add_irq_chip(). Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1730302867-8391-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e4b649c0a5c7097b93d0411f2733866833011a72 Author: Tamir Duberstein Date: Fri Oct 25 19:43:19 2024 -0400 checkpatch: always parse orig_commit in fixes tag [ Upstream commit 2f07b652384969f5d0b317e1daa5f2eb967bc73d ] Do not require the presence of `$balanced_parens` to get the commit SHA; this allows a `Fixes: deadbeef` tag to get a correct suggestion rather than a suggestion containing a reference to HEAD. Given this patch: : From: Tamir Duberstein : Subject: Test patch : Date: Fri, 25 Oct 2024 19:30:51 -0400 : : This is a test patch. : : Fixes: bd17e036b495 : Signed-off-by: Tamir Duberstein : --- /dev/null : +++ b/new-file : @@ -0,0 +1 @@ : +Test. Before: WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("")' - ie: 'Fixes: c10a7d25e68f ("Test patch")' After: WARNING: Please use correct Fixes: style 'Fixes: <12 chars of sha1> ("<title line>")' - ie: 'Fixes: bd17e036b495 ("checkpatch: warn for non-standard fixes tag style")' The prior behavior incorrectly suggested the patch's own SHA and title line rather than the referenced commit's. This fixes that. Ironically this: Fixes: bd17e036b495 ("checkpatch: warn for non-standard fixes tag style") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Louis Peens <louis.peens@corigine.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6a47c4e733a39fd374d7ead64bf7e77c93c065f3 Author: Zhenzhong Duan <zhenzhong.duan@intel.com> Date: Mon Nov 4 09:40:33 2024 +0800 iommu/vt-d: Fix checks and print in pgtable_walk() [ Upstream commit f1645676f25d2c846798f0233c3a953efd62aafb ] There are some issues in pgtable_walk(): 1. Super page is dumped as non-present page 2. dma_pte_superpage() should not check against leaf page table entries 3. Pointer pte is never NULL so checking it is meaningless 4. When an entry is not present, it still makes sense to dump the entry content. Fix 1,2 by checking dma_pte_superpage()'s returned value after level check. Fix 3 by removing pte check. Fix 4 by checking present bit after printing. By this chance, change to print "page table not present" instead of "PTE not present" to be clearer. Fixes: 914ff7719e8a ("iommu/vt-d: Dump DMAR translation structure when DMA fault occurs") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Link: https://lore.kernel.org/r/20241024092146.715063-3-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 05927faec7a2416627cbc54d3a510ecb34ac8abe Author: Zhenzhong Duan <zhenzhong.duan@intel.com> Date: Mon Nov 4 09:40:32 2024 +0800 iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes() [ Upstream commit 6ceb93f952f6ca34823ce3650c902c31b8385b40 ] There are some issues in dmar_fault_dump_ptes(): 1. return value of phys_to_virt() is used for checking if an entry is present. 2. dump is confusing, e.g., "pasid table entry is not present", confusing by unpresent pasid table vs. unpresent pasid table entry. Current code means the former. 3. pgtable_walk() is called without checking if page table is present. Fix 1 by checking present bit of an entry before dump a lower level entry. Fix 2 by removing "entry" string, e.g., "pasid table is not present". Fix 3 by checking page table present before walk. Take issue 3 for example, before fix: [ 442.240357] DMAR: pasid dir entry: 0x000000012c83e001 [ 442.246661] DMAR: pasid table entry[0]: 0x0000000000000000 [ 442.253429] DMAR: pasid table entry[1]: 0x0000000000000000 [ 442.260203] DMAR: pasid table entry[2]: 0x0000000000000000 [ 442.266969] DMAR: pasid table entry[3]: 0x0000000000000000 [ 442.273733] DMAR: pasid table entry[4]: 0x0000000000000000 [ 442.280479] DMAR: pasid table entry[5]: 0x0000000000000000 [ 442.287234] DMAR: pasid table entry[6]: 0x0000000000000000 [ 442.293989] DMAR: pasid table entry[7]: 0x0000000000000000 [ 442.300742] DMAR: PTE not present at level 2 After fix: ... [ 357.241214] DMAR: pasid table entry[6]: 0x0000000000000000 [ 357.248022] DMAR: pasid table entry[7]: 0x0000000000000000 [ 357.254824] DMAR: scalable mode page table is not present Fixes: 914ff7719e8a ("iommu/vt-d: Dump DMAR translation structure when DMA fault occurs") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Link: https://lore.kernel.org/r/20241024092146.715063-2-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e15798a7bb7d5241908af94715042b18e288f95e Author: Yang Yingliang <yangyingliang@huawei.com> Date: Sat Oct 26 19:24:52 2024 +0800 clk: imx: imx8-acm: Fix return value check in clk_imx_acm_attach_pm_domains() [ Upstream commit 81a206d736c19139d3863b79e7174f9e98b45499 ] If device_link_add() fails, it returns NULL pointer not ERR_PTR(), replace IS_ERR() with NULL pointer check, and return -EINVAL. Fixes: d3a0946d7ac9 ("clk: imx: imx8: add audio clock mux driver") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241026112452.1523-1-yangyingliang@huaweicloud.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit af0e16ff97375de06e6dbb70dc14e507541e0883 Author: Dong Aisheng <aisheng.dong@nxp.com> Date: Sun Oct 27 20:00:10 2024 +0800 clk: imx: clk-scu: fix clk enable state save and restore [ Upstream commit e81361f6cf9bf4a1848b0813bc4becb2250870b8 ] The scu clk_ops only inplements prepare() and unprepare() callback. Saving the clock state during suspend by checking clk_hw_is_enabled() is not safe as it's possible that some device drivers may only disable the clocks without unprepare. Then the state retention will not work for such clocks. Fixing it by checking clk_hw_is_prepared() which is more reasonable and safe. Fixes: d0409631f466 ("clk: imx: scu: add suspend/resume support") Reviewed-by: Peng Fan <peng.fan@nxp.com> Tested-by: Carlos Song <carlos.song@nxp.com> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-4-89152574d1d7@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c5052c5f8883e8f43308ad912ce3930e0fc5e76b Author: Peng Fan <peng.fan@nxp.com> Date: Sun Oct 27 20:00:09 2024 +0800 clk: imx: fracn-gppll: fix pll power up [ Upstream commit ff4279618f0aec350b0fb41b2b35841324fbd96e ] To i.MX93 which features dual Cortex-A55 cores and DSU, when using writel_relaxed to write value to PLL registers, the value might be buffered. To make sure the value has been written into the hardware, using readl to read back the register could achieve the goal. current PLL power up flow can be simplified as below: 1. writel_relaxed to set the PLL POWERUP bit; 2. readl_poll_timeout to check the PLL lock bit: a). timeout = ktime_add_us(ktime_get(), timeout_us); b). readl the pll the lock reg; c). check if the pll lock bit ready d). check if timeout But in some corner cases, both the write in step 1 and read in step 2 will be blocked by other bus transaction in the SoC for a long time, saying the value into real hardware is just before step b). That means the timeout counting has begins for quite sometime since step a), but value still not written into real hardware until bus released just at a point before step b). Then there maybe chances that the pll lock bit is not ready when readl done but the timeout happens. readl_poll_timeout will err return due to timeout. To avoid such unexpected failure, read back the reg to make sure the write has been done in HW reg. So use readl after writel_relaxed to fix the issue. Since we are here, to avoid udelay to run before writel_relaxed, use readl before udelay. Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll") Co-developed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-3-89152574d1d7@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 31daf0bc57906699e058dadd44b57a565a92eec5 Author: Peng Fan <peng.fan@nxp.com> Date: Sun Oct 27 20:00:08 2024 +0800 clk: imx: fracn-gppll: correct PLL initialization flow [ Upstream commit 557be501c38e1864b948fc6ccdf4b035d610a2ea ] Per i.MX93 Reference Mannual 22.4 Initialization information 1. Program appropriate value of DIV[ODIV], DIV[RDIV] and DIV[MFI] as per Integer mode. 2. Wait for 5 μs. 3. Program the following field in CTRL register. Set CTRL[POWERUP] to 1'b1 to enable PLL block. 4. Poll PLL_STATUS[PLL_LOCK] register, and wait till PLL_STATUS[PLL_LOCK] is 1'b1 and pll_lock output signal is 1'b1. 5. Set CTRL[CLKMUX_EN] to 1'b1 to enable PLL output clock. So move the CLKMUX_EN operation after PLL locked. Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll") Co-developed-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-2-89152574d1d7@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit aa9fb1422f04696cd5844e6ac8640c4638c164e5 Author: Peng Fan <peng.fan@nxp.com> Date: Sun Oct 27 20:00:07 2024 +0800 clk: imx: lpcg-scu: SW workaround for errata (e10858) [ Upstream commit 5ee063fac85656bea9cfe3570af147ba1701ba18 ] Back-to-back LPCG writes can be ignored by the LPCG register due to a HW bug. The writes need to be separated by at least 4 cycles of the gated clock. See https://www.nxp.com.cn/docs/en/errata/IMX8_1N94W.pdf The workaround is implemented as follows: 1. For clocks running greater than or equal to 24MHz, a read followed by the write will provide sufficient delay. 2. For clocks running below 24MHz, add a delay of 4 clock cylces after the write to the LPCG register. Fixes: 2f77296d3df9 ("clk: imx: add lpcg clock support") Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241027-imx-clk-v1-v3-1-89152574d1d7@nxp.com Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3c49e1084a5df99807fc43dd318c491e6cbaa168 Author: Björn Töpel <bjorn@rivosinc.com> Date: Mon Nov 4 20:15:01 2024 +0100 riscv: kvm: Fix out-of-bounds array access [ Upstream commit 332fa4a802b16ccb727199da685294f85f9880cb ] In kvm_riscv_vcpu_sbi_init() the entry->ext_idx can contain an out-of-bound index. This is used as a special marker for the base extensions, that cannot be disabled. However, when traversing the extensions, that special marker is not checked prior indexing the array. Add an out-of-bounds check to the function. Fixes: 56d8a385b605 ("RISC-V: KVM: Allow some SBI extensions to be disabled by default") Signed-off-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20241104191503.74725-1-bjorn@kernel.org Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 28ab9e4369a0374cf037edaa148f391c510fd776 Author: Yong-Xuan Wang <yongxuan.wang@sifive.com> Date: Tue Oct 29 16:55:39 2024 +0800 RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation [ Upstream commit 60821fb4dd7345e5662094accf0a52845306de8c ] In the section "4.7 Precise effects on interrupt-pending bits" of the RISC-V AIA specification defines that: "If the source mode is Level1 or Level0 and the interrupt domain is configured in MSI delivery mode (domaincfg.DM = 1): The pending bit is cleared whenever the rectified input value is low, when the interrupt is forwarded by MSI, or by a relevant write to an in_clrip register or to clripnum." Update the aplic_write_pending() to match the spec. Fixes: d8dd9f113e16 ("RISC-V: KVM: Fix APLIC setipnum_le/be write emulation") Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20241029085542.30541-1-yongxuan.wang@sifive.com Signed-off-by: Anup Patel <anup@brainfault.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 67e5afd89cc9711128d94817ff0884c81aaf795c Author: Liu Jian <liujian56@huawei.com> Date: Thu Oct 31 17:20:19 2024 +0800 RDMA/rxe: Set queue pair cur_qp_state when being queried [ Upstream commit 775e6d3c8fda41083b16c26d05163fd69f029a62 ] Same with commit e375b9c92985 ("RDMA/cxgb4: Set queue pair state when being queried"). The API for ib_query_qp requires the driver to set cur_qp_state on return, add the missing set. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Liu Jian <liujian56@huawei.com> Link: https://patch.msgid.link/20241031092019.2138467-1-liujian56@huawei.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 42784a37b290dba40d9ce3c26dd5ce5d72c58407 Author: Biju Das <biju.das.jz@bp.renesas.com> Date: Thu Oct 24 14:42:11 2024 +0100 clk: renesas: rzg2l: Fix FOUTPOSTDIV clk [ Upstream commit dabf72b85f298970e86891b5218459c17b57b26a ] While computing foutpostdiv_rate, the value of params->pl5_fracin is discarded, which results in the wrong refresh rate. Fix the formula for computing foutpostdiv_rate. Fixes: 1561380ee72f ("clk: renesas: rzg2l: Add FOUTPOSTDIV clk support") Signed-off-by: Hien Huynh <hien.huynh.px@renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20241024134236.315289-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> commit db8abd60150ec0d7afb739ce60bd82a31b90a265 Author: Andre Przywara <andre.przywara@arm.com> Date: Tue Oct 1 11:50:16 2024 +0100 clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset [ Upstream commit e0f253a52ccee3cf3eb987e99756e20c68a1aac9 ] To work around a limitation in our clock modelling, we try to force two bits in the AUDIO0 PLL to 0, in the CCU probe routine. However the ~ operator only applies to the first expression, and does not cover the second bit, so we end up clearing only bit 1. Group the bit-ORing with parentheses, to make it both clearer to read and actually correct. Fixes: 35b97bb94111 ("clk: sunxi-ng: Add support for the D1 SoC clocks") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20241001105016.1068558-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ee31de294ec86a2ddd1d15fd957fb98cb9c18764 Author: Kashyap Desai <kashyap.desai@broadcom.com> Date: Mon Oct 28 03:06:54 2024 -0700 RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey [ Upstream commit 808ca6de989c598bc5af1ae0ad971a66077efac0 ] Invalidate rkey is cpu endian and immediate data is in big endian format. Both immediate data and invalidate the remote key returned by HW is in little endian format. While handling the commit in fixes tag, the difference between immediate data and invalidate rkey endianness was not considered. Without changes of this patch, Kernel ULP was failing while processing inv_rkey. dmesg log snippet - nvme nvme0: Bogus remote invalidation for rkey 0x2000019Fix in this patch Do endianness conversion based on completion queue entry flag. Also, the HW completions are already converted to host endianness in bnxt_qplib_cq_process_res_rc and bnxt_qplib_cq_process_res_ud and there is no need to convert it again in bnxt_re_poll_cq. Modified the union to hold the correct data type. Fixes: 95b087f87b78 ("bnxt_re: Fix imm_data endianness") Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1730110014-20755-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e4f26fae6075f136616d12a369b0ef7f0cf16436 Author: Zhu Yanjun <yanjun.zhu@linux.dev> Date: Fri Oct 25 17:20:36 2024 +0200 RDMA/rxe: Fix the qp flush warnings in req [ Upstream commit ea4c990fa9e19ffef0648e40c566b94ba5ab31be ] When the qp is in error state, the status of WQEs in the queue should be set to error. Or else the following will appear. [ 920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G O 6.1.113-storage+ #65 [ 920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Call Trace: [ 920.623815] <TASK> [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.624356] ? report_bug+0xfb/0x150 [ 920.624594] ? handle_bug+0x3c/0x60 [ 920.624796] ? exc_invalid_op+0x14/0x70 [ 920.624976] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.625474] ? rxe_completer+0x329/0xcc0 [rdma_rxe] [ 920.625749] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.626037] rxe_requester+0x625/0xde0 [rdma_rxe] [ 920.626310] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [ 920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? sort_range+0x20/0x20 [ 920.627942] run_ksoftirqd+0x1f/0x30 [ 920.628158] smpboot_thread_fn+0xc7/0x1b0 [ 920.628334] kthread+0xd6/0x100 [ 920.628504] ? kthread_complete_and_exit+0x20/0x20 [ 920.628709] ret_from_fork+0x1f/0x30 [ 920.628892] </TASK> Fixes: ae720bdb703b ("RDMA/rxe: Generate error completion for error requester QP state") Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev> Link: https://patch.msgid.link/20241025152036.121417-1-yanjun.zhu@linux.dev Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a0e4c78770faa0d56d47391476fe1d827e72eded Author: wenglianfa <wenglianfa@huawei.com> Date: Thu Oct 24 20:40:00 2024 +0800 RDMA/hns: Fix cpu stuck caused by printings during reset [ Upstream commit 323275ac2ff15b2b7b3eac391ae5d8c5a3c3a999 ] During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Fixes: c7bcb13442e1 ("RDMA/hns: Add SRQ support for hip08 kernel mode") Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT") Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Signed-off-by: wenglianfa <wenglianfa@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20241024124000.2931869-6-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b29a038f4d22fa2d592afce2f3eb3383764b4a43 Author: Junxian Huang <huangjunxian6@hisilicon.com> Date: Thu Oct 24 20:39:59 2024 +0800 RDMA/hns: Use dev_* printings in hem code instead of ibdev_* [ Upstream commit d81fb6511abf18591befaa5f4a972ffc838690ec ] The hem code is executed before ib_dev is registered, so use dev_* printing instead of ibdev_* to avoid log like this: (null): set HEM address to HW failed! Fixes: 2f49de21f3e9 ("RDMA/hns: Optimize mhop get flow for multi-hop addressing") Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20241024124000.2931869-5-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bbfa1c3e757ad2045adfebcc482def2394f4d2a0 Author: Yuyu Li <liyuyu6@huawei.com> Date: Thu Oct 24 20:39:58 2024 +0800 RDMA/hns: Modify debugfs name [ Upstream commit 370a9351bf84afc5a56a3f02ba3805bbfcb53c32 ] The sub-directory of hns_roce debugfs is named after the device's kernel name currently, but it will be inconvenient to use when the device is renamed. Modify the name to pci name as users can always easily find the correspondence between an RDMA device and its pci name. Fixes: eb7854d63db5 ("RDMA/hns: Support SW stats with debugfs") Signed-off-by: Yuyu Li <liyuyu6@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20241024124000.2931869-4-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ecb595fbc12c49155dee3d958b4dc612b2a8e8bb Author: wenglianfa <wenglianfa@huawei.com> Date: Thu Oct 24 20:39:57 2024 +0800 RDMA/hns: Fix flush cqe error when racing with destroy qp [ Upstream commit 377a2097705b915325a67e4d44f9f2844e567809 ] QP needs to be modified to IB_QPS_ERROR to trigger HW flush cqe. But when this process races with destroy qp, the destroy-qp process may modify the QP to IB_QPS_RESET first. In this case flush cqe will fail since it is invalid to modify qp from IB_QPS_RESET to IB_QPS_ERROR. Add lock and bit flag to make sure pending flush cqe work is completed first and no more new works will be added. Fixes: ffd541d45726 ("RDMA/hns: Add the workqueue framework for flush cqe handler") Signed-off-by: wenglianfa <wenglianfa@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20241024124000.2931869-3-huangjunxian6@hisilicon.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 68278ab1279b4757919f02ca89da974b16cd5ed1 Author: wenglianfa <wenglianfa@huawei.com> Date: Thu Oct 24 20:39:56 2024 +0800 RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci [ Upstream commit 571e4ab8a45e530623ab129803f090a844dd3fe9 ] eq_db_ci is updated only after all AEQEs are processed in the AEQ interrupt handler, which is not timely enough and may result in AEQ overflow. Two optimization methods are proposed: 1. Set an upper limit for AEQE processing. 2. Move time-consuming operations such as printings to the bottom half of the interrupt. cmd events and flush_cqe events are still fully processed in the top half to ensure timely handling. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Signed-off-by: wenglianfa <wenglianfa@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20241024124000.2931869-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 96236b5a0913c4a41149c7734607da477e2d2030 Author: Vasant Hegde <vasant.hegde@amd.com> Date: Wed Oct 30 06:35:45 2024 +0000 iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB [ Upstream commit 016991606aa01c4d92e6941be636c0c897aa05c7 ] Commit c7fc12354be0 ("iommu/amd/pgtbl_v2: Invalidate updated page ranges only") missed to take domain lock before calling amd_iommu_domain_flush_pages(). Fix this by taking protection domain lock before calling TLB invalidation function. Fixes: c7fc12354be0 ("iommu/amd/pgtbl_v2: Invalidate updated page ranges only") Signed-off-by: Vasant Hegde <vasant.hegde@amd.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20241030063556.6104-2-vasant.hegde@amd.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4a72d8f159864e324a5e7be4cb73a99eb5a9b9b6 Author: Jason Gunthorpe <jgg@ziepe.ca> Date: Thu Aug 29 21:06:18 2024 -0300 iommu/amd: Narrow the use of struct protection_domain to invalidation [ Upstream commit 9ac0b3380acdece01fa1b361687e3cd988831c55 ] The AMD io_pgtable stuff doesn't implement the tlb ops callbacks, instead it invokes the invalidation ops directly on the struct protection_domain. Narrow the use of struct protection_domain to only those few code paths. Make everything else properly use struct amd_io_pgtable through the call chains, which is the correct modular type for an io-pgtable module. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/9-v2-831cdc4d00f3+1a315-amd_iopgtbl_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Stable-dep-of: 016991606aa0 ("iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB") Signed-off-by: Sasha Levin <sashal@kernel.org> commit bbd92f5b718618c888d945b883e6bdac4ca97852 Author: Jason Gunthorpe <jgg@ziepe.ca> Date: Thu Aug 29 21:06:17 2024 -0300 iommu/amd: Store the nid in io_pgtable_cfg instead of the domain [ Upstream commit 47f218d108950984b24af81f66356ceda380eb74 ] We already have memory in the union here that is being wasted in AMD's case, use it to store the nid. Putting the nid here further isolates the io_pgtable code from the struct protection_domain. Fixup protection_domain_alloc so that the NID from the device is provided, at this point dev is never NULL for AMD so this will now allocate the first table pointer on the correct NUMA node. Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Link: https://lore.kernel.org/r/8-v2-831cdc4d00f3+1a315-amd_iopgtbl_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Stable-dep-of: 016991606aa0 ("iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5be80f0119ea46f44331453c0a03bd22c4b456fc Author: Jason Gunthorpe <jgg@ziepe.ca> Date: Thu Aug 29 21:06:15 2024 -0300 iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl [ Upstream commit 670b57796c5dc1ca58912132cad914cf4b3c0cdd ] There is struct protection_domain iopt and struct amd_io_pgtable iopt. Next patches are going to want to write domain.iopt.iopt.xx which is quite unnatural to read. Give one of them a different name, amd_io_pgtable has fewer references so call it pgtbl, to match pgtbl_cfg, instead. Suggested-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/6-v2-831cdc4d00f3+1a315-amd_iopgtbl_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Stable-dep-of: 016991606aa0 ("iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1a5c61f4e2a3f4107bb17e5749e1cb608d7148b8 Author: Jason Gunthorpe <jgg@ziepe.ca> Date: Thu Aug 29 21:06:14 2024 -0300 iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related [ Upstream commit 1ed2d21d471caf2e4351c2e8bb14143bc8062092 ] Looks like many refactorings here have left this confused. There is only one storage of the root/mode, it is in the iop struct. increase_address_space() calls amd_iommu_domain_set_pgtable() with values that it already stored in iop a few lines above. amd_iommu_domain_clr_pt_root() is zero'ing memory we are about to free. It used to protect against a double free of root, but that is gone now. Remove amd_iommu_domain_set_pgtable(), amd_iommu_domain_set_pt_root(), amd_iommu_domain_clr_pt_root() as they are all pointless. Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/5-v2-831cdc4d00f3+1a315-amd_iopgtbl_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Stable-dep-of: 016991606aa0 ("iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 259999ac41558c91425914e61a78784ddf811bc4 Author: Jason Gunthorpe <jgg@ziepe.ca> Date: Thu Aug 29 21:06:13 2024 -0300 iommu/amd: Remove amd_iommu_domain_update() from page table freeing [ Upstream commit 322d889ae7d39f8538a6deac35869aa3be1855bd ] It is a serious bug if the domain is still mapped to any DTEs when it is freed as we immediately start freeing page table memory, so any remaining HW touch will UAF. If it is not mapped then dev_list is empty and amd_iommu_domain_update() does nothing. Remove it and add a WARN_ON() to catch this class of bug. Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/4-v2-831cdc4d00f3+1a315-amd_iopgtbl_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Stable-dep-of: 016991606aa0 ("iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB") Signed-off-by: Sasha Levin <sashal@kernel.org> commit afd22d9839359829776abb55cc9bc4946e888704 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Wed Oct 30 16:24:49 2024 +0800 cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost() [ Upstream commit 1a1374bb8c5926674973d849feed500bc61ad535 ] cpufreq_cpu_get_raw() may return NULL if the cpu is not in policy->cpus cpu mask and it will cause null pointer dereference, so check NULL for cppc_get_cpu_cost(). Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e9b39f1924b76abc18881e4ce899fb232dd23d12 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Wed Oct 30 09:20:19 2024 +0800 cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw() [ Upstream commit a78e7207564258db6e373e86294a85f9d646d35a ] cpufreq_cpu_get_raw() may return NULL if the cpu is not in policy->cpus cpu mask and it will cause null pointer dereference. Fixes: 740fcdc2c20e ("cpufreq: CPPC: Register EM based on efficiency class information") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b125d0cf1adde7b2b47d7337fed7e9133eea3463 Author: Michael Ellerman <mpe@ellerman.id.au> Date: Mon Aug 19 22:24:01 2024 +1000 powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore [ Upstream commit cadae3a45d23aa4f6485938a67cbc47aaaa25e38 ] The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258 Fixes: 06220d78f24a ("powerpc/pseries: Introduce rwlock to gatekeep DTLB usage") Tested-by: Kajol Jain <kjain@linux.ibm.com> Reviewed-by: Nysal Jan K.A <nysal@linux.ibm.com> Reviewed-by: Kajol Jain <kjain@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20240819122401.513203-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4877e9748330e86a2b3f76d9e67562c72c7b4b35 Author: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Date: Wed Oct 16 09:08:37 2024 +0900 mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in RD_ANY_REG_OP [ Upstream commit b61c35e3404557779ec427c077f7a9f057bb053d ] In octal DTR mode, RD_ANY_REG_OP needs to use 4-byte address regardless of flash's internal address mode. Use nor->addr_nbytes which is set to 4 during setup. Fixes: eff9604390d6 ("mtd: spi-nor: spansion: add octal DTR support in RD_ANY_REG_OP") Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com> Link: https://lore.kernel.org/r/20241016000837.17951-1-Takahiro.Kuwano@infineon.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2ef40da22da3d49ad532ffe4f1e442ff350eadf5 Author: Zichen Xie <zichenxie0106@gmail.com> Date: Wed Oct 23 09:51:47 2024 -0500 clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate() [ Upstream commit 00f8f70a0e8c6601861628be26270a0b6f4bbb34 ] This was found by a static analyzer. There may be a potential integer overflow issue in sg2042_pll_recalc_rate(). numerator is defined as u64 while parent_rate is defined as unsigned long and ctrl_table.fbdiv is defined as unsigned int. On 32-bit machine, the result of the calculation will be limited to "u32" without correct casting. Integer overflow may occur on high-performance systems. Fixes: 48cf7e01386e ("clk: sophgo: Add SG2042 clock driver") Signed-off-by: Zichen Xie <zichenxie0106@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/20241023145146.13130-1-zichenxie0106@gmail.com Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7eaeb7a49b6d16640f9f3c9074c05175d74c710b Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Date: Fri Oct 18 22:59:42 2024 +0530 powerpc/mm/fault: Fix kfence page fault reporting [ Upstream commit 06dbbb4d5f7126b6307ab807cbf04ecfc459b933 ] copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults. Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault(). This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M Some example false negatives: =============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec Fixes: 90cbac0e995d ("powerpc: Enable KFENCE for PPC32") Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reported-by: Disha Goel <disgoel@linux.ibm.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/a411788081d50e3b136c6270471e35aba3dfafa3.1729271995.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit bdd11a04d102f8310812aa7cec39545fdd6662d1 Author: Miquel Raynal <miquel.raynal@bootlin.com> Date: Tue Oct 1 22:31:49 2024 +0200 mtd: rawnand: atmel: Fix possible memory leak [ Upstream commit 6d734f1bfc336aaea91313a5632f2f197608fadd ] The pmecc "user" structure is allocated in atmel_pmecc_create_user() and was supposed to be freed with atmel_pmecc_destroy_user(), but this other helper is never called. One solution would be to find the proper location to call the destructor, but the trend today is to switch to device managed allocations, which in this case fits pretty well. Replace kzalloc() by devm_kzalloc() and drop the destructor entirely. Reported-by: "Dr. David Alan Gilbert" <linux@treblig.org> Closes: https://lore.kernel.org/all/ZvmIvRJCf6VhHvpo@gallifrey/ Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20241001203149.387655-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit aa54f88e68b17f1bba78b7fc62fe1973691a6179 Author: Biju Das <biju.das.jz@bp.renesas.com> Date: Wed Jul 31 09:08:40 2024 +0100 mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE [ Upstream commit 7d189579a287d5c568db623c5fc2344cce98a887 ] The rpc-if-hyperflash driver can be compiled as a module, but lacks MODULE_DEVICE_TABLE() and will therefore not be loaded automatically. Fix this. Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20240731080846.257139-1-biju.das.jz@bp.renesas.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit f551637fe9bf863386309e03f9d148d97f535ad1 Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Date: Fri Oct 18 21:47:57 2024 +0530 powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init() [ Upstream commit 05b94cae1c47f94588c3e7096963c1007c4d9c1d ] During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE, since pageblock_order is still zero and it gets initialized later during initmem_init() e.g. setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order() One such use case where this causes issue is - early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init() This causes CMA memory alignment check to be bypassed in cma_init_reserved_mem(). Then later cma_activate_area() can hit a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory area was not pageblock_order aligned. Fix it by moving the fadump_cma_init() after initmem_init(), where other such cma reservations also gets called. <stack trace> ============== page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010 flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) ------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:778! Call Trace: __free_one_page+0x57c/0x7b0 (unreliable) free_pcppages_bulk+0x1a8/0x2c8 free_unref_page_commit+0x3d4/0x4e4 free_unref_page+0x458/0x6d0 init_cma_reserved_pageblock+0x114/0x198 cma_init_reserved_areas+0x270/0x3e0 do_one_initcall+0x80/0x2f8 kernel_init_freeable+0x33c/0x530 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c Fixes: 11ac3e87ce09 ("mm: cma: use pageblock_order as the single alignment") Suggested-by: David Hildenbrand <david@redhat.com> Reported-by: Sachin P Bappalige <sachinpb@linux.ibm.com> Acked-by: Hari Bathini <hbathini@linux.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/3ae208e48c0d9cefe53d2dc4f593388067405b7d.1729146153.git.ritesh.list@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit c9fbc877776d6d6ae9c93fb71f3a8c317f9fe371 Author: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Date: Fri Oct 18 21:47:55 2024 +0530 powerpc/fadump: Refactor and prepare fadump_cma_init for late init [ Upstream commit adfaec30ffaceecd565e06adae367aa944acc3c9 ] We anyway don't use any return values from fadump_cma_init(). Since fadump_reserve_mem() from where fadump_cma_init() gets called today, already has the required checks. This patch makes this function return type as void. Let's also handle extra cases like return if fadump_supported is false or dump_active, so that in later patches we can call fadump_cma_init() separately from setup_arch(). Acked-by: Hari Bathini <hbathini@linux.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/a2afc3d6481a87a305e89cfc4a3f3d2a0b8ceab3.1729146153.git.ritesh.list@gmail.com Stable-dep-of: 05b94cae1c47 ("powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4c66cb21a691ddc953102c0189935a4501e7afc1 Author: Yuan Can <yuancan@huawei.com> Date: Wed Oct 16 17:06:15 2024 +0800 cpufreq: loongson2: Unregister platform_driver on failure [ Upstream commit 5f856d71ccdf89b4bac0ff70ebb0bb582e7f7f18 ] When cpufreq_register_driver() returns error, the cpufreq_init() returns without unregister platform_driver, fix by add missing platform_driver_unregister() when cpufreq_register_driver() failed. Fixes: f8ede0f700f5 ("MIPS: Loongson 2F: Add CPU frequency scaling support") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e135ff5a26710b6e6b82bf0708dc66c3d72eaede Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Sat Oct 5 22:27:07 2024 +0300 mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication [ Upstream commit 3727c0b4ff6ba0e61203544b4c831f7f8899753b ] For all of the devices regmap IRQ may try to created the folder with the same name which is impossible and fails with: debugfs: File '\_SB.IPC1.PMIC' in directory 'domains' already present! Add domain_suffix to all of the IRQ chips driver registers to solve the issue. Fixes: 39d047c0b1c8 ("mfd: add Intel Broxton Whiskey Cove PMIC driver") Fixes: 957ae5098185 ("platform/x86: Add Whiskey Cove PMIC TMU support") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Depends-on: dde286ee5770 ("regmap: Allow setting IRQ domain name suffix") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241005193029.1929139-5-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit fc8d8b7a3f08a2845a43bf17f8078becfa043ade Author: Matti Vaittinen <mazziesaccount@gmail.com> Date: Thu Aug 8 15:36:28 2024 +0300 regmap: Allow setting IRQ domain name suffix [ Upstream commit dde286ee57704226b500cb9eb59547fec07aad3d ] When multiple IRQ domains are created from the same device-tree node they will get the same name based on the device-tree path. This will cause a naming collision in debugFS when IRQ domain specific entries are created. The regmap-IRQ creates per instance IRQ domains. This will lead to a domain name conflict when a device which provides more than one interrupt line uses the regmap-IRQ. Add support for specifying an IRQ domain name suffix when creating a regmap-IRQ controller. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/776bc4996969e5081bcf61b9bdb5517e537147a3.1723120028.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 3727c0b4ff6b ("mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7fb3597a20e1edc702fc5e1571382a89a656f75b Author: Matti Vaittinen <mazziesaccount@gmail.com> Date: Thu Aug 8 22:23:06 2024 +0200 irqdomain: Allow giving name suffix for domain [ Upstream commit 1e7c05292531e5b6bebe409cd531ed4ec0b2ff56 ] Devices can provide multiple interrupt lines. One reason for this is that a device has multiple subfunctions, each providing its own interrupt line. Another reason is that a device can be designed to be used (also) on a system where some of the interrupts can be routed to another processor. A line often further acts as a demultiplex for specific interrupts and has it's respective set of interrupt (status, mask, ack, ...) registers. Regmap supports the handling of these registers and demultiplexing interrupts, but the interrupt domain code ends up assigning the same name for the per interrupt line domains. This causes a naming collision in the debugFS code and leads to confusion, as /proc/interrupts shows two separate interrupts with the same domain name and hardware interrupt number. Instead of adding a workaround in regmap or driver code, allow giving a name suffix for the domain name when the domain is created. Add a name_suffix field in the irq_domain_info structure and make irq_domain_instantiate() use this suffix if it is given when a domain is created. [ tglx: Adopt it to the cleanup patch and fixup the invalid NULL return ] Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/871q2yvk5x.ffs@tglx Stable-dep-of: 3727c0b4ff6b ("mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7b324f2b31d6d63f2261875e75934c7f27824556 Author: Thomas Gleixner <tglx@linutronix.de> Date: Thu Aug 8 22:19:41 2024 +0200 irqdomain: Cleanup domain name allocation [ Upstream commit 1bf2c92829274e7c815d06d7b3196a967ff70917 ] irq_domain_set_name() is truly unreadable gunk. Clean it up before adding more. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/all/874j7uvkbm.ffs@tglx Stable-dep-of: 3727c0b4ff6b ("mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 21fc558d84d5c24cc0a0dffd9ea56d06f62cd803 Author: Matti Vaittinen <mazziesaccount@gmail.com> Date: Thu Aug 8 15:34:02 2024 +0300 irqdomain: Simplify simple and legacy domain creation [ Upstream commit 70114e7f7585ef078c2b7033ee14218f95f55e22 ] irq_domain_create_simple() and irq_domain_create_legacy() use __irq_domain_instantiate(), but have extra handling of allocating interrupt descriptors and associating interrupts in them. Some of that is duplicated. There are also call sites which have conditonals to invoke different interrupt domain creator functions, where one of them is usually irq_domain_create_legacy(). Alternatively they associate the interrupts for the legacy case after creating the domain. Moving the extra logic of irq_domain_create_simple()/legacy() into __irq_domain_instantiate() allows to consolidate that. Introduce hwirq_base and virq_base members in the irq_domain_info structure, which allows to transport the required information and add the conditional interrupt descriptor allocation and interrupt association into __irq_domain_instantiate(). This reduces irq_domain_create_legacy() and irq_domain_create_simple() to trivial wrappers which fill in the info structure and allows call sites which must support the legacy case along with more modern mechanism to select the domain type via the parameters of the info struct. [ tglx: Massaged change log ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/32d07bd79eb2b5416e24da9e9e8fe5955423dcf9.1723120028.git.mazziesaccount@gmail.com Stable-dep-of: 3727c0b4ff6b ("mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 897713c9d24f6ec394585abfcf259a6e5cad22c8 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Sat Oct 5 22:27:06 2024 +0300 mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices [ Upstream commit 0350d783ab888cb1cb48ced36cc28b372723f1a4 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Tested-by: Zhang Ning <zhangn1985@outlook.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241005193029.1929139-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2310f5336f32eac9ada2d59b965d578efe25c4bf Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Sat Oct 5 22:27:05 2024 +0300 mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device [ Upstream commit 9b79d59e6b2b515eb9a22bc469ef7b8f0904fc73 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 957ae5098185 ("platform/x86: Add Whiskey Cove PMIC TMU support") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by: Zhang Ning <zhangn1985@outlook.com> Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by: Zhang Ning <zhangn1985@outlook.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241005193029.1929139-3-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 518e414d24e7037d6cc7198e942bf47fe6f5e8e1 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Sat Oct 5 22:27:04 2024 +0300 mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device [ Upstream commit 686fb77712a4bc94b76a0c5ae74c60118b7a0d79 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 9c6235c86332 ("mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device") Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by: Zhang Ning <zhangn1985@outlook.com> Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by: Zhang Ning <zhangn1985@outlook.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20241005193029.1929139-2-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7fd26c70eee0889b74bd9bc458a7fee01e8b0c26 Author: Marcus Folkesson <marcus.folkesson@gmail.com> Date: Wed Sep 25 12:19:53 2024 +0200 mfd: da9052-spi: Change read-mask to write-mask [ Upstream commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed ] Driver has mixed up the R/W bit. The LSB bit is set on write rather than read. Change it to avoid nasty things to happen. Fixes: e9e9d3973594 ("mfd: da9052: Avoid setting read_flag_mask for da9052-i2c driver") Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20240925-da9052-v2-1-f243e4505b07@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 83eb7270779d0343f00135ff600378463a850ce7 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Thu Sep 12 11:15:30 2024 +0800 mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race [ Upstream commit 2174f9a8c9db50f74df769edd5a4ab822c73b6d2 ] As the comment said, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 72cd799544f2 ("[PATCH] I2C: add i2c driver for TPS6501x") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20240912031530.2211654-1-ruanjinjie@huawei.com Signed-off-by: Lee Jones <lee@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 766c972d86d1675fba1a2a35a5fe67a5f2d31b95 Author: Christophe Leroy <christophe.leroy@csgroup.eu> Date: Thu Oct 10 00:17:57 2024 +0200 powerpc/vdso: Flag VDSO64 entry points as functions [ Upstream commit 0161bd38c24312853ed5ae9a425a1c41c4ac674a ] On powerpc64 as shown below by readelf, vDSO functions symbols have type NOTYPE. $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg ELF Header: Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: PowerPC64 Version: 0x1 ... Symbol table '.dynsym' contains 12 entries: Num: Value Size Type Bind Vis Ndx Name ... 1: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 ... 4: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 5: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __[...]@@LINUX_2.6.15 Symbol table '.symtab' contains 56 entries: Num: Value Size Type Bind Vis Ndx Name ... 45: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.15 46: 00000000000006c0 48 NOTYPE GLOBAL DEFAULT 8 __kernel_getcpu 47: 0000000000000524 84 NOTYPE GLOBAL DEFAULT 8 __kernel_clock_getres To overcome that, commit ba83b3239e65 ("selftests: vDSO: fix vDSO symbols lookup for powerpc64") was applied to have selftests also look for NOTYPE symbols, but the correct fix should be to flag VDSO entry points as functions. The original commit that brought VDSO support into powerpc/64 has the following explanation: Note that the symbols exposed by the vDSO aren't "normal" function symbols, apps can't be expected to link against them directly, the vDSO's are both seen as if they were linked at 0 and the symbols just contain offsets to the various functions. This is done on purpose to avoid a relocation step (ppc64 functions normally have descriptors with abs addresses in them). When glibc uses those functions, it's expected to use it's own trampolines that know how to reach them. The descriptors it's talking about are the OPD function descriptors used on ABI v1 (big endian). But it would be more correct for a text symbol to have type function, even if there's no function descriptor for it. glibc has a special case already for handling the VDSO symbols which creates a fake opd pointing at the kernel symbol. So changing the VDSO symbol type to function shouldn't affect that. For ABI v2, there is no function descriptors and VDSO functions can safely have function type. So lets flag VDSO entry points as functions and revert the selftest change. Link: https://github.com/mpe/linux-fullhistory/commit/5f2dd691b62da9d9cc54b938f8b29c22c93cb805 Fixes: ba83b3239e65 ("selftests: vDSO: fix vDSO symbols lookup for powerpc64") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-By: Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/b6ad2f1ee9887af3ca5ecade2a56f4acda517a85.1728512263.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7ac440b4b3e6ca1226f11370bf7d1ab67a7350d9 Author: Yihang Li <liyihang9@huawei.com> Date: Tue Oct 8 10:18:13 2024 +0800 scsi: hisi_sas: Enable all PHYs that are not disabled by user during controller reset [ Upstream commit 08a07dc71d7fc6f58c35c4fc0bcede2811c5aa4c ] For the controller reset operation(such as FLR or clear nexus ha in SCSI EH), we will disable all PHYs and then enable PHY based on the hisi_hba->phy_state obtained in hisi_sas_controller_reset_prepare(). If the device is removed before controller reset or the PHY is not attached to any device in directly attached scenario, the corresponding bit of phy_state is not set. After controller reset done, the PHY is disabled. The device cannot be identified even if user reconnect the disk. Therefore, for PHYs that are not disabled by user, hisi_sas_phy_enable() needs to be executed even if the corresponding bit of phy_state is not set. Fixes: 89954f024c3a ("scsi: hisi_sas: Ensure all enabled PHYs up during controller reset") Signed-off-by: Yihang Li <liyihang9@huawei.com> Link: https://lore.kernel.org/r/20241008021822.2617339-5-liyihang9@huawei.com Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3be34fa1cdbf180c1a948cfededfdf2cdc497199 Author: Matthew Rosato <mjrosato@linux.ibm.com> Date: Tue Sep 10 17:15:16 2024 -0400 iommu/s390: Implement blocking domain [ Upstream commit ecda483339a5151e3ca30d6b82691ef6f1d17912 ] This fixes a crash when surprise hot-unplugging a PCI device. This crash happens because during hot-unplug __iommu_group_set_domain_nofail() attaching the default domain fails when the platform no longer recognizes the device as it has already been removed and we end up with a NULL domain pointer and UAF. This is exactly the case referred to in the second comment in __iommu_device_set_domain() and just as stated there if we can instead attach the blocking domain the UAF is prevented as this can handle the already removed device. Implement the blocking domain to use this handling. With this change, the crash is fixed but we still hit a warning attempting to change DMA ownership on a blocked device. Fixes: c76c067e488c ("s390/pci: Use dma-iommu layer") Co-developed-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20240910211516.137933-1-mjrosato@linux.ibm.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e9ac61ab1da2e0f7b1b5ad4dc334569a2db98447 Author: Jonathan Marek <jonathan@marek.ca> Date: Sat Oct 5 10:40:46 2024 -0400 clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650 [ Upstream commit aab8d53711346d5569261aec9702b7579eecf1ab ] This driver is compatible with both sm8550 and sm8650, fix the Kconfig entry to reflect that. Fixes: da1f361c887c ("clk: qcom: videocc-sm8550: Add SM8650 video clock controller") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241005144047.2226-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8021756518ecc24624c0d9aa9616a784852df519 Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Date: Thu Oct 10 14:27:26 2024 +0100 pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC [ Upstream commit 5dcde519a067ac5c85c273e550dde1873e2199bf ] Add explicit selection of the PINCTRL_RZG2L config option for the RZ/V2H(P) (R9A09G057) SoC, ensuring pin control driver is enabled for this SoC. Fixes: 9bd95ac86e70 ("pinctrl: renesas: rzg2l: Add support for RZ/V2H SoC") Reported-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20241010132726.702658-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f0e0e5346e04379ee27e04c80ca75a8e127c8d69 Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Date: Thu Oct 10 10:04:32 2024 +0200 pinctrl: zynqmp: drop excess struct member description [ Upstream commit 2a85fc7044987d751f27d7f1e4423eebbcecc2c6 ] The 'node' member has never been part of this structure so drop its description. Fixes: 8b242ca700f8 ("pinctrl: Add Xilinx ZynqMP pinctrl driver support") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/20241010080432.7781-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7f739fa9b25c028a16b10e55a55517724de65e8e Author: Levi Yun <yeoreum.yun@arm.com> Date: Fri Sep 13 03:13:47 2024 +0100 trace/trace_event_perf: remove duplicate samples on the first tracepoint event [ Upstream commit afe5960dc208fe069ddaaeb0994d857b24ac19d1 ] When a tracepoint event is created with attr.freq = 1, 'hwc->period_left' is not initialized correctly. As a result, in the perf_swevent_overflow() function, when the first time the event occurs, it calculates the event overflow and the perf_swevent_set_period() returns 3, this leads to the event are recorded for three duplicate times. Step to reproduce: 1. Enable the tracepoint event & starting tracing $ echo 1 > /sys/kernel/tracing/events/module/module_free $ echo 1 > /sys/kernel/tracing/tracing_on 2. Record with perf $ perf record -a --strict-freq -F 1 -e "module:module_free" 3. Trigger module_free event. $ modprobe -i sunrpc $ modprobe -r sunrpc Result: - Trace pipe result: $ cat trace_pipe modprobe-174509 [003] ..... 6504.868896: module_free: sunrpc - perf sample: modprobe 174509 [003] 6504.868980: module:module_free: sunrpc modprobe 174509 [003] 6504.868980: module:module_free: sunrpc modprobe 174509 [003] 6504.868980: module:module_free: sunrpc By setting period_left via perf_swevent_set_period() as other sw_event did, This problem could be solved. After patch: - Trace pipe result: $ cat trace_pipe modprobe 1153096 [068] 613468.867774: module:module_free: xfs - perf sample modprobe 1153096 [068] 613468.867794: module:module_free: xfs Link: https://lore.kernel.org/20240913021347.595330-1-yeoreum.yun@arm.com Fixes: bd2b5b12849a ("perf_counter: More aggressive frequency adjustment") Signed-off-by: Levi Yun <yeoreum.yun@arm.com> Acked-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f5fc566dffeebe2da628ef99c2190f90f1943e31 Author: Lukas Bulwahn <lukas.bulwahn@redhat.com> Date: Fri Sep 27 11:22:32 2024 +0200 clk: mediatek: drop two dead config options [ Upstream commit 98619dc3cecc2b3943d6abe1db235c868dc72f8d ] Commit 0f471d31e5e8 ("clk: mediatek: Split MT8195 clock drivers and allow module build") adds a number of new COMMON_CLK_MT8195_* config options. Among those, the config options COMMON_CLK_MT8195_AUDSYS and COMMON_CLK_MT8195_MSDC have no reference in the source tree and are not used in the Makefile to include a specific file. Drop the dead config options COMMON_CLK_MT8195_AUDSYS and COMMON_CLK_MT8195_MSDC. Fixes: 0f471d31e5e8 ("clk: mediatek: Split MT8195 clock drivers and allow module build") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Link: https://lore.kernel.org/r/20240927092232.386511-1-lukas.bulwahn@redhat.com Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a59bd5abce6294c7e41fd1e13a62c875dcb892aa Author: Chengchang Tang <tangchengchang@huawei.com> Date: Fri Sep 27 18:33:23 2024 +0800 RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset [ Upstream commit 615b94746a54702af923b28bd8a629f4ac0ff0d8 ] When HW is being reset, userspace should not ring doorbell otherwise it may lead to abnormal consequence such as RAS. Disassociate mmap pages for all uctx to prevent userspace from ringing doorbell to HW. Since all resources will be destroyed during HW reset, no new mmap is allowed after HW reset is completed. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20240927103323.1897094-3-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0598914a950ddfa694f410e482453cdbb9265515 Author: Chengchang Tang <tangchengchang@huawei.com> Date: Fri Sep 27 18:33:22 2024 +0800 RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages [ Upstream commit 51976c6cd786151b6a1bdf8b8b3334beac0ba99c ] Provide a new api rdma_user_mmap_disassociate() for drivers to disassociate mmap pages for a device. Since drivers can now disassociate mmaps by calling this api, introduce a new disassociation_lock to specifically prevent races between this disassociation process and new mmaps. And thus the old hw_destroy_rwsem is not needed in this api. Signed-off-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Junxian Huang <huangjunxian6@hisilicon.com> Link: https://patch.msgid.link/20240927103323.1897094-2-huangjunxian6@hisilicon.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Stable-dep-of: 615b94746a54 ("RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 40c309812687a65673c2f475fd945ee7390da8eb Author: Jie Zhan <zhanjie9@hisilicon.com> Date: Sun Sep 29 11:32:13 2024 +0800 cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged [ Upstream commit c47195631960b626058c335aec31f186fa854f97 ] The CPPC performance feedback counters could be 0 or unchanged when the target cpu is in a low-power idle state, e.g. power-gated or clock-gated. When the counters are 0, cppc_cpufreq_get_rate() returns 0 KHz, which makes cpufreq_online() get a false error and fail to generate a cpufreq policy. When the counters are unchanged, the existing cppc_perf_from_fbctrs() returns a cached desired perf, but some platforms may update the real frequency back to the desired perf reg. For the above cases in cppc_cpufreq_get_rate(), get the latest desired perf from the CPPC reg to reflect the frequency because some platforms may update the actual frequency back there; if failed, use the cached desired perf. Fixes: 6a4fec4f6d30 ("cpufreq: cppc: cppc_cpufreq_get_rate() returns zero in all error cases.") Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Reviewed-by: Zeng Heng <zengheng4@huawei.com> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: Huisong Li <lihuisong@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6504dd27123966dc455494cb55217c04ca479121 Author: André Almeida <andrealmeid@igalia.com> Date: Mon Sep 2 19:55:03 2024 -0300 unicode: Fix utf8_load() error path [ Upstream commit 156bb2c569cd869583c593d27a5bd69e7b2a4264 ] utf8_load() requests the symbol "utf8_data_table" and then checks if the requested UTF-8 version is supported. If it's unsupported, it tries to put the data table using symbol_put(). If an unsupported version is requested, symbol_put() fails like this: kernel BUG at kernel/module/main.c:786! RIP: 0010:__symbol_put+0x93/0xb0 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __symbol_put+0x93/0xb0 ? exc_invalid_op+0x51/0x70 ? __symbol_put+0x93/0xb0 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_cmp_name+0x10/0x10 ? __symbol_put+0x93/0xb0 ? __symbol_put+0x62/0xb0 utf8_load+0xf8/0x150 That happens because symbol_put() expects the unique string that identify the symbol, instead of a pointer to the loaded symbol. Fix that by using such string. Fixes: 2b3d04787012 ("unicode: Add utf8-data module") Signed-off-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Theodore Ts'o <tytso@mit.edu> Link: https://lore.kernel.org/r/20240902225511.757831-2-andrealmeid@igalia.com Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 01f1b88acfd79103da0610b45471f6c88ea98d72 Author: Jiayuan Chen <mrpre@163.com> Date: Mon Nov 18 11:09:09 2024 +0800 bpf: fix recursive lock when verdict program return SK_PASS [ Upstream commit 8ca2a1eeadf09862190b2810697702d803ceef2d ] When the stream_verdict program returns SK_PASS, it places the received skb into its own receive queue, but a recursive lock eventually occurs, leading to an operating system deadlock. This issue has been present since v6.9. ''' sk_psock_strp_data_ready write_lock_bh(&sk->sk_callback_lock) strp_data_ready strp_read_sock read_sock -> tcp_read_sock strp_recv cb.rcv_msg -> sk_psock_strp_read # now stream_verdict return SK_PASS without peer sock assign __SK_PASS = sk_psock_map_verd(SK_PASS, NULL) sk_psock_verdict_apply sk_psock_skb_ingress_self sk_psock_skb_ingress_enqueue sk_psock_data_ready read_lock_bh(&sk->sk_callback_lock) <= dead lock ''' This topic has been discussed before, but it has not been fixed. Previous discussion: https://lore.kernel.org/all/6684a5864ec86_403d20898@john.notmuch Fixes: 6648e613226e ("bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue") Reported-by: Vincent Whitchurch <vincent.whitchurch@datadoghq.com> Signed-off-by: Jiayuan Chen <mrpre@163.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20241118030910.36230-2-mrpre@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 44be8c53eec4e94431dda404cf890036060f4de2 Author: Hangbin Liu <liuhangbin@gmail.com> Date: Sun Nov 17 22:20:29 2024 +0100 wireguard: selftests: load nf_conntrack if not present [ Upstream commit 0290abc9860917f1ee8b58309c2bbd740a39ee8e ] Some distros may not load nf_conntrack by default, which will cause subsequent nf_conntrack sets to fail. Load this module if it is not already loaded. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> [ Jason: add [[ -e ... ]] check so this works in the qemu harness. ] Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://patch.msgid.link/20241117212030.629159-4-Jason@zx2c4.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 34f2c041cb596f0ca859c59694620654ee9a09b6 Author: Breno Leitao <leitao@debian.org> Date: Mon Nov 18 03:15:18 2024 -0800 netpoll: Use rcu_access_pointer() in netpoll_poll_lock [ Upstream commit a57d5a72f8dec7db8a79d0016fb0a3bdecc82b56 ] The ndev->npinfo pointer in netpoll_poll_lock() is RCU-protected but is being accessed directly for a NULL check. While no RCU read lock is held in this context, we should still use proper RCU primitives for consistency and correctness. Replace the direct NULL check with rcu_access_pointer(), which is the appropriate primitive when only checking for NULL without dereferencing the pointer. This function provides the necessary ordering guarantees without requiring RCU read-side protection. Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct net_device objects.") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/20241118-netpoll_rcu-v1-2-a1888dcb4a02@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9b2f33b6046cbdcd19246fdea1292b53d2203b70 Author: Jiawen Wu <jiawenwu@trustnetic.com> Date: Fri Nov 15 15:35:08 2024 +0800 net: txgbe: fix null pointer to pcs [ Upstream commit 2160428bcb20f2f70a72ee84aba91a1264dc4ff3 ] For 1000BASE-X or SGMII interface mode, the PCS also need to be selected. Only return null pointer when there is a copper NIC with external PHY. Fixes: 02b2a6f91b90 ("net: txgbe: support copper NIC with external PHY") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20241115073508.1130046-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2081dae117afd976cab63a65a34595bf548f4bed Author: Jiawen Wu <jiawenwu@trustnetic.com> Date: Fri Nov 15 15:15:27 2024 +0800 net: txgbe: remove GPIO interrupt controller [ Upstream commit e867ed3ac8aa50945170723a450b5c068a56339a ] Since the GPIO interrupt controller is always not working properly, we need to constantly add workaround to cope with hardware deficiencies. So just remove GPIO interrupt controller, and let the SFP driver poll the GPIO status. Fixes: b4a2496c17ed ("net: txgbe: fix GPIO interrupt blocking") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Link: https://patch.msgid.link/20241115071527.1129458-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0a3323b4120f96931a2d77975cb8da601efbb90e Author: Jakub Kicinski <kuba@kernel.org> Date: Thu Nov 14 17:48:09 2024 -0800 eth: fbnic: don't disable the PCI device twice [ Upstream commit 62e9c00ea868ceb71156c517747dc69316c25bf1 ] We use pcim_enable_device(), there is no need to call pci_disable_device(). Fixes: 546dd90be979 ("eth: fbnic: Add scaffolding for Meta's NIC driver") Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241115014809.754860-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3230718a75a6c30ed60ac920c26be2119fa82b8e Author: Alexander Aring <aahringo@redhat.com> Date: Mon Nov 18 11:01:49 2024 -0500 dlm: fix dlm_recover_members refcount on error [ Upstream commit 200b977ebbc313a59174ba971006a231b3533dc5 ] If dlm_recover_members() fails we don't drop the references of the previous created root_list that holds and keep all rsbs alive during the recovery. It might be not an unlikely event because ping_members() could run into an -EINTR if another recovery progress was triggered again. Fixes: 3a747f4a2ee8 ("dlm: move rsb root_list to ls_recover() stack") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 480c6c7b55aeacac800bc2a0d321ff53273045e5 Author: Gao Xiang <xiang@kernel.org> Date: Sat Nov 16 01:36:51 2024 +0800 erofs: handle NONHEAD !delta[1] lclusters gracefully [ Upstream commit 0bc8061ffc733a0a246b8689b2d32a3e9204f43c ] syzbot reported a WARNING in iomap_iter_done: iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctl_fiemap fs/ioctl.c:220 [inline] Generally, NONHEAD lclusters won't have delta[1]==0, except for crafted images and filesystems created by pre-1.0 mkfs versions. Previously, it would immediately bail out if delta[1]==0, which led to inadequate decompressed lengths (thus FIEMAP is impacted). Treat it as delta[1]=1 to work around these legacy mkfs versions. `lclusterbits > 14` is illegal for compact indexes, error out too. Reported-by: syzbot+6c0b301317aa0156f9eb@syzkaller.appspotmail.com Closes: https://lore.kernel.org/r/67373c0c.050a0220.2a2fcc.0079.GAE@google.com Tested-by: syzbot+6c0b301317aa0156f9eb@syzkaller.appspotmail.com Fixes: d95ae5e25326 ("erofs: add support for the full decompressed length") Fixes: 001b8ccd0650 ("erofs: fix compact 4B support for 16k block size") Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20241115173651.3339514-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7f0d0dd5a7f437d83cff954bc321f1a9b181efd5 Author: Felix Maurer <fmaurer@redhat.com> Date: Thu Nov 14 12:30:05 2024 +0100 xsk: Free skb when TX metadata options are invalid [ Upstream commit 0c0d0f42ffa6ac94cd79893b7ed419c15e1b45de ] When a new skb is allocated for transmitting an xsk descriptor, i.e., for every non-multibuf descriptor or the first frag of a multibuf descriptor, but the descriptor is later found to have invalid options set for the TX metadata, the new skb is never freed. This can leak skbs until the send buffer is full which makes sending more packets impossible. Fix this by freeing the skb in the error path if we are currently dealing with the first frag, i.e., an skb allocated in this iteration of xsk_build_skb. Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Reported-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: Felix Maurer <fmaurer@redhat.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Acked-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/edb9b00fb19e680dff5a3350cd7581c5927975a8.1731581697.git.fmaurer@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 91e2a2e4d1336333804cd31162984f01ad8cc70f Author: Dmitry Antipov <dmantipov@yandex.ru> Date: Fri Nov 1 14:44:10 2024 +0300 Bluetooth: fix use-after-free in device_for_each_child() [ Upstream commit 27aabf27fd014ae037cc179c61b0bee7cff55b3d ] Syzbot has reported the following KASAN splat: BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980 CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x100/0x190 ? device_for_each_child+0x18f/0x1a0 print_report+0x13a/0x4cb ? __virt_addr_valid+0x5e/0x590 ? __phys_addr+0xc6/0x150 ? device_for_each_child+0x18f/0x1a0 kasan_report+0xda/0x110 ? device_for_each_child+0x18f/0x1a0 ? __pfx_dev_memalloc_noio+0x10/0x10 device_for_each_child+0x18f/0x1a0 ? __pfx_device_for_each_child+0x10/0x10 pm_runtime_set_memalloc_noio+0xf2/0x180 netdev_unregister_kobject+0x1ed/0x270 unregister_netdevice_many_notify+0x123c/0x1d80 ? __mutex_trylock_common+0xde/0x250 ? __pfx_unregister_netdevice_many_notify+0x10/0x10 ? trace_contention_end+0xe6/0x140 ? __mutex_lock+0x4e7/0x8f0 ? __pfx_lock_acquire.part.0+0x10/0x10 ? rcu_is_watching+0x12/0xc0 ? unregister_netdev+0x12/0x30 unregister_netdevice_queue+0x30d/0x3f0 ? __pfx_unregister_netdevice_queue+0x10/0x10 ? __pfx_down_write+0x10/0x10 unregister_netdev+0x1c/0x30 bnep_session+0x1fb3/0x2ab0 ? __pfx_bnep_session+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? __pfx_woken_wake_function+0x10/0x10 ? __kthread_parkme+0x132/0x200 ? __pfx_bnep_session+0x10/0x10 ? kthread+0x13a/0x370 ? __pfx_bnep_session+0x10/0x10 kthread+0x2b7/0x370 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x48/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 4974: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 __kmalloc_noprof+0x1d1/0x440 hci_alloc_dev_priv+0x1d/0x2820 __vhci_create_device+0xef/0x7d0 vhci_write+0x2c7/0x480 vfs_write+0x6a0/0xfc0 ksys_write+0x12f/0x260 do_syscall_64+0xc7/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 4979: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x4f/0x70 kfree+0x141/0x490 hci_release_dev+0x4d9/0x600 bt_host_release+0x6a/0xb0 device_release+0xa4/0x240 kobject_put+0x1ec/0x5a0 put_device+0x1f/0x30 vhci_release+0x81/0xf0 __fput+0x3f6/0xb30 task_work_run+0x151/0x250 do_exit+0xa79/0x2c30 do_group_exit+0xd5/0x2a0 get_signal+0x1fcd/0x2210 arch_do_signal_or_restart+0x93/0x780 syscall_exit_to_user_mode+0x140/0x290 do_syscall_64+0xd4/0x250 entry_SYSCALL_64_after_hwframe+0x77/0x7f In 'hci_conn_del_sysfs()', 'device_unregister()' may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly. Reported-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com Tested-by: syzbot+6cf5652d3df49fae2e3f@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6cf5652d3df49fae2e3f Fixes: a85fb91e3d72 ("Bluetooth: Fix double free in hci_conn_cleanup") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bfec1e55314896bf4a4cfdb3a9ad4872be9f06ed Author: Iulia Tanasescu <iulia.tanasescu@nxp.com> Date: Mon Nov 11 13:47:08 2024 +0200 Bluetooth: ISO: Send BIG Create Sync via hci_sync [ Upstream commit 07a9342b94a91b306ed1cf6aa8254aea210764c9 ] Before issuing the LE BIG Create Sync command, an available BIG handle is chosen by iterating through the conn_hash list and finding the first unused value. If a BIG is terminated, the associated hcons are removed from the list and the LE BIG Terminate Sync command is sent via hci_sync queue. However, a new LE BIG Create sync command might be issued via hci_send_cmd, before the previous BIG sync was terminated. This can cause the same BIG handle to be reused and the LE BIG Create Sync to fail with Command Disallowed. < HCI Command: LE Broadcast Isochronous Group Create Sync (0x08|0x006b) BIG Handle: 0x00 BIG Sync Handle: 0x0002 Encryption: Unencrypted (0x00) Broadcast Code[16]: 00000000000000000000000000000000 Maximum Number Subevents: 0x00 Timeout: 20000 ms (0x07d0) Number of BIS: 1 BIS ID: 0x01 > HCI Event: Command Status (0x0f) plen 4 LE Broadcast Isochronous Group Create Sync (0x08|0x006b) ncmd 1 Status: Command Disallowed (0x0c) < HCI Command: LE Broadcast Isochronous Group Terminate Sync (0x08|0x006c) BIG Handle: 0x00 This commit fixes the ordering of the LE BIG Create Sync/LE BIG Terminate Sync commands, to make sure that either the previous BIG sync is terminated before reusing the handle, or that a new handle is chosen for a new sync. Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8958e1cee4e2eac1a5b825caa4dd96ce9ed975dd Author: Iulia Tanasescu <iulia.tanasescu@nxp.com> Date: Fri Nov 1 10:23:38 2024 +0200 Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending [ Upstream commit 42ecf1947135110ea08abeaca39741636f9a2285 ] The Bluetooth Core spec does not allow a LE BIG Create sync command to be sent to Controller if another one is pending (Vol 4, Part E, page 2586). In order to avoid this issue, the HCI_CONN_CREATE_BIG_SYNC was added to mark that the LE BIG Create Sync command has been sent for a hcon. Once the BIG Sync Established event is received, the hcon flag is erased and the next pending hcon is handled. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Stable-dep-of: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync") Signed-off-by: Sasha Levin <sashal@kernel.org> commit f3689ce39de2d5db7a6a7862844e4a16ae7175e9 Author: Iulia Tanasescu <iulia.tanasescu@nxp.com> Date: Fri Nov 1 10:23:36 2024 +0200 Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending [ Upstream commit 4a5e0ba68676b3a77298cf646cd2b39c94fbd2f5 ] The Bluetooth Core spec does not allow a LE PA Create sync command to be sent to Controller if another one is pending (Vol 4, Part E, page 2493). In order to avoid this issue, the HCI_CONN_CREATE_PA_SYNC was added to mark that the LE PA Create Sync command has been sent for a hcon. Once the PA Sync Established event is received, the hcon flag is erased and the next pending hcon is handled. Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Stable-dep-of: 07a9342b94a9 ("Bluetooth: ISO: Send BIG Create Sync via hci_sync") Signed-off-by: Sasha Levin <sashal@kernel.org> commit f53e7489273dc2bb307bf50f319b3762d45534f0 Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Date: Tue Oct 1 16:15:51 2024 -0400 Bluetooth: ISO: Use kref to track lifetime of iso_conn [ Upstream commit dc26097bdb864a0d5955b9a25e43376ffc1af99b ] This make use of kref to keep track of reference of iso_conn which allows better tracking of its lifetime with usage of things like kref_get_unless_zero in a similar way as used in l2cap_chan. In addition to it remove call to iso_sock_set_timer on iso_sock_disconn since at that point it is useless to set a timer as the sk will be freed there is nothing to be done in iso_sock_timeout. Fixes: ccf74f2390d6 ("Bluetooth: Add BTPROTO_ISO socket type") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit df6614d6602d60a555d77fc6e2fcf27c679b97cc Author: Javier Carrasco <javier.carrasco.cruz@gmail.com> Date: Thu Oct 31 13:11:23 2024 +0100 Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name() [ Upstream commit e42eec0f182ac0605e658145f6fe3b6a7c256c45 ] of_find_node_by_path() returns a pointer to a device_node with its refcount incremented, and a call to of_node_put() is required to decrement the refcount again and avoid leaking the resource. If 'of_property_read_string_index(root, "compatible", 0, &tmp)' fails, the function returns without calling of_node_put(root) before doing so. The automatic cleanup attribute can be used by means of the __free() macro to automatically call of_node_put() when the variable goes out of scope, fixing the issue and also accounting for new error paths. Fixes: 63fac3343b99 ("Bluetooth: btbcm: Support per-board firmware variants") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d8bd79f0eea9c07d90ce870a714ab5c10afaa4b3 Author: Chris Lu <chris.lu@mediatek.com> Date: Fri Oct 25 14:07:17 2024 +0800 Bluetooth: btmtk: adjust the position to init iso data anchor [ Upstream commit 61c5a3def90ac729a538e5ca5ff7f461cff72776 ] MediaTek iso data anchor init should be moved to where MediaTek claims iso data interface. If there is an unexpected BT usb disconnect during setup flow, it will cause a NULL pointer crash issue when releasing iso anchor since the anchor wasn't been init yet. Adjust the position to do iso data anchor init. [ 17.137991] pc : usb_kill_anchored_urbs+0x60/0x168 [ 17.137998] lr : usb_kill_anchored_urbs+0x44/0x168 [ 17.137999] sp : ffffffc0890cb5f0 [ 17.138000] x29: ffffffc0890cb5f0 x28: ffffff80bb6c2e80 [ 17.144081] gpio gpiochip0: registered chardev handle for 1 lines [ 17.148421] x27: 0000000000000000 [ 17.148422] x26: ffffffd301ff4298 x25: 0000000000000003 x24: 00000000000000f0 [ 17.148424] x23: 0000000000000000 x22: 00000000ffffffff x21: 0000000000000001 [ 17.148425] x20: ffffffffffffffd8 x19: ffffff80c0f25560 x18: 0000000000000000 [ 17.148427] x17: ffffffd33864e408 x16: ffffffd33808f7c8 x15: 0000000000200000 [ 17.232789] x14: e0cd73cf80ffffff x13: 50f2137c0a0338c9 x12: 0000000000000001 [ 17.239912] x11: 0000000080150011 x10: 0000000000000002 x9 : 0000000000000001 [ 17.247035] x8 : 0000000000000000 x7 : 0000000000008080 x6 : 8080000000000000 [ 17.254158] x5 : ffffffd33808ebc0 x4 : fffffffe033dcf20 x3 : 0000000080150011 [ 17.261281] x2 : ffffff8087a91400 x1 : 0000000000000000 x0 : ffffff80c0f25588 [ 17.268404] Call trace: [ 17.270841] usb_kill_anchored_urbs+0x60/0x168 [ 17.275274] btusb_mtk_release_iso_intf+0x2c/0xd8 [btusb (HASH:5afe 6)] [ 17.284226] btusb_mtk_disconnect+0x14/0x28 [btusb (HASH:5afe 6)] [ 17.292652] btusb_disconnect+0x70/0x140 [btusb (HASH:5afe 6)] [ 17.300818] usb_unbind_interface+0xc4/0x240 [ 17.305079] device_release_driver_internal+0x18c/0x258 [ 17.310296] device_release_driver+0x1c/0x30 [ 17.314557] bus_remove_device+0x140/0x160 [ 17.318643] device_del+0x1c0/0x330 [ 17.322121] usb_disable_device+0x80/0x180 [ 17.326207] usb_disconnect+0xec/0x300 [ 17.329948] hub_quiesce+0x80/0xd0 [ 17.333339] hub_disconnect+0x44/0x190 [ 17.337078] usb_unbind_interface+0xc4/0x240 [ 17.341337] device_release_driver_internal+0x18c/0x258 [ 17.346551] device_release_driver+0x1c/0x30 [ 17.350810] usb_driver_release_interface+0x70/0x88 [ 17.355677] proc_ioctl+0x13c/0x228 [ 17.359157] proc_ioctl_default+0x50/0x80 [ 17.363155] usbdev_ioctl+0x830/0xd08 [ 17.366808] __arm64_sys_ioctl+0x94/0xd0 [ 17.370723] invoke_syscall+0x6c/0xf8 [ 17.374377] el0_svc_common+0x84/0xe0 [ 17.378030] do_el0_svc+0x20/0x30 [ 17.381334] el0_svc+0x34/0x60 [ 17.384382] el0t_64_sync_handler+0x88/0xf0 [ 17.388554] el0t_64_sync+0x180/0x188 [ 17.392208] Code: f9400677 f100a2f4 54fffea0 d503201f (b8350288) [ 17.398289] ---[ end trace 0000000000000000 ]--- Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1b3688d0463cf3de095302d5bd7e81f88615623f Author: Kiran K <kiran.k@intel.com> Date: Thu Oct 17 17:21:56 2024 +0530 Bluetooth: btintel: Do no pass vendor events to stack [ Upstream commit 510e8380b0382ee3b070748656b00f83c9a5bf80 ] During firmware download, vendor specific events like boot up and secure send result are generated. These events can be safely processed at the driver level. Passing on these events to stack prints unnecessary log as below. Bluetooth: hci0: Malformed MSFT vendor event: 0x02 Fixes: 3368aa357f3b ("Bluetooth: msft: Handle MSFT Monitor Device Event") Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 56d37739414cb002444497b6713cb35f0924d6bb Author: Kiran K <kiran.k@intel.com> Date: Tue Oct 1 16:14:50 2024 +0530 Bluetooth: btintel_pcie: Add handshake between driver and firmware [ Upstream commit 05c200c8f0295c9c91beeb3ee0552331c1f8adbe ] The following handshake mechanism needs be followed after firmware download is completed to bring the firmware to running state. After firmware fragments of Operational image are downloaded and secure sends result of the image succeeds, 1. Driver sends HCI Intel reset with boot option #1 to switch FW image. 2. FW sends Alive GP[0] MSIx 3. Driver enables data path (doorbell 0x460 for RBDs, etc...) 4. Driver gets Bootup event from firmware 5. Driver performs D0 entry to device (WRITE to IPC_Sleep_Control =0x0) 6. FW sends Alive GP[0] MSIx 7. Device host interface is fully set for BT protocol stack operation. 8. Driver may optionally get debug event with ID 0x97 which can be dropped For Intermediate loadger image, all the above steps are applicable expcept #5 and #6. On HCI_OP_RESET, firmware raises alive interrupt. Driver needs to wait for it before passing control over to bluetooth stack. Co-developed-by: Devegowda Chandrashekar <chandrashekar.devegowda@intel.com> Signed-off-by: Devegowda Chandrashekar <chandrashekar.devegowda@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Stable-dep-of: 510e8380b038 ("Bluetooth: btintel: Do no pass vendor events to stack") Signed-off-by: Sasha Levin <sashal@kernel.org> commit fd741c216a05c8ee7f8734465da375db1d31347d Author: guanjing <guanjing@cmss.chinamobile.com> Date: Fri Nov 8 16:13:58 2024 +0800 selftests: netfilter: Fix missing return values in conntrack_dump_flush [ Upstream commit 041bd1e4f2d82859690cd8b41c35f0f9404c3770 ] Fix the bug of some functions were missing return values. Fixes: eff3c558bb7e ("netfilter: ctnetlink: support filtering by zone") Signed-off-by: Guan Jing <guanjing@cmss.chinamobile.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 56e5c009c9d98fbc3d1d5c75df56b055401fd02d Author: Igor Pylypiv <ipylypiv@google.com> Date: Fri Nov 8 00:15:42 2024 +0000 i2c: dev: Fix memory leak when underlying adapter does not support I2C [ Upstream commit 48730a9d04ffccda541602d722d1ff81920a85d8 ] Early return in i2cdev_ioctl_rdwr() failed to free the memory allocated by the caller. Move freeing the memory to the function where it has been allocated to prevent similar leaks in the future. Fixes: 97ca843f6ad3 ("i2c: dev: Check for I2C_FUNC_I2C before calling i2c_transfer") Signed-off-by: Igor Pylypiv <ipylypiv@google.com> [wsa: replaced '== NULL' with '!'] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0df7f4b5cc10f5adf98be0845372e9eef7bb5b09 Author: Takashi Iwai <tiwai@suse.de> Date: Wed Nov 13 12:10:39 2024 +0100 ALSA: 6fire: Release resources at card release [ Upstream commit a0810c3d6dd2d29a9b92604d682eacd2902ce947 ] The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-6-tiwai@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit dd0de8cb708951cebf727aa045e8242ba651bb52 Author: Takashi Iwai <tiwai@suse.de> Date: Wed Nov 13 12:10:38 2024 +0100 ALSA: caiaq: Use snd_card_free_when_closed() at disconnection [ Upstream commit b04dcbb7f7b1908806b7dc22671cdbe78ff2b82c ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. This patch also splits the code to the disconnect and the free phases; the former is called immediately at the USB disconnect callback while the latter is called from the card destructor. Fixes: 523f1dce3743 ("[ALSA] Add Native Instrument usb audio device support") Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-5-tiwai@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9b27924dc8d7f8a8c35e521287d4ccb9a006e597 Author: Takashi Iwai <tiwai@suse.de> Date: Wed Nov 13 12:10:36 2024 +0100 ALSA: us122l: Use snd_card_free_when_closed() at disconnection [ Upstream commit b7df09bb348016943f56b09dcaafe221e3f73947 ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. The loop of us122l->mmap_count check is dropped as well. The check is useless for the asynchronous operation with *_when_closed(). Fixes: 030a07e44129 ("ALSA: Add USB US122L driver") Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-3-tiwai@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit ffbfc6c4330fc233698529656798bee44fea96f5 Author: Takashi Iwai <tiwai@suse.de> Date: Wed Nov 13 12:10:35 2024 +0100 ALSA: usx2y: Use snd_card_free_when_closed() at disconnection [ Upstream commit dafb28f02be407e07a6f679e922a626592b481b0 ] The USB disconnect callback is supposed to be short and not too-long waiting. OTOH, the current code uses snd_card_free() at disconnection, but this waits for the close of all used fds, hence it can take long. It eventually blocks the upper layer USB ioctls, which may trigger a soft lockup. An easy workaround is to replace snd_card_free() with snd_card_free_when_closed(). This variant returns immediately while the release of resources is done asynchronously by the card device release at the last close. Fixes: 230cd5e24853 ("[ALSA] prevent oops & dead keyboard on usb unplugging while the device is be ing used") Reported-by: syzbot+73582d08864d8268b6fd@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=73582d08864d8268b6fd Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20241113111042.15058-2-tiwai@suse.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit 56840151bd29da24564484d268d67779e6878691 Author: Xu Kuohai <xukuohai@huawei.com> Date: Tue Nov 12 22:58:49 2024 +0800 bpf: Add kernel symbol for struct_ops trampoline [ Upstream commit 7c8ce4ffb684676039b1ff9ff81c126794e8d88e ] Without kernel symbols for struct_ops trampoline, the unwinder may produce unexpected stacktraces. For example, the x86 ORC and FP unwinders check if an IP is in kernel text by verifying the presence of the IP's kernel symbol. When a struct_ops trampoline address is encountered, the unwinder stops due to the absence of symbol, resulting in an incomplete stacktrace that consists only of direct and indirect child functions called from the trampoline. The arm64 unwinder is another example. While the arm64 unwinder can proceed across a struct_ops trampoline address, the corresponding symbol name is displayed as "unknown", which is confusing. Thus, add kernel symbol for struct_ops trampoline. The name is bpf__<struct_ops_name>_<member_name>, where <struct_ops_name> is the type name of the struct_ops, and <member_name> is the name of the member that the trampoline is linked to. Below is a comparison of stacktraces captured on x86 by perf record, before and after this patch. Before: ffffffff8116545d __lock_acquire+0xad ([kernel.kallsyms]) ffffffff81167fcc lock_acquire+0xcc ([kernel.kallsyms]) ffffffff813088f4 __bpf_prog_enter+0x34 ([kernel.kallsyms]) After: ffffffff811656bd __lock_acquire+0x30d ([kernel.kallsyms]) ffffffff81167fcc lock_acquire+0xcc ([kernel.kallsyms]) ffffffff81309024 __bpf_prog_enter+0x34 ([kernel.kallsyms]) ffffffffc000d7e9 bpf__tcp_congestion_ops_cong_avoid+0x3e ([kernel.kallsyms]) ffffffff81f250a5 tcp_ack+0x10d5 ([kernel.kallsyms]) ffffffff81f27c66 tcp_rcv_established+0x3b6 ([kernel.kallsyms]) ffffffff81f3ad03 tcp_v4_do_rcv+0x193 ([kernel.kallsyms]) ffffffff81d65a18 __release_sock+0xd8 ([kernel.kallsyms]) ffffffff81d65af4 release_sock+0x34 ([kernel.kallsyms]) ffffffff81f15c4b tcp_sendmsg+0x3b ([kernel.kallsyms]) ffffffff81f663d7 inet_sendmsg+0x47 ([kernel.kallsyms]) ffffffff81d5ab40 sock_write_iter+0x160 ([kernel.kallsyms]) ffffffff8149c67b vfs_write+0x3fb ([kernel.kallsyms]) ffffffff8149caf6 ksys_write+0xc6 ([kernel.kallsyms]) ffffffff8149cb5d __x64_sys_write+0x1d ([kernel.kallsyms]) ffffffff81009200 x64_sys_call+0x1d30 ([kernel.kallsyms]) ffffffff82232d28 do_syscall_64+0x68 ([kernel.kallsyms]) ffffffff8240012f entry_SYSCALL_64_after_hwframe+0x76 ([kernel.kallsyms]) Fixes: 85d33df357b6 ("bpf: Introduce BPF_MAP_TYPE_STRUCT_OPS") Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20241112145849.3436772-4-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2a99cb07a460714a6118cb17c43390e95bcb9fdd Author: Xu Kuohai <xukuohai@huawei.com> Date: Tue Nov 12 22:58:48 2024 +0800 bpf: Use function pointers count as struct_ops links count [ Upstream commit 821a3fa32bbe3bc0fa23b3189325d3720a49a24c ] Only function pointers in a struct_ops structure can be linked to bpf progs, so set the links count to the function pointers count, instead of the total members count in the structure. Suggested-by: Martin KaFai Lau <martin.lau@linux.dev> Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20241112145849.3436772-3-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Stable-dep-of: 7c8ce4ffb684 ("bpf: Add kernel symbol for struct_ops trampoline") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 715f54ef0c91ad7b19f541552f55975d79002f3f Author: Kalle Valo <kvalo@kernel.org> Date: Tue Nov 12 16:24:19 2024 +0200 Revert "wifi: iwlegacy: do not skip frames with bad FCS" [ Upstream commit 11597043d74809daf5d14256b96d6781749b3f82 ] This reverts commit 02b682d54598f61cbb7dbb14d98ec1801112b878. Alf reports that this commit causes the connection to eventually die on iwl4965. The reason is that rx_status.flag is zeroed after RX_FLAG_FAILED_FCS_CRC is set and mac80211 doesn't know the received frame is corrupted. Fixes: 02b682d54598 ("wifi: iwlegacy: do not skip frames with bad FCS") Reported-by: Alf Marius <post@alfmarius.net> Closes: https://lore.kernel.org/r/60f752e8-787e-44a8-92ae-48bdfc9b43e7@app.fastmail.com/ Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241112142419.1023743-1-kvalo@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit b093bea53cfcff2b40d6ddf00c569d13bcbdeb82 Author: Mingwei Zheng <zmw12306@gmail.com> Date: Fri Nov 8 14:53:41 2024 -0500 net: rfkill: gpio: Add check for clk_enable() [ Upstream commit 8251e7621b25ccdb689f1dd9553b8789e3745ea1 ] Add check for the return value of clk_enable() to catch the potential error. Fixes: 7176ba23f8b5 ("net: rfkill: add generic gpio rfkill driver") Signed-off-by: Mingwei Zheng <zmw12306@gmail.com> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com> Link: https://patch.msgid.link/20241108195341.1853080-1-zmw12306@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 11edcd026012ac18acee0f1514db3ed1b160fc6f Author: Omid Ehtemam-Haghighi <omid.ehtemamhaghighi@menlosecurity.com> Date: Tue Nov 5 17:02:36 2024 -0800 ipv6: Fix soft lockups in fib6_select_path under high next hop churn [ Upstream commit d9ccb18f83ea2bb654289b6ecf014fd267cc988b ] Soft lockups have been observed on a cluster of Linux-based edge routers located in a highly dynamic environment. Using the `bird` service, these routers continuously update BGP-advertised routes due to frequently changing nexthop destinations, while also managing significant IPv6 traffic. The lockups occur during the traversal of the multipath circular linked-list in the `fib6_select_path` function, particularly while iterating through the siblings in the list. The issue typically arises when the nodes of the linked list are unexpectedly deleted concurrently on a different core—indicated by their 'next' and 'previous' elements pointing back to the node itself and their reference count dropping to zero. This results in an infinite loop, leading to a soft lockup that triggers a system panic via the watchdog timer. Apply RCU primitives in the problematic code sections to resolve the issue. Where necessary, update the references to fib6_siblings to annotate or use the RCU APIs. Include a test script that reproduces the issue. The script periodically updates the routing table while generating a heavy load of outgoing IPv6 traffic through multiple iperf3 clients. It consistently induces infinite soft lockups within a couple of minutes. Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d -- <IRQ stack> -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c 10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c 11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5 12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274 15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615 17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec 18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3 19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9 20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice] 21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice] 22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice] 23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000 24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581 25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9 26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f 29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64 30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb Fixes: 66f5d6ce53e6 ("ipv6: replace rwlock with rcu and spinlock in fib6_table") Reported-by: Adrian Oliver <kernel@aoliver.ca> Signed-off-by: Omid Ehtemam-Haghighi <omid.ehtemamhaghighi@menlosecurity.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Ido Schimmel <idosch@idosch.org> Cc: Kuniyuki Iwashima <kuniyu@amazon.com> Cc: Simon Horman <horms@kernel.org> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241106010236.1239299-1-omid.ehtemamhaghighi@menlosecurity.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 316d7d6e027d96996b4140d91260616b1de210ef Author: Viktor Malik <vmalik@redhat.com> Date: Thu Nov 7 12:52:31 2024 +0100 selftests/bpf: skip the timer_lockup test for single-CPU nodes [ Upstream commit 937a1c29a287e8f48c4cea714c76a13e14d989ac ] The timer_lockup test needs 2 CPUs to work, on single-CPU nodes it fails to set thread affinity to CPU 1 since it doesn't exist: # ./test_progs -t timer_lockup test_timer_lockup:PASS:timer_lockup__open_and_load 0 nsec test_timer_lockup:PASS:pthread_create thread1 0 nsec test_timer_lockup:PASS:pthread_create thread2 0 nsec timer_lockup_thread:PASS:cpu affinity 0 nsec timer_lockup_thread:FAIL:cpu affinity unexpected error: 22 (errno 0) test_timer_lockup:PASS: 0 nsec #406 timer_lockup:FAIL Skip the test if only 1 CPU is available. Signed-off-by: Viktor Malik <vmalik@redhat.com> Fixes: 50bd5a0c658d1 ("selftests/bpf: Add timer lockup selftest") Tested-by: Philo Lu <lulie@linux.alibaba.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20241107115231.75200-1-vmalik@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 07021ef111a9e555d2803e58ffa64c01901e3efd Author: Jiri Olsa <jolsa@kernel.org> Date: Fri Nov 8 14:45:33 2024 +0100 bpf: Force uprobe bpf program to always return 0 [ Upstream commit f505005bc7426f4309880da94cfbfc37efa225bd ] As suggested by Andrii make uprobe multi bpf programs to always return 0, so they can't force uprobe removal. Keeping the int return type for uprobe_prog_run, because it will be used in following session changes. Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20241108134544.480660-3-jolsa@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 20a1ee9fcce7bc1cbcb8b45205325d966ed9432b Author: Jiri Olsa <jolsa@kernel.org> Date: Fri Nov 8 14:45:32 2024 +0100 bpf: Allow return values 0 and 1 for kprobe session [ Upstream commit 17c4b65a24938c6dd79496cce5df15f70d9c253c ] The kprobe session program can return only 0 or 1, instruct verifier to check for that. Fixes: 535a3692ba72 ("bpf: Add support for kprobe session attach") Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20241108134544.480660-2-jolsa@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4b0dc2c8fc3361ef7098bf98a6206185bf3efec1 Author: Yuan Can <yuancan@huawei.com> Date: Wed Nov 6 09:35:41 2024 +0800 drm/amdkfd: Fix wrong usage of INIT_WORK() [ Upstream commit 21cae8debc6a1d243f64fa82cd1b41cb612b5c61 ] In kfd_procfs_show(), the sdma_activity_work_handler is a local variable and the sdma_activity_work_handler.sdma_activity_work should initialize with INIT_WORK_ONSTACK() instead of INIT_WORK(). Fixes: 32cb59f31362 ("drm/amdkfd: Track SDMA utilization per process") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Felix Kuehling <felix.kuehling@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5274cfe6c5999f89ba6e293c6fedb49f5f7eab42 Author: Lijo Lazar <lijo.lazar@amd.com> Date: Tue Nov 5 10:30:20 2024 +0530 drm/amdgpu: Fix map/unmap queue logic [ Upstream commit fa31798582882740f2b13d19e1bd43b4ef918e2f ] In current logic, it calls ring_alloc followed by a ring_test. ring_test in turn will call another ring_alloc. This is illegal usage as a ring_alloc is expected to be closed properly with a ring_commit. Change to commit the map/unmap queue packet first followed by a ring_test. Add a comment about the usage of ring_test. Also, reorder the current pre-condition checks of job hang or kiq ring scheduler not ready. Without them being met, it is not useful to attempt ring or memory allocations. Fixes tag refers to the original patch which introduced this issue which then got carried over into newer code. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Fixes: 6c10b5cc4eaa ("drm/amdgpu: Remove duplicate code in gfx_v8_0.c") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1623d2ecb98dfd159616052f13622eaf2582b5c2 Author: Yang Wang <kevinyang.wang@amd.com> Date: Wed Nov 6 14:49:56 2024 +0800 drm/amdgpu: fix ACA bank count boundary check error [ Upstream commit 2bb7dced1c2f8c0e705cc74840f776406db492c3 ] fix ACA bank count boundary check error. Fixes: f5e4cc8461c4 ("drm/amdgpu: implement RAS ACA driver framework") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e0e6e53c956a4278af5284445140cb0e5080e4f5 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Mon Oct 28 13:54:54 2024 +0200 wifi: iwlwifi: mvm: tell iwlmei when we finished suspending [ Upstream commit d1a54ec21b8e7bca59141ff1ac6ce73e07d744f2 ] Since we no longer shut down the device in suspend, we also no longer call iwl_mvm_mei_device_state() and this is a problem because iwlmei expects this to be called when it runs its own suspend sequence. It checks mei->device_down in iwl_mei_remove() which is called upon suspend. Fix this by telling iwlmei when we're done accessing the device. When we'll wake up, the device should be untouched if CSME didn't use it during the suspend time. If CSME used it, we'll notice it through the CSR_FUNC_SCRATCH register. Fixes: e8bb19c1d590 ("wifi: iwlwifi: support fast resume") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241028135215.525287b90af2.Ibf183824471ea5580d9276d104444e53191e6900@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2d0b5e56aff2a7bd8e600fa924288d0ad65071ce Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Mon Oct 28 13:54:53 2024 +0200 wifi: iwlwifi: allow fast resume on ax200 [ Upstream commit e53ebc72054efca12e0329d69342e3daf7250a5a ] This feature can be used on ax200 as well. It'll avoid to restart the firmware upon suspend / resume flow. Doing so also avoids releasing and re-allocating all the device related memory which makes the memory's subsystem task easier. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241028135215.514efe0ce4c7.I60061277526302a75cadbba10452e94c54763f13@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Stable-dep-of: d1a54ec21b8e ("wifi: iwlwifi: mvm: tell iwlmei when we finished suspending") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5b99ff3e80604dcb92f9639fe54577832438146e Author: Lingbo Kong <quic_lingbok@quicinc.com> Date: Thu Oct 31 21:42:23 2024 +0800 wifi: cfg80211: Remove the Medium Synchronization Delay validity check [ Upstream commit b4ebb58cb9a4b1b5cb5278b09d6afdcd71b2a6b4 ] Currently, when the driver attempts to connect to an AP MLD with multiple APs, the cfg80211_mlme_check_mlo_compat() function requires the Medium Synchronization Delay values from different APs of the same AP MLD to be equal, which may result in connection failures. This is because when the driver receives a multi-link probe response from an AP MLD with multiple APs, cfg80211 updates the Elements for each AP based on the multi-link probe response. If the Medium Synchronization Delay is set in the multi-link probe response, the Elements for each AP belonging to the same AP MLD will have the Medium Synchronization Delay set simultaneously. If non-multi-link probe responses are received from different APs of the same MLD AP, cfg80211 will still update the Elements based on the non-multi-link probe response. Since the non-multi-link probe response does not set the Medium Synchronization Delay (IEEE 802.11be-2024-35.3.4.4), if the Elements from a non-multi-link probe response overwrite those from a multi-link probe response that has set the Medium Synchronization Delay, the Medium Synchronization Delay values for APs belonging to the same AP MLD will not be equal. This discrepancy causes the cfg80211_mlme_check_mlo_compat() function to fail, leading to connection failures. Commit ccb964b4ab16 ("wifi: cfg80211: validate MLO connections better") did not take this into account. To address this issue, remove this validity check. Fixes: ccb964b4ab16 ("wifi: cfg80211: validate MLO connections better") Signed-off-by: Lingbo Kong <quic_lingbok@quicinc.com> Link: https://patch.msgid.link/20241031134223.970-1-quic_lingbok@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 470036c220136b4b36465d6d291b54337cbadeb0 Author: Paolo Abeni <pabeni@redhat.com> Date: Tue Nov 5 19:23:51 2024 +0100 selftests: net: really check for bg process completion [ Upstream commit 52ed077aa6336dbef83a2d6d21c52d1706fb7f16 ] A recent refactor transformed the check for process completion in a true statement, due to a typo. As a result, the relevant test-case is unable to catch the regression it was supposed to detect. Restore the correct condition. Fixes: 691bb4e49c98 ("selftests: net: avoid just another constant wait") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/0e6f213811f8e93a235307e683af8225cc6277ae.1730828007.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a3c3f8a4d025acc8c857246ec2b812c59102487a Author: Paolo Abeni <pabeni@redhat.com> Date: Tue Nov 5 19:23:50 2024 +0100 ipv6: release nexthop on device removal [ Upstream commit eb02688c5c45c3e7af7e71f036a7144f5639cbfe ] The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test: unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6 ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0 While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info. Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown(). Tested running: ./pmtu.sh cleanup_ipv6_exception in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations. Fixes: f88d8ea67fbd ("ipv6: Plumb support for nexthop object in a fib6_info") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/604c45c188c609b732286b47ac2a451a40f6cf6d.1730828007.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0edec6f93e355a8ec593a26ea4ccf2a08b3bd624 Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:20 2024 +0000 bpf, sockmap: Fix sk_msg_reset_curr [ Upstream commit 955afd57dc4bf7e8c620a0a9e3af3c881c2c6dff ] Found in the test_txmsg_pull in test_sockmap, ``` txmsg_cork = 512; // corking is importrant here opt->iov_length = 3; opt->iov_count = 1; opt->rate = 512; // sendmsg will be invoked 512 times ``` The first sendmsg will send an sk_msg with size 3, and bpf_msg_pull_data will be invoked the first time. sk_msg_reset_curr will reset the copybreak from 3 to 0. In the second sendmsg, since we are in the stage of corking, psock->cork will be reused in func sk_msg_alloc. msg->sg.copybreak is 0 now, the second msg will overwrite the first msg. As a result, we could not pass the data integrity test. The same problem happens in push and pop test. Thus, fix sk_msg_reset_curr to restore the correct copybreak. Fixes: bb9aefde5bba ("bpf: sockmap, updating the sg structure should also update curr") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241106222520.527076-9-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 785180bed9879680d8e5c5e1b54c8ae8d948f4c8 Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:19 2024 +0000 bpf, sockmap: Several fixes to bpf_msg_pop_data [ Upstream commit 5d609ba262475db450ba69b8e8a557bd768ac07a ] Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. Fixes: 7246d8ed4dcc ("bpf: helper to pop data from messages") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-8-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1a0d5c17d5ce1019aa2a48b4e6a7b4ce877382c9 Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:18 2024 +0000 bpf, sockmap: Several fixes to bpf_msg_push_data [ Upstream commit 15ab0548e3107665c34579ae523b2b6e7c22082a ] Several fixes to bpf_msg_push_data, 1. test_sockmap has tests where bpf_msg_push_data is invoked to push some data at the end of a message, but -EINVAL is returned. In this case, in bpf_msg_push_data, after the first loop, i will be set to msg->sg.end, add the logic to handle it. 2. In the code block of "if (start - offset)", it's possible that "i" points to the last of sk_msg_elem. In this case, "sk_msg_iter_next(msg, end)" might still be called twice, another invoking is in "if (!copy)" code block, but actually only one is needed. Add the logic to handle it, and reconstruct the code to make the logic more clear. Fixes: 6fff607e2f14 ("bpf: sk_msg program helper bpf_msg_push_data") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241106222520.527076-7-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1b2129208a2f1999ee131df74ecb14bfac19da6d Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:16 2024 +0000 selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap [ Upstream commit 862087c3d36219ed44569666eb263efc97f00c9a ] Add push/pop checking for msg_verify_data in test_sockmap, except for pop/push with cork tests, in these tests the logic will be different. 1. With corking, pop/push might not be invoked in each sendmsg, it makes the layout of the received data difficult 2. It makes it hard to calculate the total_bytes in the recvmsg Temporarily skip the data integrity test for these cases now, added a TODO Fixes: ee9b352ce465 ("selftests/bpf: Fix msg_verify_data in test_sockmap") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-5-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8527869190fd6d0efe07e5f78985e992c575a281 Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:15 2024 +0000 selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap [ Upstream commit 523dffccbadea0cfd65f1ff04944b864c558c4a8 ] total_bytes in msg_loop_rx should also take push into account, otherwise total_bytes will be a smaller value, which makes the msg_loop_rx end early. Besides, total_bytes has already taken pop into account, so we don't need to subtract some bytes from iov_buf in sendmsg_test. The additional subtraction may make total_bytes a negative number, and msg_loop_rx will just end without checking anything. Fixes: 18d4e900a450 ("bpf: Selftests, improve test_sockmap total bytes counter") Fixes: d69672147faa ("selftests, bpf: Add one test for sockmap with strparser") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-4-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f7d1f6f7dcd19827729b2a15f09b2e7d1bc5f5bd Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:14 2024 +0000 selftests/bpf: Fix SENDPAGE data logic in test_sockmap [ Upstream commit 4095031463d4e99b534d2cd82035a417295764ae ] In the SENDPAGE test, "opt->iov_length * cnt" size of data will be sent cnt times by sendfile. 1. In push/pop tests, they will be invoked cnt times, for the simplicity of msg_verify_data, change chunk_sz to iov_length 2. Change iov_length in test_send_large from 1024 to 8192. We have pop test where txmsg_start_pop is 4096. 4096 > 1024, an error will be returned. Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-3-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ad410729a4b0946549bd9b146fa85228212af2a4 Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Wed Nov 6 22:25:13 2024 +0000 selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap [ Upstream commit 66c54c20408d994be34be2c070fba08472f69eee ] Add txmsg_pass to test_txmsg_pull/push/pop. If txmsg_pass is missing, tx_prog will be NULL, and no program will be attached to the sockmap. As a result, pull/push/pop are never invoked. Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests") Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/r/20241106222520.527076-2-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 34f090ddb3630a26e5a6b220bf3bfaf5c7b70393 Author: Hao Ge <gehao@kylinos.cn> Date: Wed Nov 6 16:28:41 2024 +0800 isofs: avoid memory leak in iocharset [ Upstream commit 0b5bbeee4de616a268db77e2f40f19ab010a367b ] A memleak was found as below: unreferenced object 0xffff0000d10164d8 (size 8): comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes): 75 74 66 38 00 cc cc cc utf8.... backtrace (crc de430d31): [<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8 [<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474 [<ffff800080363b74>] kstrdup+0x70/0xfc [<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs] [<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164 [<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4 [<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc [<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c [<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c [<ffff8000804b6a64>] path_mount+0x6c4/0x9ec [<ffff8000804b6e38>] do_mount+0xac/0xc4 [<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0 [<ffff80008002b8dc>] invoke_syscall+0x7c/0x104 [<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104 [<ffff80008002ba94>] do_el0_svc+0x2c/0x38 [<ffff800081041108>] el0_svc+0x3c/0x1b8 The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function. For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak. Let's move the memory freeing of opt->iocharset into isofs_free_fc function. Fixes: 1b17a46c9243 ("isofs: convert isofs to use the new mount API") Signed-off-by: Hao Ge <gehao@kylinos.cn> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20241106082841.51773-1-hao.ge@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org> commit 60623296b142f46ca5c7367c64e5be3e4b431424 Author: Adrián Larumbe <adrian.larumbe@collabora.com> Date: Tue Nov 5 20:54:56 2024 +0000 drm/panthor: Fix OPP refcnt leaks in devfreq initialisation [ Upstream commit 21c23e4b64e360d74d31b480f0572c2add0e8558 ] Rearrange lookup of recommended OPP for the Mali GPU device and its refcnt decremental to make sure no OPP object leaks happen in the error path. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: fac9b22df4b1 ("drm/panthor: Add the devfreq logical block") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241105205458.1318989-2-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7712b6a44d7a24d16f307f12100437270d43dceb Author: Adrián Larumbe <adrian.larumbe@collabora.com> Date: Tue Sep 24 00:06:22 2024 +0100 drm/panthor: record current and maximum device clock frequencies [ Upstream commit 37591ae11f89cdfc0a647945a589468642a44c17 ] In order to support UM in calculating rates of GPU utilisation, the current operating and maximum GPU clock frequencies must be recorded during device initialisation, and also during OPP state transitions. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-3-adrian.larumbe@collabora.com Stable-dep-of: 21c23e4b64e3 ("drm/panthor: Fix OPP refcnt leaks in devfreq initialisation") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 80a701bc8f87a4fc3b0746f7421acd8705524b2a Author: Adrián Larumbe <adrian.larumbe@collabora.com> Date: Tue Sep 24 00:06:21 2024 +0100 drm/panthor: introduce job cycle and timestamp accounting [ Upstream commit f8ff51a4708451763e6cfa36cc83dea8513d3318 ] Enable calculations of job submission times in clock cycles and wall time. This is done by expanding the boilerplate command stream when running a job to include instructions that compute said times right before and after a user CS. A separate kernel BO is created per queue to store those values. Jobs can access their sampled data through an index different from that of the queue's ringbuffer. The reason for this is saving memory on the profiling information kernel BO, since the amount of simultaneous profiled jobs we can write into the queue's ringbuffer might be much smaller than for regular jobs, as the former take more CSF instructions. This commit is done in preparation for enabling DRM fdinfo support in the Panthor driver, which depends on the numbers calculated herein. A profile mode mask has been added that will in a future commit allow UM to toggle performance metric sampling behaviour, which is disabled by default to save power. When a ringbuffer CS is constructed, timestamp and cycling sampling instructions are added depending on the enabled flags in the profiling mask. A helper was provided that calculates the number of instructions for a given set of enablement mask, and these are passed as the number of credits when initialising a DRM scheduler job. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-2-adrian.larumbe@collabora.com Stable-dep-of: 21c23e4b64e3 ("drm/panthor: Fix OPP refcnt leaks in devfreq initialisation") Signed-off-by: Sasha Levin <sashal@kernel.org> commit adfe98b81fd6d45d85c703587942ae29f580e675 Author: Adrián Larumbe <adrian.larumbe@collabora.com> Date: Tue Nov 5 20:54:55 2024 +0000 drm/panfrost: Add missing OPP table refcnt decremental [ Upstream commit 043e8afebf6c19abde9da1ac3d5cbf8b7ac8393f ] Commit f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics") retrieves the OPP for the maximum device clock frequency, but forgets to keep the reference count balanced by putting the returned OPP object. This eventually leads to an OPP core warning when removing the device. Fix it by putting OPP objects as many times as they're retrieved. Also remove an unnecessary whitespace. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics") Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241105205458.1318989-1-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 051577414271961f3f4c3bff87b427924b486219 Author: Pei Xiao <xiaopei01@kylinos.cn> Date: Wed Oct 30 11:20:58 2024 +0800 wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg() [ Upstream commit 81df5ed446b448bdc327b7c7f0b50121fc1f4aa2 ] kmalloc may fail, return value might be NULL and will cause NULL pointer dereference. Add check NULL return of kmalloc in btc_fw_set_monreg(). Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6d8fa26a2d31a591984abe0f07b63bbc8bfcfaae Author: Maurice Lambert <mauricelambert434@gmail.com> Date: Sun Nov 3 23:39:50 2024 +0100 netlink: typographical error in nlmsg_type constants definition [ Upstream commit 84bfbfbbd32aee136afea4b6bf82581dce79c305 ] This commit fix a typographical error in netlink nlmsg_type constants definition in the include/uapi/linux/rtnetlink.h at line 177. The definition is RTM_NEWNVLAN RTM_NEWVLAN instead of RTM_NEWVLAN RTM_NEWVLAN. Signed-off-by: Maurice Lambert <mauricelambert434@gmail.com> Fixes: 8dcea187088b ("net: bridge: vlan: add rtm definitions and dump support") Link: https://patch.msgid.link/20241103223950.230300-1-mauricelambert434@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ccf306420775052abe613e532f612ee8b6ecdd61 Author: Florian Westphal <fw@strlen.de> Date: Mon Nov 4 10:41:19 2024 +0100 netfilter: nf_tables: must hold rcu read lock while iterating object type list [ Upstream commit cddc04275f95ca3b18da5c0fb111705ac173af89 ] Update of stateful object triggers: WARNING: suspicious RCU usage net/netfilter/nf_tables_api.c:7759 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by nft/3060: #0: ffff88810f0578c8 (&nft_net->commit_mutex){+.+.}-{4:4}, [..] ... but this list is not protected by the transaction mutex but the nfnl nftables subsystem mutex. Switch to nft_obj_type_get which will acquire rcu read lock, bump refcount, and returns the result. v3: Dan Carpenter points out nft_obj_type_get returns error pointer, not NULL, on error. Fixes: dad3bdeef45f ("netfilter: nf_tables: fix memory leak during stateful obj update"). Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit eddbacbaa176bf333d3a7f06bcf4625eeddb581c Author: Florian Westphal <fw@strlen.de> Date: Mon Nov 4 10:41:18 2024 +0100 netfilter: nf_tables: must hold rcu read lock while iterating expression type list [ Upstream commit ee666a541ed957937454d50afa4757924508cd74 ] nft shell tests trigger: WARNING: suspicious RCU usage net/netfilter/nf_tables_api.c:3125 RCU-list traversed in non-reader section!! 1 lock held by nft/2068: #0: ffff888106c6f8c8 (&nft_net->commit_mutex){+.+.}-{4:4}, at: nf_tables_valid_genid+0x3c/0xf0 But the transaction mutex doesn't protect this list, the nfnl subsystem mutex would, but we can't acquire it here without risk of ABBA deadlocks. Acquire the rcu read lock to avoid this issue. v3: add a comment that explains the ->inner_ops check implies expression is builtin and lack of a module owner reference is ok. Fixes: 3a07327d10a0 ("netfilter: nft_inner: support for inner tunnel header matching") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 98e9285c0c0c2f687c2cf7ce8386df37da15dd7a Author: Florian Westphal <fw@strlen.de> Date: Mon Nov 4 10:41:13 2024 +0100 netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion [ Upstream commit 9adbb4198bf6cf3634032871118a7052aeaa573f ] On rule delete we get: WARNING: suspicious RCU usage net/netfilter/nf_tables_api.c:3420 RCU-list traversed in non-reader section!! 1 lock held by iptables/134: #0: ffff888008c4fcc8 (&nft_net->commit_mutex){+.+.}-{3:3}, at: nf_tables_valid_genid (include/linux/jiffies.h:101) nf_tables Code is fine, no other CPU can change the list because we're holding transaction mutex. Pass the needed lockdep annotation to the iterator and fix two comments for functions that are no longer restricted to rcu-only context. This is enough to resolve rule delete, but there are several other missing annotations, added in followup-patches. Fixes: 28875945ba98 ("rcu: Add support for consolidated-RCU reader checking") Reported-by: Matthieu Baerts <matttbe@kernel.org> Tested-by: Matthieu Baerts <matttbe@kernel.org> Closes: https://lore.kernel.org/netfilter-devel/da27f17f-3145-47af-ad0f-7fd2a823623e@kernel.org/ Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 03a3b9e0f8f59850cdccb50cdc2ba9e2b8f7e590 Author: Jonathan Gray <jsg@jsg.id.au> Date: Thu Jan 11 13:30:45 2024 +1100 drm: use ATOMIC64_INIT() for atomic64_t [ Upstream commit 9877bb2775d020fb7000af5ca989331d09d0e372 ] use ATOMIC64_INIT() not ATOMIC_INIT() for atomic64_t Fixes: 3f09a0cd4ea3 ("drm: Add common fdinfo helper") Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240111023045.50013-1-jsg@jsg.id.au Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c9b91d2d54175f781ad2c361cb2ac2c0e29b14b6 Author: Kumar Kartikeya Dwivedi <memxor@gmail.com> Date: Mon Nov 4 09:19:57 2024 -0800 bpf: Mark raw_tp arguments with PTR_MAYBE_NULL [ Upstream commit cb4158ce8ec8a5bb528cc1693356a5eb8058094d ] Arguments to a raw tracepoint are tagged as trusted, which carries the semantics that the pointer will be non-NULL. However, in certain cases, a raw tracepoint argument may end up being NULL. More context about this issue is available in [0]. Thus, there is a discrepancy between the reality, that raw_tp arguments can actually be NULL, and the verifier's knowledge, that they are never NULL, causing explicit NULL checks to be deleted, and accesses to such pointers potentially crashing the kernel. To fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special case the dereference and pointer arithmetic to permit it, and allow passing them into helpers/kfuncs; these exceptions are made for raw_tp programs only. Ensure that we don't do this when ref_obj_id > 0, as in that case this is an acquired object and doesn't need such adjustment. The reason we do mask_raw_tp_trusted_reg logic is because other will recheck in places whether the register is a trusted_reg, and then consider our register as untrusted when detecting the presence of the PTR_MAYBE_NULL flag. To allow safe dereference, we enable PROBE_MEM marking when we see loads into trusted pointers with PTR_MAYBE_NULL. While trusted raw_tp arguments can also be passed into helpers or kfuncs where such broken assumption may cause issues, a future patch set will tackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can already be passed into helpers and causes similar problems. Thus, they are left alone for now. It is possible that these checks also permit passing non-raw_tp args that are trusted PTR_TO_BTF_ID with null marking. In such a case, allowing dereference when pointer is NULL expands allowed behavior, so won't regress existing programs, and the case of passing these into helpers is the same as above and will be dealt with later. Also update the failure case in tp_btf_nullable selftest to capture the new behavior, as the verifier will no longer cause an error when directly dereference a raw tracepoint argument marked as __nullable. [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb Reviewed-by: Jiri Olsa <jolsa@kernel.org> Reported-by: Juri Lelli <juri.lelli@redhat.com> Tested-by: Juri Lelli <juri.lelli@redhat.com> Fixes: 3f00c5239344 ("bpf: Allow trusted pointers to be passed to KF_TRUSTED_ARGS kfuncs") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20241104171959.2938862-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6b5b45b153f3ca6f5fa57d84a33a2dff9c9eeeec Author: Philo Lu <lulie@linux.alibaba.com> Date: Wed Sep 11 11:37:16 2024 +0800 selftests/bpf: Add test for __nullable suffix in tp_btf [ Upstream commit 2060f07f861a237345922023e9347a204c0795af ] Add a tracepoint with __nullable suffix in bpf_testmod, and add cases for it: $ ./test_progs -t "tp_btf_nullable" #406/1 tp_btf_nullable/handle_tp_btf_nullable_bare1:OK #406/2 tp_btf_nullable/handle_tp_btf_nullable_bare2:OK #406 tp_btf_nullable:OK Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Philo Lu <lulie@linux.alibaba.com> Link: https://lore.kernel.org/r/20240911033719.91468-3-lulie@linux.alibaba.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Stable-dep-of: cb4158ce8ec8 ("bpf: Mark raw_tp arguments with PTR_MAYBE_NULL") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 996264f5bad01ef260ebae3873fc8efd443c2539 Author: Philo Lu <lulie@linux.alibaba.com> Date: Wed Sep 11 11:37:15 2024 +0800 bpf: Support __nullable argument suffix for tp_btf [ Upstream commit 8aeaed21befc90f27f4fca6dd190850d97d2e9e3 ] Pointers passed to tp_btf were trusted to be valid, but some tracepoints do take NULL pointer as input, such as trace_tcp_send_reset(). Then the invalid memory access cannot be detected by verifier. This patch fix it by add a suffix "__nullable" to the unreliable argument. The suffix is shown in btf, and PTR_MAYBE_NULL will be added to nullable arguments. Then users must check the pointer before use it. A problem here is that we use "btf_trace_##call" to search func_proto. As it is a typedef, argument names as well as the suffix are not recorded. To solve this, I use bpf_raw_event_map to find "__bpf_trace##template" from "btf_trace_##call", and then we can see the suffix. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Philo Lu <lulie@linux.alibaba.com> Link: https://lore.kernel.org/r/20240911033719.91468-2-lulie@linux.alibaba.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Stable-dep-of: cb4158ce8ec8 ("bpf: Mark raw_tp arguments with PTR_MAYBE_NULL") Signed-off-by: Sasha Levin <sashal@kernel.org> commit d14bea4e094871226ea69772d69dab8b7b5f4915 Author: Li Huafei <lihuafei1@huawei.com> Date: Wed Oct 30 04:27:58 2024 +0800 drm/amdgpu: Fix the memory allocation issue in amdgpu_discovery_get_nps_info() [ Upstream commit a1144da794adedb9447437c57d69add56494309d ] Fix two issues with memory allocation in amdgpu_discovery_get_nps_info() for mem_ranges: - Add a check for allocation failure to avoid dereferencing a null pointer. - As suggested by Christophe, use kvcalloc() for memory allocation, which checks for multiplication overflow. Additionally, assign the output parameters nps_type and range_cnt after the kvcalloc() call to prevent modifying the output parameters in case of an error return. Fixes: b194d21b9bcc ("drm/amdgpu: Use NPS ranges from discovery table") Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Li Huafei <lihuafei1@huawei.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8eaff8c704a6e3a55f84f813db95027d0198f270 Author: José Expósito <jose.exposito89@gmail.com> Date: Thu Oct 31 19:38:35 2024 +0100 drm/vkms: Drop unnecessary call to drm_crtc_cleanup() [ Upstream commit 1d43dddd7c38ea1aa93f78f7ee10087afb0a561f ] CRTC creation uses drmm_crtc_init_with_planes(), which automatically handles cleanup. However, an unnecessary call to drm_crtc_cleanup() is still present in the vkms_output_init() error path. Fixes: 99cc528ebe92 ("drm/vkms: Use drmm_crtc_init_with_planes()") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241031183835.3633-1-jose.exposito89@gmail.com Acked-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit cc8f75d8ffaaecd737907c0a1e0582722f6631ec Author: Kumar Kartikeya Dwivedi <memxor@gmail.com> Date: Sun Nov 3 14:59:38 2024 -0800 bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable [ Upstream commit 46f7ed32f7a873d6675ea72e1d6317df41a55f81 ] There are three situations when a program logically exits and transfers control to the kernel or another program: bpf_throw, BPF_EXIT, and tail calls. The former two check for any lingering locks and references, but tail calls currently do not. Expand the checks to check for spin locks, RCU read sections and preempt disabled sections. Spin locks are indirectly preventing tail calls as function calls are disallowed, but the checks for preemption and RCU are more relaxed, hence ensure tail calls are prevented in their presence. Fixes: 9bb00b2895cb ("bpf: Add kfunc bpf_rcu_read_lock/unlock()") Fixes: fc7566ad0a82 ("bpf: Introduce bpf_preempt_[disable,enable] kfuncs") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20241103225940.1408302-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8cc6aaeca20c3896b43f930cfa55b82c2fef287a Author: Leon Hwang <leon.hwang@linux.dev> Date: Thu Oct 31 23:28:44 2024 +0800 bpf, bpftool: Fix incorrect disasm pc [ Upstream commit 4d99e509c161f8610de125202c648fa4acd00541 ] This patch addresses the bpftool issue "Wrong callq address displayed"[0]. The issue stemmed from an incorrect program counter (PC) value used during disassembly with LLVM or libbfd. For LLVM: The PC argument must represent the actual address in the kernel to compute the correct relative address. For libbfd: The relative address can be adjusted by adding func_ksym within the custom info->print_address_func to yield the correct address. Links: [0] https://github.com/libbpf/bpftool/issues/109 Changes: v2 -> v3: * Address comment from Quentin: * Remove the typedef. v1 -> v2: * Fix the broken libbfd disassembler. Fixes: e1947c750ffe ("bpftool: Refactor disassembler for JIT-ed programs") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Tested-by: Quentin Monnet <qmo@kernel.org> Reviewed-by: Quentin Monnet <qmo@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20241031152844.68817-1-leon.hwang@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1373043bdbea1bb6ea194bf9e17e6d2ac09a8b28 Author: Zichen Xie <zichenxie0106@gmail.com> Date: Tue Oct 29 14:42:10 2024 -0500 drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk() [ Upstream commit 20c7b42d9dbd048019bfe0af39229e3014007a98 ] There may be a potential integer overflow issue in _dpu_core_perf_calc_clk(). crtc_clk is defined as u64, while mode->vtotal, mode->hdisplay, and drm_mode_vrefresh(mode) are defined as a smaller data type. The result of the calculation will be limited to "int" in this case without correct casting. In screen with high resolution and high refresh rate, integer overflow may happen. So, we recommend adding an extra cast to prevent potential integer overflow. Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display") Signed-off-by: Zichen Xie <zichenxie0106@gmail.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/622206/ Link: https://lore.kernel.org/r/20241029194209.23684-1-zichenxie0106@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0ec90ac5f7bd9dd573bd5d964cbdc3beaa93a33e Author: Linus Walleij <linus.walleij@linaro.org> Date: Mon Oct 28 23:06:53 2024 +0100 wifi: cw1200: Fix potential NULL dereference [ Upstream commit 2b94751626a6d49bbe42a19cc1503bd391016bd5 ] A recent refactoring was identified by static analysis to cause a potential NULL dereference, fix this! Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202410121505.nyghqEkK-lkp@intel.com/ Fixes: 2719a9e7156c ("wifi: cw1200: Convert to GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241028-cw1200-fix-v1-1-e092b6558d1e@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit c61e6e0fa5c69964af6b097ffa01cb252767b70d Author: Yuan Can <yuancan@huawei.com> Date: Tue Oct 22 17:04:53 2024 +0800 wifi: wfx: Fix error handling in wfx_core_init() [ Upstream commit 3b88a9876779b55478a4dde867e73f7a100ffa23 ] The wfx_core_init() returns without checking the retval from sdio_register_driver(). If the sdio_register_driver() failed, the module failed to install, leaving the wfx_spi_driver not unregistered. Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit ce7e62bbd55d20cf250396eb4e8f65b3b5a5e685 Author: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com> Date: Mon Oct 28 14:39:40 2024 +0100 drm: xlnx: zynqmp_disp: layer may be null while releasing [ Upstream commit 223842c7702b52846b1c5aef8aca7474ec1fd29b ] layer->info can be null if we have an error on the first layer in zynqmp_disp_create_layers Fixes: 1836fd5ed98d ("drm: xlnx: zynqmp_dpsub: Minimize usage of global flag") Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028133941.54264-1-lists@steffen.cc Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4fb97432e28a7e136b2d76135d50e988ada8e1af Author: Sean Anderson <sean.anderson@linux.dev> Date: Fri Aug 9 15:35:53 2024 -0400 drm: zynqmp_kms: Unplug DRM device before removal [ Upstream commit 2e07c88914fc5289c21820b1aa94f058feb38197 ] Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver's internals. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Closes: https://lore.kernel.org/dri-devel/4d8f4c9b-2efb-4774-9a37-2f257f79b2c9@linux.dev/ Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240809193600.3360015-2-sean.anderson@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org> commit 22b4a623c0f230540f02f4358744cce62ae12dbf Author: Li Huafei <lihuafei1@huawei.com> Date: Sun Oct 27 01:38:44 2024 +0800 drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new() [ Upstream commit a2f599046c671d6b46d93aed95b37241ce4504cf ] When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex before returning the error. Fixes smatch warning: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'. Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generate golden context during first object alloc") Signed-off-by: Li Huafei <lihuafei1@huawei.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241026173844.2392679-1-lihuafei1@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3cf46e8572398e0369c0613be709e2b8de2997d4 Author: Fangzhi Zuo <Jerry.Zuo@amd.com> Date: Tue Oct 15 14:22:32 2024 -0400 drm/amd/display: Reduce HPD Detection Interval for IPS [ Upstream commit a88b19b13fb41a3fa03ec67b5f57cc267fbfb160 ] Fix DP Compliance test 4.2.1.3, 4.2.2.8, 4.3.1.12, 4.3.1.13 when IPS enabled. Original HPD detection interval is set to 5s which violates DP compliance. Reduce the interval parameter, such that link training can be finished within 5 seconds. Fixes: afca033f10d3 ("drm/amd/display: Add periodic detection for IPS") Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Tom Chung <chiahsuan.chung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 15ce655892c4a434e3044a2457eac9550f84b8c4 Author: Roman Li <Roman.Li@amd.com> Date: Mon Sep 30 18:07:16 2024 -0400 drm/amd/display: Increase idle worker HPD detection time [ Upstream commit 60612f75992d96955fb7154468c58d5d168cf1ab ] [Why] Idle worker thread waits HPD_DETECTION_TIME for HPD processing complete. Some displays require longer time for that. [How] Increase HPD_DETECTION_TIME to 100ms. Reviewed-by: Sun peng Li <sunpeng.li@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: a88b19b13fb4 ("drm/amd/display: Reduce HPD Detection Interval for IPS") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 394c9c7cb83879733de50fdd63448e75c89bc65f Author: Lucas Stach <l.stach@pengutronix.de> Date: Fri Jul 5 22:00:09 2024 +0200 drm/etnaviv: hold GPU lock across perfmon sampling [ Upstream commit 37dc4737447a7667f8e9ec790dac251da057eb27 ] The perfmon sampling mutates shared GPU state (e.g. VIVS_HI_CLOCK_CONTROL to select the pipe for the perf counter reads). To avoid clashing with other functions mutating the same state (e.g. etnaviv_gpu_update_clock) the perfmon sampling needs to hold the GPU lock. Fixes: 68dc0b295dcb ("drm/etnaviv: use 'sync points' for performance monitor requests") Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2a63fa182cb8ea1aa5d8cc802732a242f35e72f6 Author: Xiaolei Wang <xiaolei.wang@windriver.com> Date: Wed Oct 2 07:34:30 2024 +0800 drm/etnaviv: Request pages from DMA32 zone on addressing_limited [ Upstream commit 13c96ac9a3f0f1c7ba1ff0656ea508e7fa065e7e ] Remove __GFP_HIGHMEM when requesting a page from DMA32 zone, and since all vivante GPUs in the system will share the same DMA constraints, move the check of whether to get a page from DMA32 to etnaviv_bind(). Fixes: b72af445cd38 ("drm/etnaviv: request pages from DMA32 zone when needed") Suggested-by: Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 94c81abcbdee13c31ab27c67ce9122595c8e6635 Author: Suraj Kandpal <suraj.kandpal@intel.com> Date: Fri Oct 25 21:38:35 2024 +0530 drm/xe/hdcp: Fix gsc structure check in fw check status [ Upstream commit 182a32bcc223203c57761889fac7fa2dbb34684b ] Fix the condition for gsc structure validity in gsc_cs_status_check(). It needs to be an OR and not an AND condition Fixes: b4224f6bae38 ("drm/xe/hdcp: Check GSC structure validity") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025160834.8785-1-suraj.kandpal@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 10049302eef7dea6001b11dcd7ebe2d5bc52afa8 Author: Lukasz Luba <lukasz.luba@arm.com> Date: Fri Oct 18 12:18:11 2024 +0100 drm/msm/gpu: Check the status of registration to PM QoS [ Upstream commit 8f32ddd87e499ba6d2dc74ce30b6932baf1e1fc3 ] There is a need to check the returned value of the registration function. In case of returned error, print that and stop the init process. Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Patchwork: https://patchwork.freedesktop.org/patch/620336/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d6a43ae7b0014e0c0f32d625d239ff23d642be76 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Thu Sep 12 16:30:20 2024 +0800 drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 394679f322649d06fea3c646ba65f5a0887f52c3 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Patchwork: https://patchwork.freedesktop.org/patch/614075/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d37f16ba4f179a077d7272fb5f137d24f31464c3 Author: Xu Kuohai <xukuohai@huawei.com> Date: Fri Oct 25 16:52:20 2024 +0800 bpf, arm64: Remove garbage frame for struct_ops trampoline [ Upstream commit 87cb58aebdf7005661a07e9fd5a900f924d48c75 ] The callsite layout for arm64 fentry is: mov x9, lr nop When a bpf prog is attached, the nop instruction is patched to a call to bpf trampoline: mov x9, lr bl <bpf trampoline> So two return addresses are passed to bpf trampoline: the return address for the traced function/prog, stored in x9, and the return address for the bpf trampoline itself, stored in lr. To obtain a full and accurate call stack, the bpf trampoline constructs two fake function frames using x9 and lr. However, struct_ops progs are invoked directly as function callbacks, meaning that x9 is not set as it is in the fentry callsite. In this case, the frame constructed using x9 is garbage. The following stack trace for struct_ops, captured by perf sampling, illustrates this issue, where tcp_ack+0x404 is a garbage frame: ffffffc0801a04b4 bpf_prog_50992e55a0f655a9_bpf_cubic_cong_avoid+0x98 (bpf_prog_50992e55a0f655a9_bpf_cubic_cong_avoid) ffffffc0801a228c [unknown] ([kernel.kallsyms]) // bpf trampoline ffffffd08d362590 tcp_ack+0x798 ([kernel.kallsyms]) // caller for bpf trampoline ffffffd08d3621fc tcp_ack+0x404 ([kernel.kallsyms]) // garbage frame ffffffd08d36452c tcp_rcv_established+0x4ac ([kernel.kallsyms]) ffffffd08d375c58 tcp_v4_do_rcv+0x1f0 ([kernel.kallsyms]) ffffffd08d378630 tcp_v4_rcv+0xeb8 ([kernel.kallsyms]) To fix it, construct only one frame using lr for struct_ops. The above stack trace also indicates that there is no kernel symbol for struct_ops bpf trampoline. This will be addressed in a follow-up patch. Fixes: efc9909fdce0 ("bpf, arm64: Add bpf trampoline for arm64") Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Acked-by: Puranjay Mohan <puranjay@kernel.org> Tested-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20241025085220.533949-1-xukuohai@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1c12f6efe88028f02d0daf236e3fca7b11a2b295 Author: Steven Price <steven.price@arm.com> Date: Fri Oct 25 15:00:07 2024 +0100 drm/panfrost: Remove unused id_mask from struct panfrost_model [ Upstream commit 581d1f8248550f2b67847e6d84f29fbe3751ea0a ] The id_mask field of struct panfrost_model has never been used. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241025140008.385081-1-steven.price@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit fc465ef07aa639709dfc2f544d0cd6c96d4e9503 Author: Andrii Nakryiko <andrii@kernel.org> Date: Tue Oct 22 21:39:07 2024 -0700 libbpf: move global data mmap()'ing into bpf_object__load() [ Upstream commit 137978f422516a128326df55c0ba23605f925e21 ] Since BPF skeleton inception libbpf has been doing mmap()'ing of global data ARRAY maps in bpf_object__load_skeleton() API, which is used by code generated .skel.h files (i.e., by BPF skeletons only). This is wrong because if BPF object is loaded through generic bpf_object__load() API, global data maps won't be re-mmap()'ed after load step, and memory pointers returned from bpf_map__initial_value() would be wrong and won't reflect the actual memory shared between BPF program and user space. bpf_map__initial_value() return result is rarely used after load, so this went unnoticed for a really long time, until bpftrace project attempted to load BPF object through generic bpf_object__load() API and then used BPF subskeleton instantiated from such bpf_object. It turned out that .data/.rodata/.bss data updates through such subskeleton was "blackholed", all because libbpf wouldn't re-mmap() those maps during bpf_object__load() phase. Long story short, this step should be done by libbpf regardless of BPF skeleton usage, right after BPF map is created in the kernel. This patch moves this functionality into bpf_object__populate_internal_map() to achieve this. And bpf_object__load_skeleton() is now simple and almost trivial, only propagating these mmap()'ed pointers into user-supplied skeleton structs. We also do trivial adjustments to error reporting inside bpf_object__populate_internal_map() for consistency with the rest of libbpf's map-handling code. Reported-by: Alastair Robertson <ajor@meta.com> Reported-by: Jonathan Wiepert <jwiepert@meta.com> Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20241023043908.3834423-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9bb1c0c79cbb91f69dbe42bcd6e577064c762252 Author: Andrii Nakryiko <andrii@kernel.org> Date: Tue Oct 22 21:39:06 2024 -0700 selftests/bpf: fix test_spin_lock_fail.c's global vars usage [ Upstream commit 1b2bfc29695d273492c3dd8512775261f3272686 ] Global variables of special types (like `struct bpf_spin_lock`) make underlying ARRAY maps non-mmapable. To make this work with libbpf's mmaping logic, application is expected to declare such special variables as static, so libbpf doesn't even attempt to mmap() such ARRAYs. test_spin_lock_fail.c didn't follow this rule, but given it relied on this test to trigger failures, this went unnoticed, as we never got to the step of mmap()'ing these ARRAY maps. It is fragile and relies on specific sequence of libbpf steps, which are an internal implementation details. Fix the test by marking lockA and lockB as static. Fixes: c48748aea4f8 ("selftests/bpf: Add failure test cases for spin lock pairing") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20241023043908.3834423-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 54e8b501b3ea9371e4a9aa639c75b681fa5680f0 Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 19:16:16 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c [ Upstream commit 69297b0d3369488af259e3a7cf53d69157938ea1 ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 8e67558177f8 ("octeontx2-pf: PFC config support with DCBx") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 20e06a5137a1174214bae3a29ce623e69455ee0f Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 19:13:54 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c [ Upstream commit f5b942e6c54b13246ee49d42dcfb71b7f29e3c64 ] Add error pointer checks after calling otx2_mbox_get_rsp(). Fixes: 79d2be385e9e ("octeontx2-pf: offload DMAC filters to CGX/RPM block") Fixes: fa5e0ccb8f3a ("octeontx2-pf: Add support for exact match table.") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 41f39f4c67253f802809310be6846ff408c3c758 Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 19:10:36 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c [ Upstream commit ac9183023b6a9c09467516abd8aab04f9a2f9564 ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 2ca89a2c3752 ("octeontx2-pf: TC_MATCHALL ingress ratelimiting offload") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a479b3d7586e6f77f8337bbcac980eaf2d0a4029 Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 19:08:44 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c [ Upstream commit bd3110bc102ab6292656b8118be819faa0de8dd0 ] Adding error pointer check after calling otx2_mbox_get_rsp(). Fixes: 9917060fc30a ("octeontx2-pf: Cleanup flow rule management") Fixes: f0a1913f8a6f ("octeontx2-pf: Add support for ethtool ntuple filters") Fixes: 674b3e164238 ("octeontx2-pf: Add additional checks while configuring ucast/bcast/mcast rules") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6cda142cee032b8fe65ee11f78721721c3988feb Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 19:02:29 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c [ Upstream commit e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: 75f36270990c ("octeontx2-pf: Support to enable/disable pause frames via ethtool") Fixes: d0cf9503e908 ("octeontx2-pf: ethtool fec mode support") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4b88b202cf1ae79159a94fff9500f9be31559235 Author: Dipendra Khadka <kdipendra88@gmail.com> Date: Thu Oct 17 18:56:33 2024 +0000 octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c [ Upstream commit 0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 ] Add error pointer check after calling otx2_mbox_get_rsp(). Fixes: ab58a416c93f ("octeontx2-pf: cn10k: Get max mtu supported from admin function") Signed-off-by: Dipendra Khadka <kdipendra88@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d83503125b0366cb4d4102a4a7d5c40ad601e749 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu Sep 5 06:26:15 2024 +0300 drm/msm/dpu: drop LM_3 / LM_4 on MSM8998 [ Upstream commit c59afe50773d5c972f6684f9bbd9a2ddb2fb92fa ] On the MSM8998 platform ther are no LM_3 and LM_4 blocks. Drop them from the MSM8998 catalog. Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog") Reported-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/612585/ Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-3-3363d03998bd@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit bd5647b4573bfb7dbc23ae0a68381ce66fd6fc9c Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu Sep 5 06:26:14 2024 +0300 drm/msm/dpu: drop LM_3 / LM_4 on SDM845 [ Upstream commit d39271061d67c6fcbe8f361c532b493069232cf8 ] On the SDM845 platform ther are no LM_3 and LM_4 blocks. Drop them from the SDM845 catalog. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/612586/ Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-2-3363d03998bd@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8f4abfee26ac3dfae8611b17f77470be4483ab90 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Thu Sep 5 06:26:13 2024 +0300 drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block [ Upstream commit 768a272d5357269b17b4b06dd8647e21bdc0ca3c ] On the SDM845 platform the DSPP_3 is used by the LM_5. Correct corresponding entries in the sdm845_lm array. Fixes: c72375172194 ("drm/msm/dpu/catalog: define DSPP blocks found on sdm845") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/612584/ Link: https://lore.kernel.org/r/20240905-dpu-fix-sdm845-catalog-v1-1-3363d03998bd@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8a79ceb152822c5dc0ee4fbe582d528cc463e3f8 Author: Ryan Walklin <ryan@testtoast.com> Date: Sun Oct 20 21:37:41 2024 +1300 drm: panel: nv3052c: correct spi_device_id for RG35XX panel [ Upstream commit 45608a3eb4902f32010a8328c0a01ccda4b38c9b ] The Anbernic RG35XX devices use an SPI LCD panel from an unknown OEM, with an NV3052C driver chip. As discussed previously, the integrating vendor and device name are preferred instead of the OEM serial. A previous patch corrected the device tree binding and of_device_id in the NV3052C driver, however the spi_device_id also needs correction. Correct the spi_device_id for the RG35XX panel. Signed-off-by: Ryan Walklin <ryan@testtoast.com> Fixes: 76dce2a96c0f ("drm: panel: nv3052c: Correct WL-355608-A8 panel compatible") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241020083836.175733-1-ryan@testtoast.com [DB: corrected the Fixes tag] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b39705c3610b4c8ac7d583f43324a3c15a96f928 Author: Matthias Schiffer <matthias.schiffer@tq-group.com> Date: Thu Sep 26 07:55:51 2024 +0200 drm: fsl-dcu: enable PIXCLK on LS1021A [ Upstream commit ffcde9e44d3e18fde3d18bfff8d9318935413bfd ] The PIXCLK needs to be enabled in SCFG before accessing certain DCU registers, or the access will hang. For simplicity, the PIXCLK is enabled unconditionally, resulting in increased power consumption. Signed-off-by: Matthias Schiffer <matthias.schiffer@tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Fixes: 109eee2f2a18 ("drm/layerscape: Add Freescale DCU DRM driver") Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926055552.1632448-2-alexander.stein@ew.tq-group.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e2de22e4b6213371d9e76f74a10ce817572a8d74 Author: Alper Nebi Yasak <alpernebiyasak@gmail.com> Date: Tue Oct 8 01:20:54 2024 +0300 wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan() [ Upstream commit d241a139c2e9f8a479f25c75ebd5391e6a448500 ] Replace one-element array with a flexible-array member in `struct mwifiex_ie_types_wildcard_ssid_params` to fix the following warning on a MT8173 Chromebook (mt8173-elm-hana): [ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241007222301.24154-1-alpernebiyasak@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit f27d4f33a3da487b7c9b1000d489d982dafb3ccf Author: Marek Vasut <marex@denx.de> Date: Thu Oct 3 15:24:17 2024 +0200 wifi: wilc1000: Set MAC after operation mode [ Upstream commit 29dd3e48b9bd88bf65a1e760126fa18d1def7b30 ] It seems it is necessary to set WILC MAC address after operation mode, otherwise the MAC address of the WILC MAC is reset back to what is in nvmem. This causes a failure to associate with AP after the WILC MAC address was overridden by userspace. Test case: " ap$ cat << EOF > hostap.conf interface=wlan0 ssid=ssid hw_mode=g channel=6 wpa=2 wpa_passphrase=pass wpa_key_mgmt=WPA-PSK EOF ap$ hostapd -d hostap.conf ap$ ifconfig wlan0 10.0.0.1 " " sta$ ifconfig wlan0 hw ether 00:11:22:33:44:55 sta$ wpa_supplicant -i wlan0 -c <(wpa_passphrase ssid pass) sta$ ifconfig wlan0 10.0.0.2 sta$ ping 10.0.0.1 # fails without this patch " AP still indicates SA with original MAC address from nvmem without this patch: " nl80211: RX frame da=ff:ff:ff:ff:ff:ff sa=60:01:23:45:67:89 bssid=ff:ff:ff:ff:ff:ff ... ^^^^^^^^^^^^^^^^^ " Fixes: 83d9b54ee5d4 ("wifi: wilc1000: read MAC address from fuse at probe") Tested-by: Alexis Lothoré <alexis.lothore@bootlin.com> Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241003132504.52233-1-marex@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6a23c19e510bb0a5707bb9e0171925fb4f9a775c Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Sat Oct 12 20:37:31 2024 +0000 selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap [ Upstream commit b29e231d66303c12b7b8ac3ac2a057df06b161e8 ] txmsg_redir in "Test pull + redirect" case of test_txmsg_pull should be 1 instead of 0. Fixes: 328aa08a081b ("bpf: Selftests, break down test_sockmap into subtests") Acked-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241012203731.1248619-3-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6a2ff9c7433d3d84e9e45659c2ce9666d281b0de Author: Zijian Zhang <zijianzhang@bytedance.com> Date: Sat Oct 12 20:37:30 2024 +0000 selftests/bpf: Fix msg_verify_data in test_sockmap [ Upstream commit ee9b352ce4650ffc0d8ca0ac373d7c009c7e561e ] Function msg_verify_data should have context of bytes_cnt and k instead of assuming they are zero. Otherwise, test_sockmap with data integrity test will report some errors. I also fix the logic related to size and index j 1/ 6 sockmap::txmsg test passthrough:FAIL 2/ 6 sockmap::txmsg test redirect:FAIL 7/12 sockmap::txmsg test apply:FAIL 10/11 sockmap::txmsg test push_data:FAIL 11/17 sockmap::txmsg test pull-data:FAIL 12/ 9 sockmap::txmsg test pop-data:FAIL 13/ 1 sockmap::txmsg test push/pop data:FAIL ... Pass: 24 Fail: 52 After applying this patch, some of the errors are solved, but for push, pull and pop, we may need more fixes to msg_verify_data, added a TODO 10/11 sockmap::txmsg test push_data:FAIL 11/17 sockmap::txmsg test pull-data:FAIL 12/ 9 sockmap::txmsg test pop-data:FAIL ... Pass: 37 Fail: 15 Besides, added a custom errno EDATAINTEGRITY for msg_verify_data, we shall not ignore the error in txmsg_cork case. Fixes: 753fb2ee0934 ("bpf: sockmap, add msg_peek tests to test_sockmap") Fixes: 16edddfe3c5d ("selftests/bpf: test_sockmap, check test failure") Acked-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com> Link: https://lore.kernel.org/r/20241012203731.1248619-2-zijianzhang@bytedance.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f4302986bb09acfd5f673ae7282f4fa76641e85e Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: Wed Nov 8 13:27:23 2023 +0200 drm/bridge: tc358767: Fix link properties discovery [ Upstream commit 2d343723c7e1f9f6d64f721f07cfdfc2993758d1 ] When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR, tc358767 will behave properly and skip the creation of the connector. However, tc_get_display_props(), which is used to find out about the DP monitor and link, is only called from two places: .atomic_enable() and tc_connector_get_modes(). The latter is only used when tc358767 creates its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_ set. Thus, the driver never finds out the link properties before get_edid() is called. With num_lanes of 0 and link_rate of 0 there are not many valid modes... Fix this by adding tc_get_display_props() call at the beginning of get_edid(), so that we have up to date information before looking at the modes. Reported-by: Jan Kiszka <jan.kiszka@siemens.com> Closes: https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8205@siemens.com/ Fixes: de5e6c027ae6 ("drm/bridge: tc358767: add drm_panel_bridge support") Reviewed-by: Aradhya Bhatia <a-bhatia1@ti.com> Tested-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108-tc358767-v2-2-25c5f70a2159@ideasonboard.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit fd8d9e4399a51aa20d7d733188363dd15539d8fa Author: Hangbin Liu <liuhangbin@gmail.com> Date: Thu Oct 10 04:00:26 2024 +0000 netdevsim: copy addresses for both in and out paths [ Upstream commit 2cf567f421dbfe7e53b7e5ddee9400da10efb75d ] The current code only copies the address for the in path, leaving the out path address set to 0. This patch corrects the issue by copying the addresses for both the in and out paths. Before this patch: # cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec SA count=2 tx=20 sa[0] tx ipaddr=0.0.0.0 sa[0] spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1 sa[0] key=0x3167608a ca4f1397 43565909 941fa627 sa[1] rx ipaddr=192.168.0.1 sa[1] spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1 sa[1] key=0x3167608a ca4f1397 43565909 941fa627 After this patch: = cat /sys/kernel/debug/netdevsim/netdevsim0/ports/0/ipsec SA count=2 tx=20 sa[0] tx ipaddr=192.168.0.2 sa[0] spi=0x00000100 proto=0x32 salt=0x0adecc3a crypt=1 sa[0] key=0x3167608a ca4f1397 43565909 941fa627 sa[1] rx ipaddr=192.168.0.1 sa[1] spi=0x00000101 proto=0x32 salt=0x0adecc3a crypt=1 sa[1] key=0x3167608a ca4f1397 43565909 941fa627 Fixes: 7699353da875 ("netdevsim: add ipsec offload testing") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Link: https://patch.msgid.link/20241010040027.21440-3-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 035defb4d367eb7478249681c000d16f7997e8c6 Author: Andrii Nakryiko <andrii@kernel.org> Date: Thu Oct 10 14:17:30 2024 -0700 libbpf: never interpret subprogs in .text as entry programs [ Upstream commit db089c9158c1d535a36dfc010e5db37fccea2561 ] Libbpf pre-1.0 had a legacy logic of allowing singular non-annotated (i.e., not having explicit SEC() annotation) function to be treated as sole entry BPF program (unless there were other explicit entry programs). This behavior was dropped during libbpf 1.0 transition period (unless LIBBPF_STRICT_SEC_NAME flag was unset in libbpf_mode). When 1.0 was released and all the legacy behavior was removed, the bug slipped through leaving this legacy behavior around. Fix this for good, as it actually causes very confusing behavior if BPF object file only has subprograms, but no entry programs. Fixes: bd054102a8c7 ("libbpf: enforce strict libbpf 1.0 behaviors") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20241010211731.4121837-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f2c82fddede4e8e7fb24e453ee6afc0c8570e7e6 Author: Everest K.C <everestkc@everestkc.com.np> Date: Thu Oct 10 11:57:54 2024 -0600 ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c [ Upstream commit 22206e569fb54bf9c95db9a0138a7485ba9e13bc ] As the same condition was checked in inner and outer if statements. The code never reaches the inner else statement. Fix this by removing the logically dead inner else statement. Fixes: 7f5d6036ca00 ("ASoC: rt722-sdca: Add RT722 SDCA driver") Reported-by: Shuah Khan <skhan@linuxfoundation.org> Closes: https://lore.kernel.org/all/e44527e8-b7c6-4712-97a6-d54f02ad2dc9@linuxfoundation.org/ Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://patch.msgid.link/20241010175755.5278-1-everestkc@everestkc.com.np Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit cac822772c4dc27a285f09caf30072ab76d2bf38 Author: Karol Wachowski <karol.wachowski@intel.com> Date: Mon Sep 30 21:53:13 2024 +0200 accel/ivpu: Prevent recovery invocation during probe and resume [ Upstream commit 5eaa497411197c41b0813d61ba3fbd6267049082 ] Refactor IPC send and receive functions to allow correct handling of operations that should not trigger a recovery process. Expose ivpu_send_receive_internal(), which is now utilized by the D0i3 entry, DCT initialization, and HWS initialization functions. These functions have been modified to return error codes gracefully, rather than initiating recovery. The updated functions are invoked within ivpu_probe() and ivpu_resume(), ensuring that any errors encountered during these stages result in a proper teardown or shutdown sequence. The previous approach of triggering recovery within these functions could lead to a race condition, potentially causing undefined behavior and kernel crashes due to null pointer dereferences. Fixes: 45e45362e095 ("accel/ivpu: Introduce ivpu_ipc_send_receive_active()") Signed-off-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930195322.461209-23-jacek.lawrynowicz@linux.intel.com Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit be8f3d1e4b8731bf133e554ee703cfdadb394c6c Author: Andrii Nakryiko <andrii@kernel.org> Date: Tue Oct 8 18:15:54 2024 -0700 libbpf: fix sym_is_subprog() logic for weak global subprogs [ Upstream commit 4073213488be542f563eb4b2457ab4cbcfc2b738 ] sym_is_subprog() is incorrectly rejecting relocations against *weak* global subprogs. Fix that by realizing that STB_WEAK is also a global function. While it seems like verifier doesn't support taking an address of non-static subprog right now, it's still best to fix support for it on libbpf side, otherwise users will get a very confusing error during BPF skeleton generation or static linking due to misinterpreted relocation: libbpf: prog 'handle_tp': bad map relo against 'foo' in section '.text' Error: failed to open BPF object file: Relocation failed It's clearly not a map relocation, but is treated and reported as such without this fix. Fixes: 53eddb5e04ac ("libbpf: Support subprog address relocation") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20241009011554.880168-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0af05e8c7d40f889fc9d3db2e5a1b8533994e68d Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Tue Oct 8 17:44:36 2024 +0100 drm/vc4: Correct generation check in vc4_hvs_lut_load [ Upstream commit 42aa18d1c3e7762bcebd89a5857ed7774e669d92 ] Commit 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum") incorrectly swapped a check of hvs->vc4->is_vc5 to hvs->vc4->gen == VC4_GEN_4 in vc4_hvs_lut_load, hence breaking loading the gamma look up table on Pi0-3. Correct that conditional. Fixes: 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5752@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-3-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 419fc2aabc17e8cca71b530c716a129e4b9f7d86 Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Tue Oct 8 17:44:35 2024 +0100 drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush [ Upstream commit 6b0bd1b02ea24b10522c92b2503981970b26d1a2 ] Commit 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we're disabled") added a path which returned early without having called drm_dev_exit. Ensure all paths call drm_dev_exit. Fixes: 92c17d16476c ("drm/vc4: hvs: Ignore atomic_flush if we're disabled") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-2-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 731a6bb68a973df47f6e00622bf4f99933b3d56a Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Tue Oct 8 17:44:34 2024 +0100 drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load [ Upstream commit cf1c87d978d47339a39bfa7a6133ecd3f8f87525 ] Commit 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711") added a return path to vc4_hvs_lut_load that had called drm_dev_enter, but not drm_dev_exit. Ensure we call drm_dev_exit. Fixes: 52efe364d196 ("drm/vc4: hvs: Don't write gamma luts on 2711") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5752@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-1-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9b73d0363ff3e513381c16d9d100f4a949b8df21 Author: Maxime Ripard <mripard@kernel.org> Date: Fri Jun 21 16:20:44 2024 +0100 drm/vc4: Introduce generation number enum [ Upstream commit 24c5ed3ddf27313b248900455b0312bd7a9d3554 ] With the introduction of the BCM2712 support, we will get yet another generation of display engine to support. The binary check of whether it's VC5 or not thus doesn't work anymore, especially since some parts of the driver will have changed with BCM2711, and some others with BCM2712. Let's introduce an enum to store the generation the driver is running on, which should provide more flexibility. Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-21-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Stable-dep-of: cf1c87d978d4 ("drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 27ae4460a8585ce8e1b899c2b9a758df97335801 Author: Dom Cobley <popcornmix@gmail.com> Date: Fri Jun 21 16:20:31 2024 +0100 drm/vc4: hdmi: Increase audio MAI fifo dreq threshold [ Upstream commit 59f8b2b7fb8e460881d21c7d5b32604993973879 ] Now we wait for write responses and have a burst size of 4, we can set the fifo threshold much higher. Set it to 28 (of the 32 entry size) to keep fifo fuller and reduce chance of underflow. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-8-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Stable-dep-of: cf1c87d978d4 ("drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 937d495524438c6817b92302aa550f2f56996b58 Author: Jacob Keller <jacob.e.keller@intel.com> Date: Mon Sep 9 16:07:44 2024 -0700 ice: consistently use q_idx in ice_vc_cfg_qs_msg() [ Upstream commit a884c304e18a40e1c7a6525a9274e64c2c061c3f ] The ice_vc_cfg_qs_msg() function is used to configure VF queues in response to a VIRTCHNL_OP_CONFIG_VSI_QUEUES command. The virtchnl command contains an array of queue pair data for configuring Tx and Rx queues. This data includes a queue ID. When configuring the queues, the driver generally uses this queue ID to determine which Tx and Rx ring to program. However, a handful of places use the index into the queue pair data from the VF. While most VF implementations appear to send this data in order, it is not mandated by the virtchnl and it is not verified that the queue pair data comes in order. Fix the driver to consistently use the q_idx field instead of the 'i' iterator value when accessing the rings. For the Rx case, introduce a local ring variable to keep lines short. Fixes: 7ad15440acf8 ("ice: Refactor VIRTCHNL_OP_CONFIG_VSI_QUEUES handling") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4f8a5c43f2fa30c792ade24a573e00b964423d1d Author: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Date: Tue Sep 17 19:32:39 2024 +0530 wifi: cfg80211: check radio iface combination for multi radio per wiphy [ Upstream commit bd9813d13be439851a7ff3e6372e53caa6e387a6 ] Currently, wiphy_verify_combinations() fails for the multi-radio per wiphy due to the condition check on new global interface combination that DFS only works on one channel. In a multi-radio scenario, new global interface combination encompasses the capabilities of all radio combinations, so it supports more than one channel with DFS. For multi-radio per wiphy, interface combination verification needs to be performed for radio specific interface combinations. This is necessary as the new global interface combination combines the capabilities of all radio combinations. Fixes: a01b1e9f9955 ("wifi: mac80211: add support for DFS with multiple radios") Signed-off-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://patch.msgid.link/20240917140239.886083-1-quic_periyasa@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3a0df0c598f646c4e654c6f6a8fb3a9abad90ae1 Author: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> Date: Tue Oct 8 16:50:57 2024 +0200 selftests/bpf: add missing header include for htons [ Upstream commit bc9b3fb827fceec4e05564d6e668280f4470ab5b ] Including the network_helpers.h header in tests can lead to the following build error: ./network_helpers.h: In function ‘csum_tcpudp_magic’: ./network_helpers.h:116:14: error: implicit declaration of function \ ‘htons’ [-Werror=implicit-function-declaration] 116 | s += htons(proto + len); The error is avoided in many cases thanks to some other headers included earlier and bringing in arpa/inet.h (ie: test_progs.h). Make sure that test_progs build success does not depend on header ordering by adding the missing header include in network_helpers.h Fixes: f6642de0c3e9 ("selftests/bpf: Add csum helpers") Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com> Link: https://lore.kernel.org/r/20241008-network_helpers_fix-v1-1-2c2ae03df7ef@bootlin.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e6e4446113445c885c4a74a51b22b4fb00b1834e Author: Balaji Pothunoori <quic_bpothuno@quicinc.com> Date: Fri Sep 27 15:28:25 2024 +0530 wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR [ Upstream commit 4c57ec6c4bb9979b42ae7fa7273fc2d4a361d576 ] Currently, mem_ce and mem iomem addresses are used to calculate the CE offset address. mem_ce is initialized with mem address, and for targets where ce_remap is needed, mem_ce is remapped to a new address space during AHB probe. For targets such as WCN6750 in which CE address space is same as WCSS address space (i.e. "ce_remap" hw_param is set to false), mem_ce and mem iomem addresses are same. In the initial SRNG setup for such targets, the CE offset address and hence CE register base addresses are calculated correctly in ath11k_hal_srng_init() as both mem and mem_ce are initialized with same iomem address. Later, after the firmware download, mem is initialized with BAR address received in qmi_wlanfw_device_info_resp_msg_v01 QMI message, while mem_ce is not updated. After initial setup success, during Subsystem Restart (SSR), as part of reinitialization, ath11k_hal_srng_init() will be called again, and CE offset address will be calculated incorrectly this time as mem_ce address was not updated. Due to the incorrect CE offset address, APPS accesses an invalid CE register address which leads to improper behavior in firmware after SSR is triggered. To fix the above issue, update mem_ce to mem iomem address in ath11k_qmi_request_device_info() for targets which do not support ce_remap feature. Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com> Fixes: b42b3678c91f ("wifi: ath11k: remap ce register space for IPQ5018") Link: https://patch.msgid.link/20240927095825.22317-1-quic_bpothuno@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6072c6f8d3a360848df355ab244a6e31626df23c Author: Eduard Zingerman <eddyz87@gmail.com> Date: Thu Oct 3 14:03:07 2024 -0700 selftests/bpf: Fix backtrace printing for selftests crashes [ Upstream commit 5bf1557e3d6a69113649d831276ea2f97585fc33 ] test_progs uses glibc specific functions backtrace() and backtrace_symbols_fd() to print backtrace in case of SIGSEGV. Recent commit (see fixes) updated test_progs.c to define stub versions of the same functions with attriubte "weak" in order to allow linking test_progs against musl libc. Unfortunately this broke the backtrace handling for glibc builds. As it turns out, glibc defines backtrace() and backtrace_symbols_fd() as weak: $ llvm-readelf --symbols /lib64/libc.so.6 \ | grep -P '( backtrace_symbols_fd| backtrace)$' 4910: 0000000000126b40 161 FUNC WEAK DEFAULT 16 backtrace 6843: 0000000000126f90 852 FUNC WEAK DEFAULT 16 backtrace_symbols_fd So does test_progs: $ llvm-readelf --symbols test_progs \ | grep -P '( backtrace_symbols_fd| backtrace)$' 2891: 00000000006ad190 15 FUNC WEAK DEFAULT 13 backtrace 11215: 00000000006ad1a0 41 FUNC WEAK DEFAULT 13 backtrace_symbols_fd In such situation dynamic linker is not obliged to favour glibc implementation over the one defined in test_progs. Compiling with the following simple modification to test_progs.c demonstrates the issue: $ git diff ... \--- a/tools/testing/selftests/bpf/test_progs.c \+++ b/tools/testing/selftests/bpf/test_progs.c \@@ -1817,6 +1817,7 @@ int main(int argc, char **argv) if (err) return err; + *(int *)0xdeadbeef = 42; err = cd_flavor_subdir(argv[0]); if (err) return err; $ ./test_progs [0]: Caught signal #11! Stack trace: <backtrace not supported> Segmentation fault (core dumped) Resolve this by hiding stub definitions behind __GLIBC__ macro check instead of using "weak" attribute. Fixes: c9a83e76b5a9 ("selftests/bpf: Fix compile if backtrace support missing in libc") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Tested-by: Tony Ambardar <tony.ambardar@gmail.com> Reviewed-by: Tony Ambardar <tony.ambardar@gmail.com> Acked-by: Daniel Xu <dxu@dxuuu.xyz> Link: https://lore.kernel.org/bpf/20241003210307.3847907-1-eddyz87@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit db451bd64c2aca72246050c6a4b530d7d0e72211 Author: Kui-Feng Lee <thinker.li@gmail.com> Date: Wed Aug 14 22:32:51 2024 -0700 selftests/bpf: netns_new() and netns_free() helpers. [ Upstream commit 1e115a58be0ffca63727dc0495dae924a19f8cd4 ] netns_new()/netns_free() create/delete network namespaces. They support the option '-m' of test_progs to start/stop traffic monitor for the network namespace being created for matched tests. Acked-by: Stanislav Fomichev <sdf@fomichev.me> Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com> Link: https://lore.kernel.org/r/20240815053254.470944-4-thinker.li@gmail.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Stable-dep-of: 5bf1557e3d6a ("selftests/bpf: Fix backtrace printing for selftests crashes") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 802758620de31244f9d157cd56ad4d7e98344ccf Author: Yuan Chen <chenyuan@kylinos.cn> Date: Mon Sep 30 10:41:15 2024 +0800 bpf: Fix the xdp_adjust_tail sample prog issue [ Upstream commit 4236f114a3ffbbfd217436c08852e94cae372f57 ] During the xdp_adjust_tail test, probabilistic failure occurs and SKB package is discarded by the kernel. After checking the issues by tracking SKB package, it is identified that they were caused by checksum errors. Refer to checksum of the arch/arm64/include/asm/checksum.h for fixing. v2: Based on Alexei Starovoitov's suggestions, it is necessary to keep the code implementation consistent. Fixes: c6ffd1ff7856 (bpf: add bpf_xdp_adjust_tail sample prog) Signed-off-by: Yuan Chen <chenyuan@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240930024115.52841-1-chenyuan_fl@163.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2e7fc2af89e27ebb0b6ec7e26dea6885f9d9aa66 Author: Arnd Bergmann <arnd@arndb.de> Date: Fri Oct 4 09:54:13 2024 +0000 wifi: ath12k: fix one more memcpy size error [ Upstream commit 19c23eb61fa4c802e6e0aaf74d6f7dcbe99f0ba3 ] A previous patch addressed a fortified-memcpy warning on older compilers, but there is still a warning on gcc-14 in some configurations: In file included from include/linux/string.h:390, from drivers/net/wireless/ath/ath12k/wow.c:7: drivers/net/wireless/ath/ath12k/wow.c: In function 'ath12k_wow_convert_8023_to_80211.isra': include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 18446744073709551610 or more bytes at offsets 0 and 0 overlaps 9223372036854775797 bytes at offset -9223372036854775803 [-Werror=restrict] include/linux/fortify-string.h:679:26: note: in expansion of macro '__fortify_memcpy_chk' 679 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/ath/ath12k/wow.c:199:25: note: in expansion of macro 'memcpy' 199 | memcpy(pat + a3_ofs - pkt_ofs, | ^~~~~~ Address this the same way as the other two, using size_add(). Fixes: b49991d83bba ("wifi: ath12k: fix build vs old compiler") Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241004095420.637091-1-arnd@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e5e15c8b42923bfb6c84d3d906a9965d9a0f111d Author: Rameshkumar Sundaram <quic_ramess@quicinc.com> Date: Tue Oct 1 14:56:52 2024 +0530 wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup() [ Upstream commit bdb281103373fd80eb5c91cede1e115ba270b4e9 ] During ath12k module removal, in ath12k_core_deinit(), ath12k_mac_destroy() un-registers ah->hw from mac80211 and frees the ah->hw as well as all the ar's in it. After this ath12k_core_soc_destroy()-> ath12k_dp_free()-> ath12k_dp_cc_cleanup() tries to access one of the freed ar's from pending skb. This is because during mac destroy, driver failed to flush few data packets, which were accessed later in ath12k_dp_cc_cleanup() and freed, but using ar from the packet led to this use-after-free. BUG: KASAN: use-after-free in ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] Write of size 4 at addr ffff888150bd3514 by task modprobe/8926 CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted 6.11.0-rc2-wt-ath+ #1746 Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 Call Trace: <TASK> dump_stack_lvl+0x7d/0xe0 print_address_description.constprop.0+0x33/0x3a0 print_report+0xb5/0x260 ? kasan_addr_to_slab+0x24/0x80 kasan_report+0xd8/0x110 ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] ? ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] kasan_check_range+0xf3/0x1a0 __kasan_check_write+0x14/0x20 ath12k_dp_cc_cleanup.part.0+0x5e2/0xd40 [ath12k] ath12k_dp_free+0x178/0x420 [ath12k] ath12k_core_stop+0x176/0x200 [ath12k] ath12k_core_deinit+0x13f/0x210 [ath12k] ath12k_pci_remove+0xad/0x1c0 [ath12k] pci_device_remove+0x9b/0x1b0 device_remove+0xbf/0x150 device_release_driver_internal+0x3c3/0x580 ? __kasan_check_read+0x11/0x20 driver_detach+0xc4/0x190 bus_remove_driver+0x130/0x2a0 driver_unregister+0x68/0x90 pci_unregister_driver+0x24/0x240 ? find_module_all+0x13e/0x1e0 ath12k_pci_exit+0x10/0x20 [ath12k] __do_sys_delete_module+0x32c/0x580 ? module_flags+0x2f0/0x2f0 ? kmem_cache_free+0xf0/0x410 ? __fput+0x56f/0xab0 ? __fput+0x56f/0xab0 ? debug_smp_processor_id+0x17/0x20 __x64_sys_delete_module+0x4f/0x70 x64_sys_call+0x522/0x9f0 do_syscall_64+0x64/0x130 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f8182c6ac8b Commit 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery scenarios") added the change to decrement the pending packets count in case of recovery which make sense as ah->hw as well all ar's in it are intact during recovery, but during core deinit there is no use in decrementing packets count or waking up the empty waitq as the module is going to be removed also ar's from pending skb's can't be used and the packets should just be released back. To fix this, avoid accessing ar from skb->cb when driver is being unregistered. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery scenarios") Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241001092652.3134334-1-quic_ramess@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e51cbe40b77a32e8698ad8b9582e5b4fce6da364 Author: Aurabindo Pillai <aurabindo.pillai@amd.com> Date: Mon Sep 23 20:07:25 2024 +0000 drm/amd/display: fix a memleak issue when driver is removed [ Upstream commit d4f36e5fd800de7db74c1c4e62baf24a091a5ff6 ] Running "modprobe amdgpu" the second time (followed by a modprobe -r amdgpu) causes a call trace like: [ 845.212163] Memory manager not clean during takedown. [ 845.212170] WARNING: CPU: 4 PID: 2481 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x2b/0x40 [ 845.212177] Modules linked in: amdgpu(OE-) amddrm_ttm_helper(OE) amddrm_buddy(OE) amdxcp(OE) amd_sched(OE) drm_exec drm_suballoc_helper drm_display_helper i2c_algo_bit amdttm(OE) amdkcl(OE) cec rc_core sunrpc qrtr intel_rapl_msr intel_rapl_common snd_hda_codec_hdmi edac_mce_amd snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib kvm_amd snd_hda_core snd_ump mc snd_hwdep kvm snd_pcm snd_seq_midi snd_seq_midi_event irqbypass crct10dif_pclmul snd_rawmidi polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 snd_seq aesni_intel crypto_simd snd_seq_device cryptd snd_timer mfd_aaeon asus_nb_wmi eeepc_wmi joydev asus_wmi snd ledtrig_audio sparse_keymap ccp wmi_bmof input_leds k10temp i2c_piix4 platform_profile rapl soundcore gpio_amdpt mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj hid_generic usbhid hid ahci xhci_pci igc crc32_pclmul libahci xhci_pci_renesas video [ 845.212284] wmi [last unloaded: amddrm_ttm_helper(OE)] [ 845.212290] CPU: 4 PID: 2481 Comm: modprobe Tainted: G W OE 6.8.0-31-generic #31-Ubuntu [ 845.212296] RIP: 0010:drm_mm_takedown+0x2b/0x40 [ 845.212300] Code: 1f 44 00 00 48 8b 47 38 48 83 c7 38 48 39 f8 75 09 31 c0 31 ff e9 90 2e 86 00 55 48 c7 c7 d0 f6 8e 8a 48 89 e5 e8 f5 db 45 ff <0f> 0b 5d 31 c0 31 ff e9 74 2e 86 00 66 0f 1f 84 00 00 00 00 00 90 [ 845.212302] RSP: 0018:ffffb11302127ae0 EFLAGS: 00010246 [ 845.212305] RAX: 0000000000000000 RBX: ffff92aa5020fc08 RCX: 0000000000000000 [ 845.212307] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 845.212309] RBP: ffffb11302127ae0 R08: 0000000000000000 R09: 0000000000000000 [ 845.212310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004 [ 845.212312] R13: ffff92aa50200000 R14: ffff92aa5020fb10 R15: ffff92aa5020faa0 [ 845.212313] FS: 0000707dd7c7c080(0000) GS:ffff92b93de00000(0000) knlGS:0000000000000000 [ 845.212316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 845.212318] CR2: 00007d48b0aee200 CR3: 0000000115a58000 CR4: 0000000000f50ef0 [ 845.212320] PKRU: 55555554 [ 845.212321] Call Trace: [ 845.212323] <TASK> [ 845.212328] ? show_regs+0x6d/0x80 [ 845.212333] ? __warn+0x89/0x160 [ 845.212339] ? drm_mm_takedown+0x2b/0x40 [ 845.212344] ? report_bug+0x17e/0x1b0 [ 845.212350] ? handle_bug+0x51/0xa0 [ 845.212355] ? exc_invalid_op+0x18/0x80 [ 845.212359] ? asm_exc_invalid_op+0x1b/0x20 [ 845.212366] ? drm_mm_takedown+0x2b/0x40 [ 845.212371] amdgpu_gtt_mgr_fini+0xa9/0x130 [amdgpu] [ 845.212645] amdgpu_ttm_fini+0x264/0x340 [amdgpu] [ 845.212770] amdgpu_bo_fini+0x2e/0xc0 [amdgpu] [ 845.212894] gmc_v12_0_sw_fini+0x2a/0x40 [amdgpu] [ 845.213036] amdgpu_device_fini_sw+0x11a/0x590 [amdgpu] [ 845.213159] amdgpu_driver_release_kms+0x16/0x40 [amdgpu] [ 845.213302] devm_drm_dev_init_release+0x5e/0x90 [ 845.213305] devm_action_release+0x12/0x30 [ 845.213308] release_nodes+0x42/0xd0 [ 845.213311] devres_release_all+0x97/0xe0 [ 845.213314] device_unbind_cleanup+0x12/0x80 [ 845.213317] device_release_driver_internal+0x230/0x270 [ 845.213319] ? srso_alias_return_thunk+0x5/0xfbef5 This is caused by lost memory during early init phase. First time driver is removed, memory is freed but when second time the driver is inserted, VBIOS dmub is not active, since the PSP policy is to retain the driver loaded version on subsequent warm boots. Hence, communication with VBIOS DMUB fails. Fix this by aborting further communication with vbios dmub and release the memory immediately. Fixes: f59549c7e705 ("drm/amd/display: free bo used for dmub bounding box") Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4e5d50b6f35fce4b4a27028fda48f5a24b8add17 Author: Martin Kaistra <martin.kaistra@linutronix.de> Date: Mon Sep 30 10:49:55 2024 +0200 wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled [ Upstream commit d7063ed6758c62e00a2f56467ded85a021fac67a ] In STA+AP concurrent mode, performing a scan operation on one vif temporarily stops beacons on the other. When the scan is completed, beacons are enabled again with BSS_CHANGED_BEACON_ENABLED. We can observe that no beacons are being sent when just rtl8xxxu_start_tx_beacon() is being called. Thus, also perform update_beacon_work in order to restore beaconing. Fixes: cde8848cad0b ("wifi: rtl8xxxu: Add beacon functions") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240930084955.455241-1-martin.kaistra@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6cf4a37e1a5c0138677b999f4480d1083f1f8428 Author: Alexander Aring <aahringo@redhat.com> Date: Fri Oct 4 11:13:37 2024 -0400 dlm: fix swapped args sb_flags vs sb_status [ Upstream commit 6d59f2fbfb18965f76ebcff40ab38da717cde798 ] The arguments got swapped by commit 986ae3c2a8df ("dlm: fix race between final callback and remove") fixing this now. Fixes: 986ae3c2a8df ("dlm: fix race between final callback and remove") Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 327060b8fe86a9742c71763fe27a9b9733c01097 Author: Tony Ambardar <tony.ambardar@gmail.com> Date: Mon Sep 16 01:37:42 2024 -0700 libbpf: Fix output .symtab byte-order during linking [ Upstream commit f896b4a5399e97af0b451fcf04754ed316935674 ] Object linking output data uses the default ELF_T_BYTE type for '.symtab' section data, which disables any libelf-based translation. Explicitly set the ELF_T_SYM type for output to restore libelf's byte-order conversion, noting that input '.symtab' data is already correctly translated. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/87868bfeccf3f51aec61260073f8778e9077050a.1726475448.git.tony.ambardar@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 59f5cfc367ae8efd8a36977490252c7269e311d7 Author: Tao Chen <chen.dylane@gmail.com> Date: Wed Sep 25 23:30:12 2024 +0800 libbpf: Fix expected_attach_type set handling in program load callback [ Upstream commit a400d08b3014a4f4e939366bb6fd769b9caff4c9 ] Referenced commit broke the logic of resetting expected_attach_type to zero for allowed program types if kernel doesn't yet support such field. We do need to overwrite and preserve expected_attach_type for multi-uprobe though, but that can be done explicitly in libbpf_prepare_prog_load(). Fixes: 5902da6d8a52 ("libbpf: Add uprobe multi link support to bpf_program__attach_usdt") Suggested-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Tao Chen <chen.dylane@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240925153012.212866-1-chen.dylane@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 26dd231990b7d8b17d652af0734f81e93a9df503 Author: Pin-yen Lin <treapking@chromium.org> Date: Thu Sep 26 17:29:09 2024 +0800 drm/bridge: it6505: Drop EDID cache on bridge power off [ Upstream commit 574c558ddb68591c9a4b7a95e45e935ab22c0fc6 ] The bridge might miss the display change events when it's powered off. This happens when a user changes the external monitor when the system is suspended and the embedded controller doesn't not wake AP up. It's also observed that one DP-to-HDMI bridge doesn't work correctly when there is no EDID read after it is powered on. Drop the cache to force an EDID read after system resume to fix this. Fixes: 11feaef69d0c ("drm/bridge: it6505: Add caching for EDID") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926092931.3870342-3-treapking@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 619b60e0f4b34bbab7c8640a2dc9c76331beed77 Author: Pin-yen Lin <treapking@chromium.org> Date: Thu Sep 26 17:29:08 2024 +0800 drm/bridge: anx7625: Drop EDID cache on bridge power off [ Upstream commit 00ae002116a14c2e6a342c4c9ae080cdbb9b4b21 ] The bridge might miss the display change events when it's powered off. This happens when a user changes the external monitor when the system is suspended and the embedded controller doesn't not wake AP up. It's also observed that one DP-to-HDMI bridge doesn't work correctly when there is no EDID read after it is powered on. Drop the cache to force an EDID read after system resume to fix this. Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240926092931.3870342-2-treapking@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1e4ca40efc9e507bed4469c132d1e268d8e220cf Author: Geert Uytterhoeven <geert+renesas@glider.be> Date: Fri Sep 27 14:42:16 2024 +0200 ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios [ Upstream commit cfd1054c65eefec30972416a83eb62920bc1ff8d ] The DT bindings deprecated the "hp-det-gpio" and "mic-det-gpio" properties in favor of "hp-det-gpios" and "mic-det-gpios", but the driver was never updated to support the latter. Even before, there existed users of "hp-det-gpios" and "mic-det-gpios". While this may have been handled fine by the ASoC core, this was missed by the Freescale-specific part. Fixes: 4189b54220e5af15 ("ASoC: dt-bindings: fsl-asoc-card: convert to YAML") Fixes: 40ba2eda0a7b727f ("arm64: dts: imx8mm-nitrogen-r2: add audio") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://patch.msgid.link/dbcb5bfea005a468ec6dc38374fe6d02bc693c22.1727438777.git.geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9c5b553f2e5273ff6771b1ee79b0edb0ec118dbb Author: Macpaul Lin <macpaul.lin@mediatek.com> Date: Mon Sep 30 15:54:50 2024 +0800 ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode [ Upstream commit 4649cbd97fdae5069e9a71cd7669b62b90e03669 ] Some fix and updates in the following items: 1. examples: Update generic node name to 'audio-codec' to comply with the coming change in 'mt6359.dtsi'. This change is necessary to fix the dtbs_check error: pmic: 'mt6359codec' does not match any of the regexes: 'pinctrl-[0-9]+' 2. mediatek,dmic-mode: After inspecting the .dts and .dtsi files using 'mt6359-codec', it was discovered that the definitions of 'two wires' and 'one wire' are inverted compared to the DT schema. For example, the following boards using MT6359 PMIC: - mt8192-asurada.dtsi - mt8195-cherry.dtsi These boards use the same definitions of 'dmic-mode' as other boards using MT6358 PMIC. The meaning of '0' or '1' has been noted as comments in the device trees. Upon examining the code in [1] and [2], it was confirmed that the definitions of 'dmic-mode' are consistent between "MT6359 PMIC" and "MT6358 PMIC". Therefore, the DT Schema should be correct as is. References: [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6358.c#n1875 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/codecs/mt6359.c#L1515 Fixes: 539237d1c609 ("dt-bindings: mediatek: mt6359: add codec document") Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20240930075451.14196-1-macpaul.lin@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 592d561f8cd0d50a38e65d068c45029507f82b53 Author: Shengjiu Wang <shengjiu.wang@nxp.com> Date: Fri Sep 27 16:00:29 2024 +0800 ASoC: fsl_micfil: fix regmap_write_bits usage [ Upstream commit 06df673d20230afb0e383e39235a4fa8b9a62464 ] The last parameter 1 means BIT(0), which should be the correct BIT(X). Fixes: 47a70e6fc9a8 ("ASoC: Add MICFIL SoC Digital Audio Interface driver.") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/1727424031-19551-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f1665333ae68347ad94bde775dbfdc0c40c853fb Author: Igor Prusov <ivprusov@salutedevices.com> Date: Wed Sep 25 17:52:39 2024 +0300 dt-bindings: vendor-prefixes: Add NeoFidelity, Inc [ Upstream commit 5d9e6d6fc1b98c8c22d110ee931b3b233d43cd13 ] Add vendor prefix for NeoFidelity, Inc Signed-off-by: Igor Prusov <ivprusov@salutedevices.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20240925-ntp-amps-8918-8835-v3-1-e2459a8191a6@salutedevices.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a1e2d6738b29c74c2024eb23167dfff68aadd984 Author: Ramya Gnanasekar <quic_rgnanase@quicinc.com> Date: Thu Sep 5 09:58:51 2024 +0530 wifi: ath12k: Skip Rx TID cleanup for self peer [ Upstream commit 1a0c640ce1cdcde3eb131a0c1e70ca1ed7cf27cb ] During peer create, dp setup for the peer is done where Rx TID is updated for all the TIDs. Peer object for self peer will not go through dp setup. When core halts, dp cleanup is done for all the peers. While cleanup, rx_tid::ab is accessed which causes below stack trace for self peer. WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851 Call Trace: __warn+0x7b/0x1a0 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] report_bug+0x10b/0x200 handle_bug+0x3f/0x70 exc_invalid_op+0x13/0x60 asm_exc_invalid_op+0x16/0x20 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k] ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k] ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k] ath12k_core_halt+0x3b/0x100 [ath12k] ath12k_core_reset+0x494/0x4c0 [ath12k] sta object in peer will be updated when remote peer is created. Hence use peer::sta to detect the self peer and skip the cleanup. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Ramya Gnanasekar <quic_rgnanase@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240905042851.2282306-1-quic_rgnanase@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit fde7c192e6e2710247795bbd6d72a1f4b6f0cfb7 Author: Baochen Qiang <quic_bqiang@quicinc.com> Date: Thu Jul 11 10:03:44 2024 +0800 wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2 [ Upstream commit 52db16ec5bae7bd027804265b968259d1a6c3970 ] In supported_vht_mcs_rate_nss2, the rate for MCS9 & VHT20 is defined as {1560, 1733}, this does not align with firmware's definition and therefore fails the verification in ath10k_mac_get_rate_flags_vht(): invalid vht params rate 1730 100kbps nss 2 mcs 9 and: invalid vht params rate 1920 100kbps nss 2 mcs 9 Change it to {1730, 1920} to align with firmware to fix the issue. Since ath10k_hw_params::supports_peer_stats_info is enabled only for QCA6174, this change does not affect other chips. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: 3344b99d69ab ("ath10k: add bitrate parse for peer stats info") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-8402272788ff@molgen.mpg.de/ Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> # Dell XPS 13 9360 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240711020344.98040-3-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit df563cd1dde1ba3d7ab55c8a706dce13b0ee003b Author: Baochen Qiang <quic_bqiang@quicinc.com> Date: Thu Jul 11 10:03:43 2024 +0800 wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1 [ Upstream commit d50886b27850447d90c0cd40c725238097909d1e ] In supported_vht_mcs_rate_nss1, the rate for MCS9 & VHT20 is defined as {780, 867}, this does not align with firmware's definition and therefore fails the verification in ath10k_mac_get_rate_flags_vht(): invalid vht params rate 960 100kbps nss 1 mcs 9 Change it to {865, 960} to align with firmware, so this issue could be fixed. Since ath10k_hw_params::supports_peer_stats_info is enabled only for QCA6174, this change does not affect other chips. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: 3344b99d69ab ("ath10k: add bitrate parse for peer stats info") Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://lore.kernel.org/lkml/fba24cd3-4a1e-4072-8585-8402272788ff@molgen.mpg.de/ Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240711020344.98040-2-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9989df48382d9a74e6d61a50c3c4f93892b61ad9 Author: Lijo Lazar <lijo.lazar@amd.com> Date: Fri Sep 6 14:10:19 2024 +0530 drm/amdgpu: Fix JPEG v4.0.3 register write [ Upstream commit 8c50bf9beb889fd2bdcbf95b27a5d101eede51fc ] EXTERNAL_REG_INTERNAL_OFFSET/EXTERNAL_REG_WRITE_ADDR should be used in pairs. If an external register shouldn't be written, both packets shouldn't be sent. Fixes: a78b48146972 ("drm/amdgpu: Skip PCTL0_MMHUB_DEEPSLEEP_IB write in jpegv4.0.3 under SRIOV") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ace93da3a817e4fa92500600be52afd2b96975f4 Author: Maíra Canal <mcanal@igalia.com> Date: Mon Sep 23 10:55:06 2024 -0300 drm/v3d: Flush the MMU before we supply more memory to the binner [ Upstream commit d2fb8811108b2c1285c56f4fba4fff8fe3525593 ] We must ensure that the MMU is flushed before we supply more memory to the binner, otherwise we might end up with invalid MMU accesses by the GPU. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923141348.2422499-3-mcanal@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit bcb3f40988dfd59e1c1f78f1e02c084bffa9bba4 Author: Maíra Canal <mcanal@igalia.com> Date: Mon Sep 23 10:55:05 2024 -0300 drm/v3d: Address race-condition in MMU flush [ Upstream commit cf1becb7f996a0a23ea2c270cf6bb0911ec3ca1a ] We must first flush the MMU cache and then, flush the TLB, not the other way around. Currently, we can see a race condition between the MMU cache and the TLB when running multiple rendering processes at the same time. This is evidenced by MMU errors triggered by the IRQ. Fix the MMU flush order by flushing the MMU cache and then the TLB. Also, in order to address the race condition, wait for the MMU cache flush to finish before starting the TLB flush. Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923141348.2422499-2-mcanal@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 11be5252b845b1982ec883c667bf9fab03af4e6f Author: Linus Walleij <linus.walleij@linaro.org> Date: Sun Sep 8 23:50:30 2024 +0200 drm/panel: nt35510: Make new commands optional [ Upstream commit 2418aa8516b26c5e332a1a8c216d4d620f965a56 ] The commit introducing the Frida display started to write the SETVCMOFF registers unconditionally, and some (not all!) Hydis display seem to be affected by ghosting after the commit. Make SETVCMOFF optional and only send these commands on the Frida display for now. Reported-by: Stefan Hansson <newbyte@postmarketos.org> Fixes: 219a1f49094f ("drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK") Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by: Stefan Hansson <newbyte@postmarketos.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240908-fix-nt35510-v2-1-d4834b9cdb9b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit fbc48203b9f8ef9e8c1865ff76ab6eea7e00a273 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Thu Sep 12 16:30:18 2024 +0800 drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 40004709a3d3b07041a473a163ca911ef04ab8bd ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 47b1be5c0f4e ("staging: imx/drm: request irq only after adding the crtc") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-4-ruanjinjie@huawei.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b2f2cc6ce22515221ae37694c21c17ba6a6bc3a8 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Thu Sep 12 16:30:16 2024 +0800 drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 1af01e14db7e0b45ae502d822776a58c86688763 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-2-ruanjinjie@huawei.com [DB: fixed the subject] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit eb403042790b59fef7d2f3706132b04d7bdce521 Author: Huan Yang <link@vivo.com> Date: Wed Sep 18 10:52:26 2024 +0800 udmabuf: fix vmap_udmabuf error page set [ Upstream commit 18d7de823b7150344d242c3677e65d68c5271b04 ] Currently vmap_udmabuf set page's array by each folio. But, ubuf->folios is only contain's the folio's head page. That mean we repeatedly mapped the folio head page to the vmalloc area. Due to udmabuf can use hugetlb, if HVO enabled, tail page may not exist, so, we can't use page array to map, instead, use pfn array. By this, we removed page usage in udmabuf totally. Fixes: 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios") Suggested-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Huan Yang <link@vivo.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-4-link@vivo.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2acc6192aa8570661ed37868c02c03002b1dc290 Author: Huan Yang <link@vivo.com> Date: Wed Sep 18 10:52:25 2024 +0800 udmabuf: change folios array from kmalloc to kvmalloc [ Upstream commit 1c0844c6184e658064e14c4335885785ad3bf84b ] When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine, page_alloc only support 4MB. If above this, trigger this warn and return NULL. udmabuf can change size limit, if change it to 3072(3GB), and then alloc 3GB udmabuf, will fail create. [ 4080.876581] ------------[ cut here ]------------ [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Call Trace: [ 4080.879473] <TASK> [ 4080.879473] ? __alloc_pages+0x2c8/0x350 [ 4080.879475] ? __warn.cold+0x8e/0xe8 [ 4080.880647] ? __alloc_pages+0x2c8/0x350 [ 4080.880909] ? report_bug+0xff/0x140 [ 4080.881175] ? handle_bug+0x3c/0x80 [ 4080.881556] ? exc_invalid_op+0x17/0x70 [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20 [ 4080.882077] ? udmabuf_create+0x131/0x400 Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB memory, each array entry is pointer(8byte), so can save 524288 pages(2GB). Further more, costly order(order 3) may not be guaranteed that it can be applied for, due to fragmentation. This patch change udmabuf array use kvmalloc_array, this can fallback alloc into vmalloc, which can guarantee allocation for any size and does not affect the performance of kmalloc allocations. Signed-off-by: Huan Yang <link@vivo.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-3-link@vivo.com Stable-dep-of: 18d7de823b71 ("udmabuf: fix vmap_udmabuf error page set") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7f9594610b7b005f6f1a4fc5bb29cd10e79d1545 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Tue Sep 10 20:43:13 2024 +0800 wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 9a98dd48b6d834d7a3fe5e8e7b8c3a1d006f9685 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240910124314.698896-3-ruanjinjie@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 786c958cf429c4a52c2d24dec3a5f5352785c2d0 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Tue Sep 10 20:43:12 2024 +0800 wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit bcd1371bd85e560ccc9159b7747f94bfe43b77a6 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: cd8d3d321285 ("p54spi: p54spi driver") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240910124314.698896-2-ruanjinjie@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 26c790ceaa62f1dcffc8de89b269996c56e4d1ea Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Date: Tue Aug 13 11:25:05 2024 +0100 drm/v3d: Appease lockdep while updating GPU stats [ Upstream commit 06c3c406850e5495bb56ccf624d0c9477e1ba901 ] Lockdep thinks our seqcount_t usage is unsafe because the update path can be both from irq and worker context: [ ] ================================ [ ] WARNING: inconsistent lock state [ ] 6.10.3-v8-16k-numa #159 Tainted: G WC [ ] -------------------------------- [ ] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [ ] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ ] ffff80003d7c08d0 (&v3d_priv->stats[i].lock){?.+.}-{0:0}, at: v3d_irq+0xc8/0x660 [v3d] [ ] {HARDIRQ-ON-W} state was registered at: [ ] lock_acquire+0x1f8/0x328 [ ] v3d_job_start_stats.isra.0+0xd8/0x218 [v3d] [ ] v3d_bin_job_run+0x23c/0x388 [v3d] [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ ] process_one_work+0x62c/0xb48 [ ] worker_thread+0x468/0x5b0 [ ] kthread+0x1c4/0x1e0 [ ] ret_from_fork+0x10/0x20 [ ] irq event stamp: 337094 [ ] hardirqs last enabled at (337093): [<ffffc0008144ce7c>] default_idle_call+0x11c/0x140 [ ] hardirqs last disabled at (337094): [<ffffc0008144a354>] el1_interrupt+0x24/0x58 [ ] softirqs last enabled at (337082): [<ffffc00080061d90>] handle_softirqs+0x4e0/0x538 [ ] softirqs last disabled at (337073): [<ffffc00080010364>] __do_softirq+0x1c/0x28 [ ] other info that might help us debug this: [ ] Possible unsafe locking scenario: [ ] CPU0 [ ] ---- [ ] lock(&v3d_priv->stats[i].lock); [ ] <Interrupt> [ ] lock(&v3d_priv->stats[i].lock); [ ] *** DEADLOCK *** [ ] no locks held by swapper/0/0. [ ] stack backtrace: [ ] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 6.10.3-v8-16k-numa #159 [ ] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ ] Call trace: [ ] dump_backtrace+0x170/0x1b8 [ ] show_stack+0x20/0x38 [ ] dump_stack_lvl+0xb4/0xd0 [ ] dump_stack+0x18/0x28 [ ] print_usage_bug+0x3cc/0x3f0 [ ] mark_lock+0x4d0/0x968 [ ] __lock_acquire+0x784/0x18c8 [ ] lock_acquire+0x1f8/0x328 [ ] v3d_job_update_stats+0xec/0x2e0 [v3d] [ ] v3d_irq+0xc8/0x660 [v3d] [ ] __handle_irq_event_percpu+0x1f8/0x488 [ ] handle_irq_event+0x88/0x128 [ ] handle_fasteoi_irq+0x298/0x408 [ ] generic_handle_domain_irq+0x50/0x78 But it is a false positive because all the queue-stats pairs have their own lock and jobs are also one at a time. Nevertheless we can appease lockdep by disabling local interrupts to make it see lock usage is consistent. Cc: Maíra Canal <mcanal@igalia.com> Fixes: 6abe93b621ab ("drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler") Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240813102505.80512-2-tursulin@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4e564763494c8735976288ec037a997f5c842610 Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: Tue Aug 6 16:50:29 2024 +0300 drm/omap: Fix locking in omap_gem_new_dmabuf() [ Upstream commit e6a1c4037227539373c8cf484ace83833e2ad6a2 ] omap_gem_new_dmabuf() creates the new gem object, and then takes and holds the omap_obj->lock for the rest of the function. This has two issues: - omap_gem_free_object(), which is called in the error paths, also takes the same lock, leading to deadlock - Even if the above wouldn't happen, in the error cases omap_gem_new_dmabuf() still unlocks omap_obj->lock, even after the omap_obj has already been freed. Furthermore, I don't think there's any reason to take the lock at all, as the object was just created and not yet shared with anyone else. To fix all this, drop taking the lock. Fixes: 3cbd0c587b12 ("drm/omap: gem: Replace struct_mutex usage with omap_obj private lock") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/511b99d7-aade-4f92-bd3e-63163a13d617@stanley.mountain/ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-3-15d31aea0831@ideasonboard.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 238273246f5c1957ed59a2800b949a6e5c8ee2b0 Author: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Date: Tue Aug 6 16:50:27 2024 +0300 drm/omap: Fix possible NULL dereference [ Upstream commit a88fee2d67d9b78c24630a987a88ccf886b2498b ] smatch reports: drivers/gpu/drm/omapdrm/dss/base.c:176 omapdss_device_disconnect() error: we previously assumed 'src' could be null (see line 169) This code is mostly from a time when omapdrm had its own display device model. I can't honestly remember the details, and I don't think it's worth digging in deeply into that for a legacy driver. However, it looks like we only call omapdss_device_disconnect() and omapdss_device_connect() with NULL as the src parameter. We can thus drop the src parameter from both functions, and fix the smatch warning. I don't think omapdss_device_disconnect() ever gets NULL for the dst parameter (if it did, we'd crash soon after returning from the function), but I have kept the !dst check, just in case, but I added a WARN_ON() there. Also, if the dst parameter can be NULL, we can't always get the struct dss_device pointer from dst->dss (which is only used for a debug print). To make sure we can't hit that issue, do it similarly to the omapdss_device_connect() function: add 'struct dss_device *dss' as the first parameter, so that we always have it regardless of the dst. Fixes: 79107f274b2f ("drm/omap: Add support for drm_bridge") Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-1-15d31aea0831@ideasonboard.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3fe99b9690b99606d3743c9961ebee865cfa1ab8 Author: Jeongjun Park <aha310510@gmail.com> Date: Sat Sep 14 12:06:03 2024 +0300 wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() [ Upstream commit 8619593634cbdf5abf43f5714df49b04e4ef09ab ] I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Jeongjun Park <aha310510@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240909103855.68006-1-aha310510@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit c89e0a4cb649e43d8a9497d047f3bb9f49f346e2 Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Fri Jun 21 16:20:55 2024 +0100 drm/vc4: hvs: Correct logic on stopping an HVS channel [ Upstream commit 7ab6512e7942889c0962588355cb92424a690be6 ] When factoring out __vc4_hvs_stop_channel, the logic got inverted from if (condition) // stop channel to if (condition) goto out //stop channel out: and also changed the exact register writes used to stop the channel. Correct the logic so that the channel is actually stopped, and revert to the original register writes. Fixes: 6d01a106b4c8 ("drm/vc4: crtc: Move HVS init and close to a function") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-32-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 583876fcbd2478609dc1f2f3868d94b849e533f3 Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Fri Jun 21 16:20:42 2024 +0100 drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function [ Upstream commit d285bb622ebdfaa84f51df3a1abccb87036157ea ] The debugfs function to dump dlists aborted at 256 bytes, when actually the dlist memory is generally significantly larger but varies based on SoC. We already have the correct limit in __vc4_hvs_alloc, so store it for use in the debugfs dlist function. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-19-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ce882d4f4bfbb739d8b7cd441c048859f1e278d5 Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Fri Jun 21 16:20:41 2024 +0100 drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer [ Upstream commit 6d5f76e0544b04ec5bdd2a09c19d90aeeb2cd479 ] The debug function to display the dlists didn't reset next_entry_start when starting each display, so resulting in not stopping the list at the correct place. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-18-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 16f351adf733a182224ad24916d7673aa6df02df Author: Dom Cobley <popcornmix@gmail.com> Date: Fri Jun 21 16:20:40 2024 +0100 drm/vc4: hdmi: Avoid hang with debug registers when suspended [ Upstream commit 223ee2567a55e4f80315c768d2969e6a3b9fb23d ] Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. Fixes: 25eb441d55d4 ("drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumps") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-17-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 200cef3d08fce40053226404366945969dbe9dd3 Author: Dave Stevenson <dave.stevenson@raspberrypi.com> Date: Fri Jun 21 16:20:38 2024 +0100 drm/vc4: hvs: Don't write gamma luts on 2711 [ Upstream commit 52efe364d1968ee3e3ed45eb44eb924b63635315 ] The gamma block has changed in 2711, therefore writing the lut in vc4_hvs_lut_load is incorrect. Whilst the gamma property isn't created for 2711, it is called from vc4_hvs_init_channel, so abort if attempted. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-15-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 78bd865efdcae05f5e6c81e4b0820f0e0cccc399 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Thu Aug 29 18:46:40 2024 +0300 drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused [ Upstream commit 53bd7c1c0077db533472ae32799157758302ef48 ] The INTERVAL_TREE_DEFINE() uncoditionally provides a bunch of helper functions which in some cases may be not used. This, in particular, prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y: .../drm/drm_mm.c:152:1: error: unused function 'drm_mm_interval_tree_insert' [-Werror,-Wunused-function] 152 | INTERVAL_TREE_DEFINE(struct drm_mm_node, rb, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 153 | u64, __subtree_last, | ~~~~~~~~~~~~~~~~~~~~ 154 | START, LAST, static inline, drm_mm_interval_tree) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by marking drm_mm_interval_tree*() functions with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Fixes: 202b52b7fbf7 ("drm: Track drm_mm nodes with an interval tree") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240829154640.1120050-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4600f48dd82abc381e28ea88d6b1b0f35e0b6af9 Author: Matt Coster <Matt.Coster@imgtec.com> Date: Fri Aug 30 15:06:01 2024 +0000 drm/imagination: Use pvr_vm_context_get() [ Upstream commit eb4accc5234525e2cb2b720187ccaf6db99b705f ] I missed this open-coded kref_get() while trying to debug a refcount bug, so let's use the helper function here to avoid that waste of time again in the future. Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/8616641d-6005-4b25-bc0a-0b53985a0e08@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a855bc9cdb37623fb5eb143484db9c0054209f0c Author: Chen Yufan <chenyufan@vivo.com> Date: Fri Aug 23 17:39:24 2024 +0800 drm/imagination: Convert to use time_before macro [ Upstream commit 7a5115ba1d691bd14db91d2fcc3ce0b056574ce9 ] Use time_*() macros instead of using jiffies directly to handle overflow issues. Fixes: cc1aeedb98ad ("drm/imagination: Implement firmware infrastructure and META FW support") Signed-off-by: Chen Yufan <chenyufan@vivo.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240823093925.9599-1-chenyufan@vivo.com Signed-off-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 62830b6103a25ba3c3b48f255fee98593d158596 Author: Yao Zi <ziyao@disroot.org> Date: Mon Nov 18 06:46:39 2024 +0000 platform/x86: panasonic-laptop: Return errno correctly in show callback [ Upstream commit 5c7bebc1a3f0661db558d60e14dde27fc216d9dc ] When an error occurs in sysfs show callback, we should return the errno directly instead of formatting it as the result, which produces meaningless output and doesn't inform the userspace of the error. Fixes: 468f96bfa3a0 ("platform/x86: panasonic-laptop: Add support for battery charging threshold (eco mode)") Fixes: d5a81d8e864b ("platform/x86: panasonic-laptop: Add support for optical driver power in Y and W series") Signed-off-by: Yao Zi <ziyao@disroot.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241118064637.61832-3-ziyao@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 19a9457e5e210e408c1f8865b5d93c5a2c90409d Author: Vitaly Kuznetsov <vkuznets@redhat.com> Date: Mon Nov 11 14:12:40 2024 +0100 HID: hyperv: streamline driver probe to avoid devres issues [ Upstream commit 66ef47faa90d838cda131fe1f7776456cc3b59f2 ] It was found that unloading 'hid_hyperv' module results in a devres complaint: ... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: <TASK> ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not. The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct. Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is. Fixes: 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") Suggested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Saurabh Sengar <ssengar@linux.microsoft.com> Signed-off-by: Jiri Kosina <jkosina@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9a1a26156363cd9e88c933d649bae7701e5e78cb Author: Chris Morgan <macromorgan@hotmail.com> Date: Thu Oct 31 10:05:03 2024 -0500 arm64: dts: rockchip: correct analog audio name on Indiedroid Nova [ Upstream commit 42d85557527266804579bc5d20c101d93f6be3c6 ] Correct the audio name for the Indiedroid Nova from rockchip,es8388-codec to rockchip,es8388. This name change corrects a kernel log error of "ASoC: driver name too long 'rockchip,es8388-codec' -> 'rockchip_es8388'". Fixes: 3900160e164b ("arm64: dts: rockchip: Add Indiedroid Nova board") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20241031150505.967909-2-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 74aa783682c4d78c69d87898e40c78df1fec204e Author: Li Huafei <lihuafei1@huawei.com> Date: Mon Nov 4 22:50:51 2024 +0800 media: atomisp: Add check for rgby_data memory allocation failure [ Upstream commit ed61c59139509f76d3592683c90dc3fdc6e23cd6 ] In ia_css_3a_statistics_allocate(), there is no check on the allocation result of the rgby_data memory. If rgby_data is not successfully allocated, it may trigger the assert(host_stats->rgby_data) assertion in ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue. Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2") Signed-off-by: Li Huafei <lihuafei1@huawei.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20241104145051.3088231-1-lihuafei1@huawei.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6e2cb93e54fafd45a631d78a5bc6a71e752359de Author: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Date: Tue Nov 5 16:35:22 2024 +0100 pwm: Assume a disabled PWM to emit a constant inactive output [ Upstream commit b2eaa1170e45dc18eb09dcc9abafbe9a7502e960 ] Some PWM hardwares (e.g. MC33XS2410) cannot implement a zero duty cycle but can instead disable the hardware which also results in a constant inactive output. There are some checks (enabled with CONFIG_PWM_DEBUG) to help implementing a driver without violating the normal rounding rules. Make them less strict to let above described hardware pass without warning. Reported-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20241103205215.GA509903@debian Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20241105153521.1001864-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a8a333a5a3cc9a871ee919c848f191616f3d030b Author: Bingbu Cao <bingbu.cao@intel.com> Date: Wed Oct 16 15:53:01 2024 +0800 media: ipu6: not override the dma_ops of device in driver [ Upstream commit daabc5c64703432c4a8798421a3588c2c142c51b ] DMA ops are a helper for architectures and not for drivers to override the DMA implementation. Driver should not override the DMA implementation. This patch removes the dma_ops override from auxiliary device and adds driver-internal helpers that use the actual DMA mapping APIs. Fixes: 9163d83573e4 ("media: intel/ipu6: add IPU6 DMA mapping API and MMU table") Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Reviewed-by: Christoph Hellwig <hch@lst.de> [Sakari Ailus: Fix the commit message a little.] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1365a40a267734fadb9d92a98439def5b4c53784 Author: Sakari Ailus <sakari.ailus@linux.intel.com> Date: Mon Nov 4 13:31:32 2024 +0200 media: ipu6: Fix DMA and physical address debugging messages for 32-bit [ Upstream commit 199c204bcc732ec18dbaec2b9d6445addbd376ea ] Fix printing DMA and physical address printing on 32-bit platforms, by using correct types. Also cast DMA_BIT_MASK() result to dma_addr_t to make Clang happy. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Stable-dep-of: daabc5c64703 ("media: ipu6: not override the dma_ops of device in driver") Signed-off-by: Sasha Levin <sashal@kernel.org> commit dfc9c2aa7f04f7db7e7225a5e118a24bf1c3b325 Author: Luo Qiu <luoqiu@kylinsec.com.cn> Date: Fri Nov 1 11:21:15 2024 +0800 firmware: arm_scpi: Check the DVFS OPP count returned by the firmware [ Upstream commit 109aa654f85c5141e813b2cd1bd36d90be678407 ] Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Luo Qiu <luoqiu@kylinsec.com.cn> Message-Id: <55A2F7A784391686+20241101032115.275977-1-luoqiu@kylinsec.com.cn> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1b4f406a29fc23eb2fd3539b4806ffd95ec367d9 Author: Reinette Chatre <reinette.chatre@intel.com> Date: Thu Oct 24 14:18:41 2024 -0700 selftests/resctrl: Protect against array overrun during iMC config parsing [ Upstream commit 48ed4e799e8fbebae838dca404a8527763d41191 ] The MBM and MBA tests need to discover the event and umask with which to configure the performance event used to measure read memory bandwidth. This is done by parsing the /sys/bus/event_source/devices/uncore_imc_<imc instance>/events/cas_count_read file for each iMC instance that contains the formatted output: "event=<event>,umask=<umask>" Parsing of cas_count_read contents is done by initializing an array of MAX_TOKENS elements with tokens (deliminated by "=,") from this file. Remove the unnecessary append of a delimiter to the string needing to be parsed. Per the strtok() man page: "delimiter bytes at the start or end of the string are ignored". This has no impact on the token placement within the array. After initialization, the actual event and umask is determined by parsing the tokens directly following the "event" and "umask" tokens respectively. Iterating through the array up to index "i < MAX_TOKENS" but then accessing index "i + 1" risks array overrun during the final iteration. Avoid array overrun by ensuring that the index used within for loop will always be valid. Fixes: 1d3f08687d76 ("selftests/resctrl: Read memory bandwidth from perf IMC counter and from resctrl file system") Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c7b393c4d27e3c5ce6ae0e1c315304c350ee4947 Author: Reinette Chatre <reinette.chatre@intel.com> Date: Thu Oct 24 14:18:40 2024 -0700 selftests/resctrl: Fix memory overflow due to unhandled wraparound [ Upstream commit caf02626b2bf164a02c808240f19dbf97aced664 ] alloc_buffer() allocates and initializes (with random data) a buffer of requested size. The initialization starts from the beginning of the allocated buffer and incrementally assigns sizeof(uint64_t) random data to each cache line. The initialization uses the size of the buffer to control the initialization flow, decrementing the amount of buffer needing to be initialized after each iteration. The size of the buffer is stored in an unsigned (size_t) variable s64 and the test "s64 > 0" is used to decide if initialization is complete. The problem is that decrementing the buffer size may wrap around if the buffer size is not divisible by "CL_SIZE / sizeof(uint64_t)" resulting in the "s64 > 0" test being true and memory beyond the buffer "initialized". Use a signed value for the buffer size to support all buffer sizes. Fixes: a2561b12fe39 ("selftests/resctrl: Add built in benchmark") Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d691c2ab8838372670fbffa1860785a5909b76eb Author: Reinette Chatre <reinette.chatre@intel.com> Date: Thu Oct 24 14:18:39 2024 -0700 selftests/resctrl: Print accurate buffer size as part of MBM results [ Upstream commit 1b4840395f08e9723a15fea42c2d31090e8375f3 ] By default the MBM test uses the "fill_buf" benchmark to keep reading from a buffer with size DEFAULT_SPAN while measuring memory bandwidth. User space can provide an alternate benchmark or amend the size of the buffer "fill_buf" should use. Analysis of the MBM measurements do not require that a buffer be used and thus do not require knowing the size of the buffer if it was used during testing. Even so, the buffer size is printed as informational as part of the MBM test results. What is printed as buffer size is hardcoded as DEFAULT_SPAN, even if the test relied on another benchmark (that may or may not use a buffer) or if user space amended the buffer size. Ensure that accurate buffer size is printed when using "fill_buf" benchmark and omit the buffer size information if another benchmark is used. Fixes: ecdbb911f22d ("selftests/resctrl: Add MBM test") Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 80b59bc2caadd933ea293f6d6c902128d206c070 Author: Chen-Yu Tsai <wenst@chromium.org> Date: Wed Oct 30 15:02:22 2024 +0800 arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed regulators [ Upstream commit aaecb1da58a72bfbd2c35d4aadc43caa02f11862 ] When the fixed regulators for the LCD panel and DP bridge were added, their supplies were not modeled in. These, except for the 1.0V supply, are just load switches, and need and have a supply. Add the supplies for each of the fixed regulators. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20241030070224.1006331-4-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 496414fe141f3fda36ffefe8516180cb2a2d47c8 Author: Chen-Yu Tsai <wenst@chromium.org> Date: Wed Oct 30 15:02:21 2024 +0800 arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names [ Upstream commit c4e8cf13f1740037483565d5b802764e2426515b ] Some of the regulator supplies for the MIPI-DPI-to-DP bridge and their associated nodes are incorrectly named. In particular, the 1.0V supply was modeled as a 1.2V supply. Fix all the incorrect names, and also fix the voltage of the 1.0V regulator. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20241030070224.1006331-3-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9e7b0837b9fffe48ec66b2380810d01c287e8b92 Author: Macpaul Lin <macpaul.lin@mediatek.com> Date: Tue Oct 29 14:46:47 2024 +0800 arm64: dts: mediatek: mt6358: fix dtbs_check error [ Upstream commit 76ab2ae0ab9ebb2d70e6ee8a9f59911621192c37 ] Fix DTBS check errors for 'mt6358codec' and 'mt6358regulator': Error message is: pmic: 'mt6358codec' and 'mt6358regulator' does not match any of the regexes: 'pinctrl-[0-9]+'. Rename these two device node to generic 'audio-codec' and 'regulators'. Fixes: 9f8872221674 ("arm64: dts: mt6358: add PMIC MT6358 related nodes") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Link: https://lore.kernel.org/r/20241029064647.13370-1-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3c7c1170e64a090751910ee29c7c70e5c3444c3e Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Date: Tue Jun 4 14:30:08 2024 +0200 arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs [ Upstream commit b0a4ce81f327eae06c1088f1a437edc48a94a3e8 ] Add support for the ADC on MT6357/8/9 and keep it default enabled as this IP is always present on those PMICs. Users may use different IIO channels depending on board-specific routing. Link: https://lore.kernel.org/r/20240604123008.327424-6-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Stable-dep-of: 76ab2ae0ab9e ("arm64: dts: mediatek: mt6358: fix dtbs_check error") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7acf3ad2ce09ba4ac4c81b17b7073de577712d5a Author: Frank Li <Frank.Li@nxp.com> Date: Wed Oct 23 17:03:13 2024 -0400 arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and output-high in GPIO [ Upstream commit c771d311b1901cd4679c8fc7f89a882fe07cf4a0 ] Fix the issue where both 'output-low' and 'output-high' exist under GPIO hog nodes (rst_usb_hub_hog and sel_usb_hub_hog) when applying device tree overlays. Since /delete-property/ is not supported in the overlays, setting 'output-low' results in both properties being present. The workaround is to disable these hogs and create new ones with 'output-low' as needed. Fix below CHECK_DTBS warning: arch/arm64/boot/dts/freescale/imx8mn-tqma8mqnl-mba8mx-usbotg.dtb: sel-usb-hub-hog: {'output-low': True, 'gpio-hog': True, 'gpios': [[1, 0]], 'output-high': True, 'phandle': 108, '$nodename': ['sel-usb-hub-hog']} is valid under each of {'required': ['output-low']}, {'required': ['output-high'] Fixes: 3f6fc30abebc ("arm64: dts: imx8mn: tqma8mqnl-mba8mx: Add USB DR overlay") Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ceb656f4e9e77bc07b23f5a9f07f77eba0f5c165 Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Date: Thu Oct 10 14:53:31 2024 +0100 arm64: dts: renesas: hihope: Drop #sound-dai-cells [ Upstream commit 9cc926e3fab42dd292219796cfc94e41f4ab749d ] "#sound-dai-cells" is required if the board is using "simple-card". However, the HiHope board uses "audio-graph", thus remove the unneeded `#sound-dai-cells`. Commit 9e72606cd2db ("arm64: dts: renesas: #sound-dai-cells is used when simple-card") updated the comment regarding usage of "#sound-dai-cells" in the SoC DTSI but missed to remove "#sound-dai-cells" from board DTS files. Fixes: 9e72606cd2db ("arm64: dts: renesas: #sound-dai-cells is used when simple-card") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/20241010135332.710648-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 010587f9e57c173c68a2cda61aa3f535c283b6d6 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: Fri Nov 1 18:55:53 2024 +0200 regmap: irq: Set lockdep class for hierarchical IRQ domains [ Upstream commit 953e549471cabc9d4980f1da2e9fa79f4c23da06 ] Lockdep gives a false positive splat as it can't distinguish the lock which is taken by different IRQ descriptors from different IRQ chips that are organized in a way of a hierarchy: ====================================================== WARNING: possible circular locking dependency detected 6.12.0-rc5-next-20241101-00148-g9fabf8160b53 #562 Tainted: G W ------------------------------------------------------ modprobe/141 is trying to acquire lock: ffff899446947868 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}, at: regmap_update_bits_base+0x33/0x90 but task is already holding lock: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 which lock already depends on the new lock. -> #3 (&d->lock){+.+.}-{4:4}: -> #2 (&desc->request_mutex){+.+.}-{4:4}: -> #1 (ipclock){+.+.}-{4:4}: -> #0 (intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock){+.+.}-{4:4}: Chain exists of: intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock --> &desc->request_mutex --> &d->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&d->lock); lock(&desc->request_mutex); lock(&d->lock); lock(intel_soc_pmic_bxtwc:502:(&bxtwc_regmap_config)->lock); *** DEADLOCK *** 3 locks held by modprobe/141: #0: ffff8994419368f8 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xf6/0x250 #1: ffff89944690b250 (&desc->request_mutex){+.+.}-{4:4}, at: __setup_irq+0x1a2/0x790 #2: ffff899446947c68 (&d->lock){+.+.}-{4:4}, at: __setup_irq+0x682/0x790 Set a lockdep class when we map the IRQ so that it doesn't warn about a lockdep bug that doesn't exist. Fixes: 4af8be67fd99 ("regmap: Convert regmap_irq to use irq_domain") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241101165553.4055617-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 75c4ca1467f749016970cb6d2430d7573e9ec2dc Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Fri Sep 20 17:11:35 2024 +0800 spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​ [ Upstream commit 2219576883e709737f3100aa9ded84976be49bd7 ] It's important to undo pm_runtime_use_autosuspend() with pm_runtime_dont_use_autosuspend() at driver exit time. So, call pm_runtime_dont_use_autosuspend() at driver exit time to fix it. Fixes: 9e3a000362ae ("spi: zynqmp: Add pm runtime support") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20240920091135.2741574-1-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3f411ae9912bd68ba4b9fd31c2eb50148cdeed42 Author: Breno Leitao <leitao@debian.org> Date: Fri Oct 4 05:53:59 2024 -0700 spi: tegra210-quad: Avoid shift-out-of-bounds [ Upstream commit f399051ec1ff02e74ae5c2517aed2cc486fd005b ] A shift-out-of-bounds issue was identified by UBSAN in the tegra_qspi_fill_tx_fifo_from_client_txbuf() function. UBSAN: shift-out-of-bounds in drivers/spi/spi-tegra210-quad.c:345:27 shift exponent 32 is too large for 32-bit type 'u32' (aka 'unsigned int') Call trace: tegra_qspi_start_cpu_based_transfer The problem arises when shifting the contents of tx_buf left by 8 times the value of i, which can exceed 4 and result in an exponent larger than 32 bits. Resolve this by restrict the value of i to be less than 4, preventing the shift operation from overflowing. Signed-off-by: Breno Leitao <leitao@debian.org> Fixes: 921fc1838fb0 ("spi: tegra210-quad: Add support for Tegra210 QSPI controller") Link: https://patch.msgid.link/20241004125400.1791089-1-leitao@debian.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit da463a80f86e57288dc73161cf17daa8501e4465 Author: Zhang Zekun <zhangzekun11@huawei.com> Date: Thu Oct 24 11:04:41 2024 +0800 pmdomain: ti-sci: Add missing of_node_put() for args.np [ Upstream commit afc2331ef81657493c074592c409dac7c3cb8ccc ] of_parse_phandle_with_args() needs to call of_node_put() to decrement the refcount of args.np. So, Add the missing of_node_put() in the loop. Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one") Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Message-ID: <20241024030442.119506-2-zhangzekun11@huawei.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f8528655791598772089845b949537d5cfcd34d3 Author: Usama Arif <usamaarif642@gmail.com> Date: Wed Oct 23 18:14:26 2024 +0100 of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify [ Upstream commit b2473a359763e27567993e7d8f37de82f57a0829 ] __pa() is only intended to be used for linear map addresses and using it for initial_boot_params which is in fixmap for arm64 will give an incorrect value. Hence save the physical address when it is known at boot time when calling early_init_dt_scan for arm64 and use it at kexec time instead of converting the virtual address using __pa(). Note that arm64 doesn't need the FDT region reserved in the DT as the kernel explicitly reserves the passed in FDT. Therefore, only a debug warning is fixed with this change. Reported-by: Breno Leitao <leitao@debian.org> Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Usama Arif <usamaarif642@gmail.com> Fixes: ac10be5cdbfa ("arm64: Use common of_kexec_alloc_and_setup_fdt()") Link: https://lore.kernel.org/r/20241023171426.452688-1-usamaarif642@gmail.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 20ddad03ec8976359bd2f6d2c7eac13678f60595 Author: Abel Vesa <abel.vesa@linaro.org> Date: Fri Oct 18 16:13:47 2024 +0300 dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries [ Upstream commit f9759e2b57049f9c4ea8d7254ba6afcf6eb10cd6 ] Document the missing Broadcast_AND region for x1e80100. Fixes: e9ceb595c2d3 ("dt-bindings: cache: qcom,llcc: Add X1E80100 compatible") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410181235.L7MF7z48-lkp@intel.com/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241018-qcom-llcc-bindings-reg-ranges-fix-v1-1-88693cb7723b@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b0a4db83deb12783a90a523e08ad7fcf639b3116 Author: Konrad Dybcio <konradybcio@kernel.org> Date: Tue Jul 16 12:35:04 2024 +0200 arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers [ Upstream commit 2e65616ef07fa4c72c3898b22e5bede7d468cf32 ] Update the numbers based on the information found in the DSDT. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240716-topic-h_bits-v1-2-f6c5d3ff982c@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1d863f4e23aa718ba4de49f8b00a5928fb14d1a0 Author: Niklas Schnelle <schnelle@linux.ibm.com> Date: Mon Oct 14 13:25:42 2024 +0200 watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240 [ Upstream commit d4d3125a3452a54acca69050be67b87ee2900e77 ] Both drivers use I/O port accesses without declaring a dependency on CONFIG_HAS_IOPORT. For sbc8360_wdt this causes a compile error on UML once inb()/outb() helpers become conditional. For sbc7240_wdt this causes no such errors with UML because this driver depends on both x86_32 and !UML. Nevertheless add HAS_IOPORT as a dependency for both drivers to be explicit and drop the !UML dependency for sbc7240_wdt as it is now redundant since UML implies no HAS_IOPORT. Fixes: 52df67b6b313 ("watchdog: add HAS_IOPORT dependencies") Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 55c28e216bdab3fef2dde7567310c19139ff31c2 Author: Anurag Dutta <a-dutta@ti.com> Date: Wed Oct 23 16:15:31 2024 +0530 arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances [ Upstream commit 891874f015e98f67ab2fda76f2e859921e136621 ] The clock IDs for multiple MCSPI instances across wakeup domain in J721s2 are incorrect when compared with documentation [1]. Fix the clock IDs to their appropriate values. [1]https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/clocks.html Fixes: 04d7cb647b85 ("arm64: dts: ti: k3-j721s2: Add MCSPI nodes") Signed-off-by: Anurag Dutta <a-dutta@ti.com> Link: https://lore.kernel.org/r/20241023104532.3438851-4-a-dutta@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 44dd67396142a2893cdb1c4c06d740826af315ae Author: Anurag Dutta <a-dutta@ti.com> Date: Wed Oct 23 16:15:30 2024 +0530 arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances [ Upstream commit ab09a68f3be04b2f9d1fc7cfc0e2225025cb9421 ] The clock IDs for multiple MCSPI instances across wakeup domain in J721e are incorrect when compared with documentation [1]. Fix the clock ids to their appropriate values. [1]https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/clocks.html Fixes: 76aa309f9fa7 ("arm64: dts: ti: k3-j721e: Add MCSPI nodes") Signed-off-by: Anurag Dutta <a-dutta@ti.com> Link: https://lore.kernel.org/r/20241023104532.3438851-3-a-dutta@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit efa011b09afb0bcab3fc861757def22db867e1bb Author: Anurag Dutta <a-dutta@ti.com> Date: Wed Oct 23 16:15:29 2024 +0530 arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances [ Upstream commit 3a47e381670f130870caef6e1155ac531b17b032 ] The clock IDs for multiple MCSPI instances across wakeup as well as main domain in J7200 are incorrect when compared with documentation [1]. This results in kernel crashes when the said instances are enabled. Fix the clock ids to their appropriate values. [1]https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html Fixes: 8f6c475f4ca7 ("arm64: dts: ti: k3-j7200: Add MCSPI nodes") Signed-off-by: Anurag Dutta <a-dutta@ti.com> Reviewed-by: Aniket Limaye <a-limaye@ti.com> Link: https://lore.kernel.org/r/20241023104532.3438851-2-a-dutta@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 245accf6633b6915644784ee5ebde2b5a77e1617 Author: Jared McArthur <j-mcarthur@ti.com> Date: Thu Sep 26 15:55:33 2024 +0530 arm64: dts: ti: k3-j7200: Fix register map for main domain pmx [ Upstream commit b7af8b4acb3e08c710cd48f098ce8cd07cf43a1e ] Commit 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux range") split the main_pmx0 into two nodes: main_pmx0 and main_pmx1 due to a non-addressable region, but incorrectly represented the ranges. As a result, the memory map for the pinctrl is incorrect. Fix this by introducing the correct ranges. The ranges are taken from the J7200 TRM [1] (Table 5-695. CTRL_MMR0 Registers). Padconfig starting addresses and ranges: - 0 to 66: 0x11c000, 0x10c - 68: 0x11c110, 0x004 - 71 to 73: 0x11c11c, 0x00c - 89 to 90: 0x11c164, 0x008 The datasheet [2] doesn't contain PADCONFIG63 (Table 6-106. Pin Multiplexing), but the pin is necessary for enabling the MMC1 CLKLP pad loopback and should be included in the pinmux register map. Due to the change in pinmux node addresses, change the pinmux node for the USB0_DRVVBUS pin to main_pmx2. The offset has not changed since the new main_pmx2 node has the same base address and range as the original main_pmx1 node. All other pinmuxing done within J7200 dts or dtso files only uses main_pmx0 which has not changed. [1] https://www.ti.com/lit/pdf/spruiu1 [2] https://www.ti.com/lit/gpn/dra821u Fixes: 0d0a0b441346 ("arm64: dts: ti: k3-j7200: fix main pinmux range") Signed-off-by: Aniket Limaye <a-limaye@ti.com> Signed-off-by: Jared McArthur <j-mcarthur@ti.com> Reviewed-by: Vaishnav Achath <vaishnav.a@ti.com> Link: https://lore.kernel.org/r/20240926102533.398139-1-a-limaye@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 555c42a1508af428fa50d4a8337cde8e6b7d1416 Author: Andre Przywara <andre.przywara@arm.com> Date: Mon Oct 7 23:29:16 2024 +0100 ARM: dts: cubieboard4: Fix DCDC5 regulator constraints [ Upstream commit dd36ad71ad65968f97630808bc8d605c929b128e ] The DCDC5 voltage rail in the X-Powers AXP809 PMIC has a resolution of 50mV, so the currently enforced limits of 1.475 and 1.525 volts cannot be set, when the existing regulator value is beyond this range. This will lead to the whole regulator driver to give up and fail probing, which in turn will hang the system, as essential devices depend on the PMIC. In this case a bug in U-Boot set the voltage to 1.75V (meant for DCDC4), and the AXP driver's attempt to correct this lead to this error: ================== [ 4.447653] axp20x-rsb sunxi-rsb-3a3: AXP20X driver loaded [ 4.450066] vcc-dram: Bringing 1750000uV into 1575000-1575000uV [ 4.460272] vcc-dram: failed to apply 1575000-1575000uV constraint: -EINVAL [ 4.474788] axp20x-regulator axp20x-regulator.0: Failed to register dcdc5 [ 4.482276] axp20x-regulator axp20x-regulator.0: probe with driver axp20x-regulator failed with error -22 ================== Set the limits to values that can be programmed, so any correction will be successful. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Fixes: 1e1dea72651b ("ARM: dts: sun9i: cubieboard4: Add AXP809 PMIC device node and regulators") Link: https://patch.msgid.link/20241007222916.19013-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e6d94a5777b4db1067a09c0b9d325be2bbabd52d Author: Clark Wang <xiaoning.wang@nxp.com> Date: Tue Oct 8 15:41:23 2024 -0400 pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle [ Upstream commit a25351e4c7740eb22561a3ee4ef17611c6f410b0 ] Implement workaround for ERR051198 (https://www.nxp.com/docs/en/errata/IMX8MN_0N14Y.pdf) PWM output may not function correctly if the FIFO is empty when a new SAR value is programmed. Description: When the PWM FIFO is empty, a new value programmed to the PWM Sample register (PWM_PWMSAR) will be directly applied even if the current timer period has not expired. If the new SAMPLE value programmed in the PWM_PWMSAR register is less than the previous value, and the PWM counter register (PWM_PWMCNR) that contains the current COUNT value is greater than the new programmed SAMPLE value, the current period will not flip the level. This may result in an output pulse with a duty cycle of 100%. Workaround: Program the current SAMPLE value in the PWM_PWMSAR register before updating the new duty cycle to the SAMPLE value in the PWM_PWMSAR register. This will ensure that the new SAMPLE value is modified during a non-empty FIFO, and can be successfully updated after the period expires. Write the old SAR value before updating the new duty cycle to SAR. This avoids writing the new value into an empty FIFO. This only resolves the issue when the PWM period is longer than 2us (or <500kHz) because write register is not quick enough when PWM period is very short. Reproduce steps: cd /sys/class/pwm/pwmchip1/pwm0 echo 2000000000 > period # It is easy to observe by using long period echo 1000000000 > duty_cycle echo 1 > enable echo 8000 > duty_cycle # One full high pulse will be seen by scope Fixes: 166091b1894d ("[ARM] MXC: add pwm driver for i.MX SoCs") Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20241008194123.1943141-1-Frank.Li@nxp.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 19b579580d2b55cb8d6a159e7e9525ea5e8b20e6 Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Date: Fri Oct 25 16:03:51 2024 +0800 arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns [ Upstream commit 6ff2d45f2121c698a57c959ae21885a048615908 ] Add i2c2's i2c-scl-internal-delay-ns. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-4-9be1bcaf35e0@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4a1675579406c789aa200bb0bff929dd49ea53bf Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Date: Fri Oct 25 16:03:50 2024 +0800 arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns [ Upstream commit bd0eb3b1f7aee698b86513edf10a50e2d0c7cb14 ] Add i2c2's i2c-scl-internal-delay-ns. Fixes: 52e84f233459 ("arm64: dts: mt8183: Add kukui-jacuzzi-cozmo board") Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-3-9be1bcaf35e0@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 077c1aca8472d835da35e1ae5e51fd36f606bc57 Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Date: Fri Oct 25 16:03:49 2024 +0800 arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns [ Upstream commit 85af64983889c621e8868b744c8ca03bd5038c02 ] Add i2c2's i2c-scl-internal-delay-ns. Fixes: dd6e3b06214f ("arm64: dts: mt8183: Add kukui-jacuzzi-burnet board") Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-2-9be1bcaf35e0@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 340b840a8bc4efa2c935271f39e931c64e0d7c3a Author: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Date: Fri Oct 25 16:03:48 2024 +0800 arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns [ Upstream commit c802db127dfb9602aaa9338e433c0553d34f1a9c ] Add i2c2's i2c-scl-internal-delay-ns. Fixes: 6cd7fdc8c530 ("arm64: dts: mt8183: Add kukui-jacuzzi-fennel board") Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Daolong Zhu <jg_daolongzhu@mediatek.corp-partner.google.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by: Link: https://lore.kernel.org/r/20241025-i2c-delay-v2-1-9be1bcaf35e0@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 393b403e9a752686436aa32452d982b9bfb13555 Author: Heiko Stuebner <heiko@sntech.de> Date: Tue Oct 8 22:39:35 2024 +0200 arm64: dts: rockchip: Remove 'enable-active-low' from two boards [ Upstream commit 4a9d7e6596f90631f21bca9cb46c6de05d8e86d4 ] The 'enable-active-low' property is not a valid, because it is the default behaviour of the fixed regulator. Only 'enable-active-high' is valid, and when this property is absent the fixed regulator will act as active low by default. Both the rk3588-orange-pi-5 and the Wolfvision pf5 io expander overlay smuggled those enable-active-low properties in, so remove them to make dtbscheck happier. Fixes: 28799a7734a0 ("arm64: dts: rockchip: add wolfvision pf5 io expander board") Cc: Michael Riesch <michael.riesch@wolfvision.net> Fixes: b6bc755d806e ("arm64: dts: rockchip: Add Orange Pi 5") Cc: Muhammed Efe Cetin <efectn@6tel.net> Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241008203940.2573684-10-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit da47bbbc585a7351de1f0b16ed5becd754ca9545 Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Date: Fri Oct 4 15:04:49 2024 +0200 power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF [ Upstream commit f82bf3c5796e1630d553669fb451e6c9d4070512 ] This driver uses various OF-specific functions and depends on phandle parsing. There's no reason to make it available to non-OF systems so add a relevant dependency switch to its Kconfig entry. Fixes: 2f1630f437df ("power: pwrseq: add a driver for the PMU module on the QCom WCN chipsets") Link: https://lore.kernel.org/r/20241004130449.51725-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f3a7499498d6e4f214ba4b1c1cc69768883cfe31 Author: Dragan Simic <dsimic@manjaro.org> Date: Mon Oct 14 12:43:41 2024 +0200 regulator: rk808: Restrict DVS GPIOs to the RK808 variant only [ Upstream commit 0d214f27c0e3d9694284c95bac1502c2d247355b ] The rk808-regulator driver supports multiple PMIC variants from the Rockckip RK80x and RK81x series, but the DVS GPIOs are supported on the RK808 variant only, according to the DT bindings [1][2][3][4][5][6] and the datasheets for the supported PMIC variants. [7][8][9][10][11][12] Thus, change the probe path so the "dvs-gpios" property is checked for and its value possibly used only when the handled PMIC variant is RK808. There's no point in doing that on the other PMIC variants, because they don't support the DVS GPIOs, and it goes against the DT bindings to allow a possible out- of-place "dvs-gpios" property to actually be handled in the driver. This eliminates the following messages, emitted when the "dvs-gpios" property isn't found in the DT, from the kernel log on boards that actually don't use the RK808 variant, which may have provided a source of confusion: rk808-regulator rk808-regulator.2.auto: there is no dvs0 gpio rk808-regulator rk808-regulator.2.auto: there is no dvs1 gpio Furthermore, demote these kernel messages to debug messages, because they are useful during the board bringup phase only. Emitting them afterwards, on the boards that use the RK808 variant, but actually don't use the DVS0/1 GPIOs, clutters the kernel log a bit, while they provide no value and may actually cause false impression that some PMIC-related issues are present. [1] Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml [2] Documentation/devicetree/bindings/mfd/rockchip,rk806.yaml [3] Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml [4] Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml [5] Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml [6] Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml [7] https://rockchip.fr/RK805%20datasheet%20V1.2.pdf [8] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2401261533_Rockchip-RK806-1_C5156483.pdf [9] https://rockchip.fr/RK808%20datasheet%20V1.4.pdf [10] https://rockchip.fr/RK816%20datasheet%20V1.3.pdf [11] https://rockchip.fr/RK817%20datasheet%20V1.01.pdf [12] https://rockchip.fr/RK818%20datasheet%20V1.0.pdf Fixes: 11375293530b ("regulator: rk808: Add regulator driver for RK818") Reported-by: Diederik de Haas <didi.debian@cknow.org> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Link: https://patch.msgid.link/9a415c59699e76fc7b88a2552520a4ca2538f44e.1728902488.git.dsimic@manjaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6b832e9fab0ce31cf8c131dbc51606c5369655be Author: Chen Ridong <chenridong@huawei.com> Date: Fri Oct 18 08:15:20 2024 +0000 cgroup/bpf: only cgroup v2 can be attached by bpf programs [ Upstream commit 2190df6c91373fdec6db9fc07e427084f232f57e ] Only cgroup v2 can be attached by bpf programs, so this patch introduces that cgroup_bpf_inherit and cgroup_bpf_offline can only be called in cgroup v2, and this can fix the memleak mentioned by commit 04f8ef5643bc ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline"), which has been reverted. Fixes: 2b0d3d3e4fcf ("percpu_ref: reduce memory footprint of percpu_ref in fast path") Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/ Signed-off-by: Chen Ridong <chenridong@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 966666b70b86c96843c4e143bd59c83e3082d1b4 Author: Chen Ridong <chenridong@huawei.com> Date: Fri Oct 18 08:15:19 2024 +0000 Revert "cgroup: Fix memory leak caused by missing cgroup_bpf_offline" [ Upstream commit feb301c60970bd2a1310a53ce2d6e4375397a51b ] This reverts commit 04f8ef5643bcd8bcde25dfdebef998aea480b2ba. Only cgroup v2 can be attached by cgroup by BPF programs. Revert this commit and cgroup_bpf_inherit and cgroup_bpf_offline won't be called in cgroup v1. The memory leak issue will be fixed with next patch. Fixes: 04f8ef5643bc ("cgroup: Fix memory leak caused by missing cgroup_bpf_offline") Link: https://lore.kernel.org/cgroups/aka2hk5jsel5zomucpwlxsej6iwnfw4qu5jkrmjhyfhesjlfdw@46zxhg5bdnr7/ Signed-off-by: Chen Ridong <chenridong@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 50dd0dd793977411859770c777a3919b13fac2f5 Author: Fei Shao <fshao@chromium.org> Date: Mon Oct 21 19:39:33 2024 +0800 arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI [ Upstream commit 7d5794e6d964940e46286fadbe69a3245fa51e44 ] The RT5682i and RT5682s drivers describe two DAIs: AIF1 supports both playback and capture, while AIF2 supports capture only. Cherry doesn't specify which DAI to use. Although this doesn't cause real issues because AIF1 happens to be the first DAI, it should be corrected: codec@1a: #sound-dai-cells: 1 was expected Update #sound-dai-cells to 1 and adjust DAI link usages accordingly. Fixes: 87728e3ccf35 ("arm64: dts: mediatek: mt8195-cherry: Specify sound DAI links and routing") Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20241021114318.1358681-1-fshao@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 280ee3c4002f1eac4b4de832955095bfd8d658e4 Author: Fei Shao <fshao@chromium.org> Date: Mon Oct 21 16:10:47 2024 +0800 arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status [ Upstream commit 6bb64877a41561bc78e0f4e9e04d524a0155d6aa ] The T-PHY controller at 0x11e40000 controls two underlying USB2 and USB3 PHY ports. The USB3 port works normally just like the others, so there's no point in disabling it separately. Otherwise, board DTs would have to enable both the T-PHY controller and one of its sub-nodes in particular, which is slightly redundant and confusing. Remove the status line in the u3port1 node, so it's ready to be used once the T-PHY controller is enabled. Fixes: 9461e0caac9e ("arm64: dts: Add MediaTek MT8188 dts and evaluation board and Makefile") Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20241021081311.543625-1-fshao@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6eec8f0cafbc8fd6855b0f78c71e6974178a434e Author: Chen-Yu Tsai <wenst@chromium.org> Date: Fri Oct 18 16:20:00 2024 +0800 arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source trackpad [ Upstream commit f766fae08f6a2eaeb45d8d2c053724c91526835c ] The Hana device has a second source option trackpad, but it is missing its regulator supply. It only works because the regulator is marked as always-on. Add the regulator supply, but leave out the post-power-on delay. Instead, document the post-power-on delay along with the reason for not adding it in a comment. Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20241018082001.1296963-1-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 678ab81b472ee137558985777b276cae88a752ae Author: Nathan Morrisson <nmorrisson@phytec.com> Date: Wed Oct 2 15:47:54 2024 -0700 arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs [ Upstream commit c33a0a02a29bde53a85407f86f332ac4bbc5ab87 ] Drop the McASP AFIFOs for better audio latency. This adds back a change that was lost while refactoring the device tree. Fixes: 554dd562a5f2 ("arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Drop McASP AFIFOs") Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20241002224754.2917895-1-nmorrisson@phytec.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f782a227c07fa152cff3fbb413973a57e6550df3 Author: Randy Dunlap <rdunlap@infradead.org> Date: Tue Oct 15 11:11:07 2024 -0700 kernel-doc: allow object-like macros in ReST output [ Upstream commit bb8fd09e2811e2386bb40b9f0d3c7dd6e7961a1e ] output_function_rst() does not handle object-like macros. It presents a trailing "()" while output_function_man() handles these macros correctly. Update output_function_rst() to handle object-like macros. Don't show the "Parameters" heading if there are no parameters. For output_function_man(), don't show the "ARGUMENTS" heading if there are no parameters. I have tested this quite a bit with my ad hoc test files for both ReST and man format outputs. The generated output looks good. Fixes: cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Horia Geanta <horia.geanta@freescale.com> Tested-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241015181107.536894-1-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 924567d6bd77446c8ef22c2b75ae2857c6f8159f Author: Sibi Sankar <quic_sibis@quicinc.com> Date: Wed Jun 12 18:10:54 2024 +0530 arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region [ Upstream commit 9ed1a2b8784262e85ec300792a1a37ebd8473be2 ] Resize the GICR register region as it currently seeps into the CPU Control Processor mailbox RX region. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Link: https://lore.kernel.org/r/20240612124056.39230-4-quic_sibis@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9f2c9a2af898fc733ae43f025a01a821f4e4aa05 Author: Hsin-Te Yuan <yuanhsinte@chromium.org> Date: Mon Sep 9 08:33:47 2024 +0000 arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4 [ Upstream commit edbde4923f208aa83abb48d4b2463299e5fc2586 ] The address of eeprom should be 50. Fixes: ff33d889567e ("arm64: dts: mt8183: Add kukui kodama board") Fixes: d1eaf77f2c66 ("arm64: dts: mt8183: Add kukui kakadu board") Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240909-eeprom-v1-2-1ed2bc5064f4@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f188d39a8fc349f323ad726de5ae4c9863d055ce Author: Hsin-Te Yuan <yuanhsinte@chromium.org> Date: Mon Sep 9 08:33:46 2024 +0000 arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4 [ Upstream commit e9c60c34948662b5d47573490ee538439b29e462 ] The address of eeprom should be 50. Fixes: cd894e274b74 ("arm64: dts: mt8183: Add krane-sku176 board") Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20240909-eeprom-v1-1-1ed2bc5064f4@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 558cc6e537ae03b8b7cddcde95f80eebb8c0c84f Author: Colin Ian King <colin.i.king@gmail.com> Date: Wed Oct 2 17:53:29 2024 +0100 media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call [ Upstream commit 24ad2d1f773a11f69eecec3ec37ea3d76f2e9e7d ] The function ub960_rxport_read is being called and afterwards ret is being checked for any failures, however ret is not being assigned to the return of the function call. Fix this by assigning ret to the return of the call which appears to be missing. Fixes: afe267f2d368 ("media: i2c: add DS90UB960 driver") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit aaef798b86fa0ea8580133b6176a92fac5b1dd8a Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Date: Thu Oct 3 19:53:15 2024 +0200 media: i2c: vgxy61: Fix an error handling path in vgxy61_detect() [ Upstream commit 0d5c92cde4d38825eeadf5b4e1534350f80a9924 ] If cci_read() fails, 'st' is set to 0 in cci_read(), so we return success, instead of the expected error code. Fix it and return the expected error. Fixes: 9a6d7f2ba2b9 ("media: i2c: st-vgxy61: Convert to CCI register access helpers") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3ffb0c3cb87202bfb215fa2939d39b5c2ba78b07 Author: Gregory Price <gourry@gourry.net> Date: Fri Sep 13 19:19:51 2024 -0400 tpm: fix signed/unsigned bug when checking event logs [ Upstream commit e6d654e9f5a97742cfe794b1c4bb5d3fb2d25e98 ] A prior bugfix that fixes a signed/unsigned error causes another signed unsigned error. A situation where log_tbl->size is invalid can cause the size passed to memblock_reserve to become negative. log_size from the main event log is an unsigned int, and the code reduces to the following u64 value = (int)unsigned_value; This results in sign extension, and the value sent to memblock_reserve becomes effectively negative. Fixes: be59d57f9806 ("efi/tpm: Fix sanity check of unsigned tbl_size being less than zero") Signed-off-by: Gregory Price <gourry@gourry.net> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e50f550766c005ec8207d7240a7d457624b7affa Author: Jonathan Marek <jonathan@marek.ca> Date: Sun Oct 13 01:11:56 2024 -0400 efi/libstub: fix efi_parse_options() ignoring the default command line [ Upstream commit aacfa0ef247b0130b7a98bb52378f8cd727a66ca ] efi_convert_cmdline() always returns a size of at least 1 because it counts the NUL terminator, so the "cmdline_size == 0" condition is never satisfied. Change it to check if the string starts with a NUL character to get the intended behavior: to use CONFIG_CMDLINE when load_options_size == 0. Fixes: 60f38de7a8d4 ("efi/libstub: Unify command line param parsing") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 673bd4b90af4bb44b561a34ea8db5b3975ffbdda Author: Stafford Horne <shorne@gmail.com> Date: Fri Sep 27 15:26:40 2024 +0100 openrisc: Implement fixmap to fix earlycon [ Upstream commit 1037d186edfc551fa7ba2d4336e74e7575a07a65 ] With commit 53c98e35dcbc ("openrisc: mm: remove unneeded early ioremap code") it was commented that early ioremap was not used in OpenRISC. I acked this but was wrong, earlycon was using it. Earlycon setup now fails with the below trace: Kernel command line: earlycon ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/ioremap.c:23 generic_ioremap_prot+0x118/0x130 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.11.0-rc5-00001-gce02fd891c38-dirty #141 Call trace: [<(ptrval)>] dump_stack_lvl+0x7c/0x9c [<(ptrval)>] dump_stack+0x1c/0x2c [<(ptrval)>] __warn+0xb4/0x108 [<(ptrval)>] ? generic_ioremap_prot+0x118/0x130 [<(ptrval)>] warn_slowpath_fmt+0x60/0x98 [<(ptrval)>] generic_ioremap_prot+0x118/0x130 [<(ptrval)>] ioremap_prot+0x20/0x30 [<(ptrval)>] of_setup_earlycon+0xd4/0x2e0 [<(ptrval)>] early_init_dt_scan_chosen_stdout+0x18c/0x1c8 [<(ptrval)>] param_setup_earlycon+0x3c/0x60 [<(ptrval)>] do_early_param+0xb0/0x118 [<(ptrval)>] parse_args+0x184/0x4b8 [<(ptrval)>] ? start_kernel+0x0/0x78c [<(ptrval)>] parse_early_options+0x40/0x50 [<(ptrval)>] ? do_early_param+0x0/0x118 [<(ptrval)>] parse_early_param+0x48/0x68 [<(ptrval)>] ? start_kernel+0x318/0x78c [<(ptrval)>] ? start_kernel+0x0/0x78c ---[ end trace 0000000000000000 ]--- To fix this we could either implement early_ioremap again or implement fixmap. In this patch we choose the later option of implementing basic fixmap support. While fixing this we also remove the old FIX_IOREMAP slots that were used by early ioremap code. That code was also removed by commit 53c98e35dcbc ("openrisc: mm: remove unneeded early ioremap code") but these definitions were not cleaned up. Fixes: 53c98e35dcbc ("openrisc: mm: remove unneeded early ioremap code") Signed-off-by: Stafford Horne <shorne@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 95f8a127beb43fb66781b4d116f84cc6b91cbc8b Author: Abel Vesa <abel.vesa@linaro.org> Date: Mon Oct 14 14:21:49 2024 +0300 arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB SS[0-1] QMP PHYs [ Upstream commit 27344eb70c8fd60fe7c570e2e12f169ff89d2c47 ] The orientation-switch is already set in the x1e80100 SoC dtsi, so drop from Vivobook S15 dts. Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241014-x1e80100-dts-drop-orientation-switch-v1-2-26afa6d4afd9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d6be133efbdfee81e0017f72324f05b2fe3f7774 Author: Abel Vesa <abel.vesa@linaro.org> Date: Mon Oct 14 14:21:48 2024 +0300 arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1] QMP PHYs [ Upstream commit eb2dd93d03b16ed0e8b09311f8d35cc5a691a9b7 ] The orientation-switch is already set in the x1e80100 SoC dtsi, so drop from Slim 7X dts. Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241014-x1e80100-dts-drop-orientation-switch-v1-1-26afa6d4afd9@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e2320daf6611334a4dce5832b5714bf71f515e56 Author: Chen-Yu Tsai <wenst@chromium.org> Date: Tue Oct 8 16:29:04 2024 +0800 scripts/kernel-doc: Do not track section counter across processed files [ Upstream commit be9264110e4e874622d588a75daf930539fdf6ea ] The section counter tracks how many sections of kernel-doc were added. The only real use of the counter value is to check if anything was actually supposed to be output and give a warning is nothing is available. The current logic of remembering the initial value and then resetting the value then when processing each file means that if a file has the same number of sections as the previously processed one, a warning is incorrectly given. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20241008082905.4005524-1-wenst@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7a867a4b0297493176f218f7d9aff93ec6be38e9 Author: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Date: Tue Oct 8 18:01:34 2024 +0200 mmc: mmc_spi: drop buggy snprintf() [ Upstream commit 328bda09cc91b3d93bc64f4a4dadc44313dd8140 ] GCC 13 complains about the truncated output of snprintf(): drivers/mmc/host/mmc_spi.c: In function ‘mmc_spi_response_get’: drivers/mmc/host/mmc_spi.c:227:64: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] 227 | snprintf(tag, sizeof(tag), " ... CMD%d response SPI_%s", | ^ drivers/mmc/host/mmc_spi.c:227:9: note: ‘snprintf’ output between 26 and 43 bytes into a destination of size 32 227 | snprintf(tag, sizeof(tag), " ... CMD%d response SPI_%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 228 | cmd->opcode, maptype(cmd)); Drop it and fold the string it generates into the only place where it's emitted - the dev_dbg() call at the end of the function. Fixes: 15a0580ced08 ("mmc_spi host driver") Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20241008160134.69934-1-brgl@bgdev.pl Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5edd201a4c36b7847b34e837d7ed4354f138e0b9 Author: Andrei Simion <andrei.simion@microchip.com> Date: Thu Sep 12 12:33:07 2024 +0300 ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode [ Upstream commit 2f9d013a0c6f1b9109ada5acb28ee26eefc77c03 ] Add the atmel,usart-mode property to the UART nodes. This ensures compliance with the atmel,at91-usart.yaml schema and resolves the errors below: serial@200: $nodename:0: 'serial@200' does not match '^spi(@.*|-([0-9]|[1-9][0-9]+))?$' serial@200: atmel,use-dma-rx: False schema does not allow True serial@200: atmel,use-dma-tx: False schema does not allow True serial@200: atmel,fifo-size: False schema does not allow [[16]] These errors indicate that the property atmel,usart-mode = <AT91_USART_MODE_SERIAL> is missing for UART nodes 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, and 12. Fixes: 99c808335877 ("ARM: dts: at91: sam9x60: Add missing flexcom definitions") Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Andrei Simion <andrei.simion@microchip.com> Link: https://lore.kernel.org/r/20240912093307.40488-1-andrei.simion@microchip.com [claudiu.beznea: move the atmel,usart-mode close to vendor specific properties to cope with DTS coding style] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f2d249c0c1f6b5dd6e981ff470a26e95c071c1de Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Sat Sep 7 21:48:15 2024 +0300 arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges [ Upstream commit 1dd7d9d41dedf8d42e04c0f2febd4dbe5a062d4a ] L10A, being a fixed regulator, should have min_voltage = max_voltage, otherwise fixed rulator fails to probe. Fix the max_voltage range to be equal to minimum. Fixes: 4edbcf264fe2 ("arm64: dts: qcom: sda660-ifc6560: document missing USB PHY supplies") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konradybcio@kernel.org> Link: https://lore.kernel.org/r/20240907-sdm660-wifi-v1-4-e316055142f8@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9f20b3348f9e7ea84bd61724afcd6a7188a79fb0 Author: Luca Weiss <luca.weiss@fairphone.com> Date: Wed Oct 2 14:58:06 2024 +0200 arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins [ Upstream commit 600c499f8f5297c2c91e8146a8217f299e445ef6 ] Make sure the GPU frequencies are marked as supported for the respective speedbins according to downstream msm-4.19 kernel: * 850 MHz: Speedbins 0 + 180 * 800 MHz: Speedbins 0 + 180 + 169 * 650 MHz: Speedbins 0 + 180 + 169 + 138 * 565 MHz: Speedbins 0 + 180 + 169 + 138 + 120 * 430 MHz: Speedbins 0 + 180 + 169 + 138 + 120 * 355 MHz: Speedbins 0 + 180 + 169 + 138 + 120 * 253 MHz: Speedbins 0 + 180 + 169 + 138 + 120 Fixes: bd9b76750280 ("arm64: dts: qcom: sm6350: Add GPU nodes") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20241002-sm6350-gpu-speedbin-fix-v1-1-8a5d90c5097d@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 56eda41dcce0ec4d3418b4f85037bdea181486cc Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Mon Sep 30 10:51:31 2024 +0300 soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get() [ Upstream commit 78261cb08f06c93d362cab5c5034bf5899bc7552 ] This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration. However, that check doesn't make sense on the first iteration through the loop. It leads to reading before the start of these->clk_perf_tbl[] array. Fixes: eddac5af0654 ("soc: qcom: Add GENI based QUP Wrapper driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/8cd12678-f44a-4b16-a579-c8f11175ee8c@stanley.mountain Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f76f8573f233ecd4116cbaea13f6cce8a01ea27d Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Thu Sep 12 11:41:47 2024 +0800 soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 16a0a69244240cfa32c525c021c40f85e090557a ] If request_irq() fails in sr_late_init(), there is no need to enable the irq, and if it succeeds, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 1279ba5916f6 ("OMAP3+: SR: disable interrupt by default") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20240912034147.3014213-1-ruanjinjie@huawei.com Signed-off-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 37cd1fbfaf3bb12f3c1b9e0311d63590a18d4ab1 Author: Macpaul Lin <macpaul.lin@mediatek.com> Date: Wed Oct 2 13:16:16 2024 +0800 arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node [ Upstream commit c14ab45f5d458073248ddc62d31045d5d616806f ] The infracfg_ao node in mt8195.dtsi was causing a dtbs_check error. The error message was: syscon@10001000: compatible: ['mediatek,mt8195-infracfg_ao', 'syscon', 'simple-mfd'] is too long To resolve this, remove 'simple-mfd' from the 'compatible' property of the infracfg_ao node. Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20241002051620.2050-1-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ed85a109e33fe3c28d642dca6a9f727307746ecc Author: Macpaul Lin <macpaul.lin@mediatek.com> Date: Wed Oct 2 13:16:19 2024 +0800 arm64: dts: mt8195: Fix dtbs_check error for mutex node [ Upstream commit 0fc557b539a1e11bdc5053a308b12d84ea754786 ] The mutex node in mt8195.dtsi was triggering a dtbs_check error: mutex@1c101000: 'clock-names', 'reg-names' do not match any of the regexes: 'pinctrl-[0-9]+' This seems no need by inspecting the DT schemas and other reference boards, so drop 'clock-names' and 'reg-names' in mt8195.dtsi. Fixes: 92d2c23dc269 ("arm64: dts: mt8195: add display node for vdosys1") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20241002051620.2050-4-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f079ec9e2e2326acf5c8da36549de8a0b164f92e Author: Macpaul Lin <macpaul.lin@mediatek.com> Date: Wed Oct 2 13:16:18 2024 +0800 arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy [ Upstream commit 752804acea010959bb3a00c65acdf78086a8474c ] The ethernet-phy node in mt8395-genio-1200-evk.dts was triggering a dtbs_check error. The error message was: eth-phy0@1: $nodename:0: 'eth-phy0@1' does not match '^ethernet-phy(@[a-f0-9]+)?$' Fix this issue by replacing 'eth-phy' node to generic 'ethernet-phy'. Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK board") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20241002051620.2050-3-macpaul.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f3e4759f4c68496305537dbebeef3fb32c450aba Author: Pablo Sun <pablo.sun@mediatek.com> Date: Wed Oct 2 10:21:33 2024 +0800 arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain [ Upstream commit 4007651c25553b10dbc6e7bff6b7abd2863c1702 ] The clock index "CLK_APMIXED_MFGPLL" belongs to the "apmixedsys" provider, so fix the index. In addition, add a "mfg1" label so following commits could set domain-supply for MFG1 power domain. Fixes: eaf73e4224a3 ("arm64: dts: mediatek: mt8188: Add support for SoC power domains") Signed-off-by: Pablo Sun <pablo.sun@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20241002022138.29241-2-pablo.sun@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 62317d40fad140d4f1af7ca3bb2be46b0a433ccf Author: Michal Simek <michal.simek@amd.com> Date: Wed Jun 19 14:11:32 2024 +0200 microblaze: Export xmb_manager functions [ Upstream commit badf752b5e4b17d281f93f409d4718388ff912e6 ] When TMR_MANAGER is enabled as module there is a need to export functions which are present in architecture code. It has been found by running: make W=1 C=1 allmodconfig sed -i -e 's/WERROR=y/WERROR=n/g' .config make C=1 W=1 which errors out like this: ERROR: modpost: "xmb_manager_register" [drivers/misc/xilinx_tmr_manager.ko] undefined! ERROR: modpost: "xmb_inject_err" [drivers/misc/xilinx_tmr_inject.ko] undefined! Fixes: a5e3aaa654c1 ("microblaze: Add xmb_manager_register function") Reported-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/e322dbbbde0feef83f44304ea13249d365d1dc5f.1718799090.git.michal.simek@amd.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5a3bda42394ff137eb2d3d3d20d2956a8c6e9237 Author: Gaosheng Cui <cuigaosheng1@huawei.com> Date: Sat Jul 6 14:51:55 2024 +0800 drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend() [ Upstream commit 44ed4f90a97ff6f339e50ac01db71544e0990efc ] If we fail to allocate memory for cb_data by kmalloc, the memory allocation for eve_data is never freed, add the missing kfree() in the error handling path. Fixes: 05e5ba40ea7a ("driver: soc: xilinx: Add support of multiple callbacks for same event in event management driver") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Link: https://lore.kernel.org/r/20240706065155.452764-1-cuigaosheng1@huawei.com Signed-off-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d8635acb7e6a5ab72eaecefab61fb3d6f62391b2 Author: Wolfram Sang <wsa+renesas@sang-engineering.com> Date: Sat Sep 14 20:28:44 2024 +0200 ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash [ Upstream commit 48e17816c3effa3545e21cd4f7d5a00c55c17a18 ] Second partition was too large, looks like two digits got mixed up. Fixes: mtd: partition "user1" extends beyond the end of device "18000000.flash" -- size truncated to 0x4000000 Fixes: 30e0a8cf886c ("ARM: dts: renesas: genmai: Add FLASH nodes") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20240914182948.94031-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 446663db1e6953e7178dcd9cd7148d0d79fe5481 Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Date: Sat Sep 7 15:51:24 2024 +0300 arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP [ Upstream commit 6317aad0e1525f3e3609d9a0fea762a37799943a ] Newer boards should always use squashed MBN firmware instead of split MDT+bNN. Use qcom/qcs6490/modem.mbn as the firmware for the modem on RB3gen2. Fixes: ac6d35b9b74c ("arm64: dts: qcom: qcs6490-rb3gen2: Enable various remoteprocs") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Konrad Dybcio <konradybcio@kernel.org> Link: https://lore.kernel.org/r/20240907-rb3g2-fixes-v1-1-eb9da98e9f80@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f56db30036c710308599a397fa3ef5f6a320afc3 Author: Jinjie Ruan <ruanjinjie@huawei.com> Date: Fri Sep 6 10:28:28 2024 +0800 spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq() [ Upstream commit 003c7e01916c5e2af95add9b0cbda2e6163873e8 ] disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 9728fb3ce117 ("spi: lpspi: disable lpspi module irq in DMA mode") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20240906022828.891812-1-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6f1b0dc2ab6e3e46eb83b843806589449c2ff185 Author: Min-Hua Chen <minhuadotchen@gmail.com> Date: Fri Sep 27 07:10:36 2024 +0800 regulator: qcom-smd: make smd_vreg_rpm static [ Upstream commit 18be43aca2c0ec475037923a8086d0a29fcc9d16 ] Since smd_vreg_rpm is used only in drivers/regulator/qcom_smd-regulator.c, make it static and fix the following sparse warning: drivers/regulator/qcom_smd-regulator.c:14:21: sparse: warning: symbol 'smd_vreg_rpm' was not declared. Should it be static? No functional changes intended. Fixes: 5df3b41bd6b5 ("regulator: qcom_smd: Keep one rpm handle for all vregs") Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20240926231038.31916-1-minhuadotchen@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6ed4ccac4683db9aecce2168c43269a138e9fa69 Author: Javier Carrasco <javier.carrasco.cruz@gmail.com> Date: Thu Oct 31 13:54:23 2024 +0100 clocksource/drivers/timer-ti-dm: Fix child node refcount handling [ Upstream commit e5cfc0989d9a2849c51c720a16b90b2c061a1aeb ] of_find_compatible_node() increments the node's refcount, and it must be decremented again with a call to of_node_put() when the pointer is no longer required to avoid leaking the resource. Instead of adding the missing calls to of_node_put() in all execution paths, use the cleanup attribute for 'arm_timer' by means of the __free() macro, which automatically calls of_node_put() when the variable goes out of scope. Fixes: 25de4ce5ed02 ("clocksource/drivers/timer-ti-dm: Handle dra7 timer wrap errata i940") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20241031-timer-ti-dm-systimer-of_node_put-v3-1-063ee822b73a@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 886ad779fa51ce14923cebb233766215b4a3fea4 Author: Mark Brown <broonie@kernel.org> Date: Tue Oct 1 12:23:56 2024 +0100 clocksource/drivers:sp804: Make user selectable [ Upstream commit 0309f714a0908e947af1c902cf6a330cb593e75e ] The sp804 is currently only user selectable if COMPILE_TEST, this was done by commit dfc82faad725 ("clocksource/drivers/sp804: Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804") in order to avoid it being spuriously offered on platforms that won't have the hardware since it's generally only seen on Arm based platforms. This config is overly restrictive, while platforms that rely on the SP804 do select it in their Kconfig there are others such as the Arm fast models which have a SP804 available but currently unused by Linux. Relax the dependency to allow it to be user selectable on arm and arm64 to avoid surprises and in case someone comes up with a use for extra timer hardware. Fixes: dfc82faad725 ("clocksource/drivers/sp804: Add COMPILE_TEST to CONFIG_ARM_TIMER_SP804") Reported-by: Ross Burton <ross.burton@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241001-arm64-vexpress-sp804-v3-1-0a2d3f7883e4@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d8764401f7492c9dc4407cba681d3fccb0c964f0 Author: Marco Elver <elver@google.com> Date: Mon Nov 4 16:43:09 2024 +0100 kcsan, seqlock: Fix incorrect assumption in read_seqbegin() [ Upstream commit 183ec5f26b2fc97a4a9871865bfe9b33c41fddb2 ] During testing of the preceding changes, I noticed that in some cases, current->kcsan_ctx.in_flat_atomic remained true until task exit. This is obviously wrong, because _all_ accesses for the given task will be treated as atomic, resulting in false negatives i.e. missed data races. Debugging led to fs/dcache.c, where we can see this usage of seqlock: struct dentry *d_lookup(const struct dentry *parent, const struct qstr *name) { struct dentry *dentry; unsigned seq; do { seq = read_seqbegin(&rename_lock); dentry = __d_lookup(parent, name); if (dentry) break; } while (read_seqretry(&rename_lock, seq)); [...] As can be seen, read_seqretry() is never called if dentry != NULL; consequently, current->kcsan_ctx.in_flat_atomic will never be reset to false by read_seqretry(). Give up on the wrong assumption of "assume closing read_seqretry()", and rely on the already-present annotations in read_seqcount_begin/retry(). Fixes: 88ecd153be95 ("seqlock, kcsan: Add annotations for KCSAN") Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20241104161910.780003-6-elver@google.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit b3c1141fbb8bbc155f9efa233a7fe558c1d95976 Author: Marco Elver <elver@google.com> Date: Mon Nov 4 16:43:07 2024 +0100 kcsan, seqlock: Support seqcount_latch_t [ Upstream commit 5c1806c41ce0a0110db5dd4c483cf2dc28b3ddf0 ] While fuzzing an arm64 kernel, Alexander Potapenko reported: | BUG: KCSAN: data-race in ktime_get_mono_fast_ns / timekeeping_update | | write to 0xffffffc082e74248 of 56 bytes by interrupt on cpu 0: | update_fast_timekeeper kernel/time/timekeeping.c:430 [inline] | timekeeping_update+0x1d8/0x2d8 kernel/time/timekeeping.c:768 | timekeeping_advance+0x9e8/0xb78 kernel/time/timekeeping.c:2344 | update_wall_time+0x18/0x38 kernel/time/timekeeping.c:2360 | [...] | | read to 0xffffffc082e74258 of 8 bytes by task 5260 on cpu 1: | __ktime_get_fast_ns kernel/time/timekeeping.c:372 [inline] | ktime_get_mono_fast_ns+0x88/0x174 kernel/time/timekeeping.c:489 | init_srcu_struct_fields+0x40c/0x530 kernel/rcu/srcutree.c:263 | init_srcu_struct+0x14/0x20 kernel/rcu/srcutree.c:311 | [...] | | value changed: 0x000002f875d33266 -> 0x000002f877416866 | | Reported by Kernel Concurrency Sanitizer on: | CPU: 1 UID: 0 PID: 5260 Comm: syz.2.7483 Not tainted 6.12.0-rc3-dirty #78 This is a false positive data race between a seqcount latch writer and a reader accessing stale data. Since its introduction, KCSAN has never understood the seqcount_latch interface (due to being unannotated). Unlike the regular seqlock interface, the seqcount_latch interface for latch writers never has had a well-defined critical section, making it difficult to teach tooling where the critical section starts and ends. Introduce an instrumentable (non-raw) seqcount_latch interface, with which we can clearly denote writer critical sections. This both helps readability and tooling like KCSAN to understand when the writer is done updating all latch copies. Fixes: 88ecd153be95 ("seqlock, kcsan: Add annotations for KCSAN") Reported-by: Alexander Potapenko <glider@google.com> Co-developed-by: "Peter Zijlstra (Intel)" <peterz@infradead.org> Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20241104161910.780003-4-elver@google.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6193f715a4e181f828e8bdaed121b5f4cdd5a268 Author: Uros Bizjak <ubizjak@gmail.com> Date: Sun Nov 3 17:09:32 2024 +0100 locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu() [ Upstream commit 25cf4fbb596d730476afcc0fb87a9d708db14078 ] x86_32 __arch_{,try_}cmpxchg64_emu()() macros use CALL instruction inside asm statement. Use ALT_OUTPUT_SP() macro to add required dependence on %esp register. Fixes: 79e1dd05d1a2 ("x86: Provide an alternative() based cmpxchg64()") Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20241103160954.3329-2-ubizjak@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4c7e91a17ae82df30d7ad5272307da95488f0455 Author: Uros Bizjak <ubizjak@gmail.com> Date: Sun Nov 3 17:09:31 2024 +0100 locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64() [ Upstream commit 8b64db9733c2e4d30fd068d0b9dcef7b4424b035 ] CONFIG_X86_CMPXCHG64 variant of x86_32 __alternative_atomic64() macro uses CALL instruction inside asm statement. Use ALT_OUTPUT_SP() macro to add required dependence on %esp register. Fixes: 819165fb34b9 ("x86: Adjust asm constraints in atomic64 wrappers") Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20241103160954.3329-1-ubizjak@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit c2de7ac2d7989e38df1cc2f6a0baeb4dd2f388d1 Author: Miguel Ojeda <ojeda@kernel.org> Date: Fri Oct 25 13:01:41 2024 +0200 time: Fix references to _msecs_to_jiffies() handling of values [ Upstream commit 92b043fd995a63a57aae29ff85a39b6f30cd440c ] The details about the handling of the "normal" values were moved to the _msecs_to_jiffies() helpers in commit ca42aaf0c861 ("time: Refactor msecs_to_jiffies"). However, the same commit still mentioned __msecs_to_jiffies() in the added documentation. Thus point to _msecs_to_jiffies() instead. Fixes: ca42aaf0c861 ("time: Refactor msecs_to_jiffies") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241025110141.157205-2-ojeda@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1d4367cf4a918850520b0d847a549582b62788a1 Author: Miguel Ojeda <ojeda@kernel.org> Date: Fri Oct 25 13:01:40 2024 +0200 time: Partially revert cleanup on msecs_to_jiffies() documentation [ Upstream commit b05aefc1f5886c8aece650c9c1639c87b976191a ] The documentation's intention is to compare msecs_to_jiffies() (first sentence) with __msecs_to_jiffies() (second sentence), which is what the original documentation did. One of the cleanups in commit f3cb80804b82 ("time: Fix various kernel-doc problems") may have thought the paragraph was talking about the latter since that is what it is being documented. Thus revert that part of the change. Fixes: f3cb80804b82 ("time: Fix various kernel-doc problems") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/20241025110141.157205-1-ojeda@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5f4b90972111e994d8599230cd8ca8d06dfcc125 Author: Uros Bizjak <ubizjak@gmail.com> Date: Mon Aug 19 09:41:15 2024 +0200 cleanup: Remove address space of returned pointer [ Upstream commit f730fd535fc51573f982fad629f2fc6b4a0cde2f ] Guard functions in local_lock.h are defined using DEFINE_GUARD() and DEFINE_LOCK_GUARD_1() macros having lock type defined as pointer in the percpu address space. The functions, defined by these macros return value in generic address space, causing: cleanup.h:157:18: error: return from pointer to non-enclosed address space and cleanup.h:214:18: error: return from pointer to non-enclosed address space when strict percpu checks are enabled. Add explicit casts to remove address space of the returned pointer. Found by GCC's named address space checks. Fixes: e4ab322fbaaa ("cleanup: Add conditional guard support") Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20240819074124.143565-1-ubizjak@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit c85d046893221e4d826bc214d75e072e0207ed84 Author: Carlos Llamas <cmllamas@google.com> Date: Mon Aug 12 23:01:20 2024 +0000 Revert "scripts/faddr2line: Check only two symbols when calculating symbol size" [ Upstream commit 56ac7bd2c58a4e93d19f0ccb181035d075b315d3 ] This reverts commit c02904f05ff805d6c0631634d5751ebd338f75ec. Such commit assumed that only two symbols are relevant for the symbol size calculation. However, this can lead to an incorrect symbol size calculation when there are mapping symbols emitted by readelf. For instance, when feeding 'update_irq_load_avg+0x1c/0x1c4', faddr2line might need to process the following readelf lines: 784284: ffffffc0081cca30 428 FUNC GLOBAL DEFAULT 2 update_irq_load_avg 87319: ffffffc0081ccb0c 0 NOTYPE LOCAL DEFAULT 2 $x.62522 87321: ffffffc0081ccbdc 0 NOTYPE LOCAL DEFAULT 2 $x.62524 87323: ffffffc0081ccbe0 0 NOTYPE LOCAL DEFAULT 2 $x.62526 87325: ffffffc0081ccbe4 0 NOTYPE LOCAL DEFAULT 2 $x.62528 87327: ffffffc0081ccbe8 0 NOTYPE LOCAL DEFAULT 2 $x.62530 87329: ffffffc0081ccbec 0 NOTYPE LOCAL DEFAULT 2 $x.62532 87331: ffffffc0081ccbf0 0 NOTYPE LOCAL DEFAULT 2 $x.62534 87332: ffffffc0081ccbf4 0 NOTYPE LOCAL DEFAULT 2 $x.62535 783403: ffffffc0081ccbf4 424 FUNC GLOBAL DEFAULT 2 sched_pelt_multiplier The symbol size of 'update_irq_load_avg' should be calculated with the address of 'sched_pelt_multiplier', after skipping the mapping symbols seen in between. However, the offending commit cuts the list short and faddr2line incorrectly assumes 'update_irq_load_avg' is the last symbol in the section, resulting in: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 skipping update_irq_load_avg address at 0xffffffc0081cca4c due to size mismatch (0x1c4 != 0x3ff9a59988) no match for update_irq_load_avg+0x1c/0x1c4 After reverting the commit the issue is resolved: $ scripts/faddr2line vmlinux update_irq_load_avg+0x1c/0x1c4 update_irq_load_avg+0x1c/0x1c4: cpu_of at kernel/sched/sched.h:1109 (inlined by) update_irq_load_avg at kernel/sched/pelt.c:481 Fixes: c02904f05ff8 ("scripts/faddr2line: Check only two symbols when calculating symbol size") Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Will Deacon <will@kernel.org> Acked-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 12b2fe091f0d2af82166c93c0a131405edc77f9b Author: Zheng Yejian <zhengyejian@huaweicloud.com> Date: Fri Sep 13 10:45:01 2024 +0800 x86/unwind/orc: Fix unwind for newly forked tasks [ Upstream commit 3bf19a0fb690022ec22ce87a5afeb1030cbcb56c ] When arch_stack_walk_reliable() is called to unwind for newly forked tasks, the return value is negative which means the call stack is unreliable. This obviously does not meet expectations. The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed to 'ret_from_fork_asm' (see copy_thread()), then at the start of the unwind, it is incorrectly interprets not as a "signal" one because 'ret_from_fork' is still used to determine the initial "signal" (see __unwind_start()). Then the address gets incorrectly decremented in the call to orc_find() (see unwind_next_frame()) and resulting in the incorrect ORC data. To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in __unwind_start(). Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C") Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 84018a3262aba4425ba6e3e411a1cdca8790aeca Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Thu Oct 24 12:59:38 2024 +0200 thermal/lib: Fix memory leak on error in thermal_genl_auto() [ Upstream commit 7569406e95f2353070d88ebc88e8c13698542317 ] The function thermal_genl_auto() does not free the allocated message in the error path. Fix that by putting a out label and jump to it which will free the message instead of directly returning an error. Fixes: 47c4b0de080a ("tools/lib/thermal: Add a thermal library") Reported-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20241024105938.1095358-1-daniel.lezcano@linaro.org [ rjw: Fixed up the !msg error path, added Fixes tag ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e5221848ffb5049d2951bd5f06396b4ac098d9fe Author: Daniel Lezcano <daniel.lezcano@linaro.org> Date: Tue Oct 22 17:51:43 2024 +0200 tools/lib/thermal: Make more generic the command encoding function [ Upstream commit 24b216b2d13568c703a76137ef54a2a9531a71d8 ] The thermal netlink has been extended with more commands which require an encoding with more information. The generic encoding function puts the thermal zone id with the command name. It is the unique parameters. The next changes will provide more parameters to the command. Set the scene for those new parameters by making the encoding function more generic. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://patch.msgid.link/20241022155147.463475-4-daniel.lezcano@linaro.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Stable-dep-of: 7569406e95f2 ("thermal/lib: Fix memory leak on error in thermal_genl_auto()") Signed-off-by: Sasha Levin <sashal@kernel.org> commit e1a056235f3fa283db779279d75053ebb07a6ef3 Author: Uladzislau Rezki (Sony) <urezki@gmail.com> Date: Wed Nov 13 12:00:08 2024 +0100 rcuscale: Do a proper cleanup if kfree_scale_init() fails [ Upstream commit 812a1c3b9f7c36d9255f0d29d0a3d324e2f52321 ] A static analyzer for C, Smatch, reports and triggers below warnings: kernel/rcu/rcuscale.c:1215 rcu_scale_init() warn: inconsistent returns 'global &fullstop_mutex'. The checker complains about, we do not unlock the "fullstop_mutex" mutex, in case of hitting below error path: <snip> ... if (WARN_ON_ONCE(jiffies_at_lazy_cb - jif_start < 2 * HZ)) { pr_alert("ERROR: call_rcu() CBs are not being lazy as expected!\n"); WARN_ON_ONCE(1); return -1; ^^^^^^^^^^ ... <snip> it happens because "-1" is returned right away instead of doing a proper unwinding. Fix it by jumping to "unwind" label instead of returning -1. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Closes: https://lore.kernel.org/rcu/ZxfTrHuEGtgnOYWp@pc636/T/ Fixes: 084e04fff160 ("rcuscale: Add laziness and kfree tests") Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f0c2a4d342997b97a70493c667d38c4dbf4521db Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Date: Fri Nov 8 18:22:27 2024 +0100 crypto: cavium - Fix an error handling path in cpt_ucode_load_fw() [ Upstream commit 572b7cf08403b6c67dfe0dc3e0f2efb42443254f ] If do_cpt_init() fails, a previous dma_alloc_coherent() call needs to be undone. Add the needed dma_free_coherent() before returning. Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ee36db8e8203420e6d5c42eb9428920c2fc36532 Author: Chen Ridong <chenridong@huawei.com> Date: Mon Nov 4 12:17:45 2024 +0000 crypto: bcm - add error check in the ahash_hmac_init function [ Upstream commit 19630cf57233e845b6ac57c9c969a4888925467b ] The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Chen Ridong <chenridong@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8a5f46d030f28e926a7a322aab64dceb38c1a17d Author: Chen Ridong <chenridong@huawei.com> Date: Mon Nov 4 12:15:11 2024 +0000 crypto: caam - add error check to caam_rsa_set_priv_key_form [ Upstream commit b64140c74e954f1db6eae5548ca3a1f41b6fad79 ] The caam_rsa_set_priv_key_form did not check for memory allocation errors. Add the checks to the caam_rsa_set_priv_key_form functions. Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2") Signed-off-by: Chen Ridong <chenridong@huawei.com> Reviewed-by: Gaurav Jain <gaurav.jain@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b5643b1e1e94b9a5c8a318e82edcca508b2e7889 Author: Lifeng Zheng <zhenglifeng1@huawei.com> Date: Wed Nov 13 18:33:09 2024 +0800 ACPI: CPPC: Fix _CPC register setting issue [ Upstream commit 2388b266c9fcc7c9169ba85c7f9ebe325b7622d7 ] Since commit 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage"), _CPC registers cannot be changed from 1 to 0. It turns out that there is an extra OR after MASK_VAL_WRITE(), which has already ORed prev_val with the register mask. Remove the extra OR to fix the problem. Fixes: 60949b7b8054 ("ACPI: CPPC: Fix MASK_VAL() usage") Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Link: https://patch.msgid.link/20241113103309.761031-1-zhenglifeng1@huawei.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a4712e4485f5c388bbe0d0e8f52978241ab34a29 Author: Pei Xiao <xiaopei01@kylinos.cn> Date: Tue Nov 12 09:39:51 2024 +0800 hwmon: (nct6775-core) Fix overflows seen when writing limit attributes [ Upstream commit 57ee12b6c514146c19b6a159013b48727a012960 ] DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large number such as 18446744073709551615 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: c3963bc0a0cf ("hwmon: (nct6775) Split core and platform driver") Message-ID: <7d5084cea33f7c0fd0578c59adfff71f93de94d9.1731375425.git.xiaopei01@kylinos.cn> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7cad9f0ba9e6e562101aa0f119fc8ba53d565079 Author: Jerome Brunet <jbrunet@baylibre.com> Date: Tue Nov 5 18:58:42 2024 +0100 hwmon: (pmbus/core) clear faults after setting smbalert mask [ Upstream commit 509c3a362675bc995771df74d545548f98e37621 ] pmbus_write_smbalert_mask() ignores the errors if the chip can't set smbalert mask the standard way. It is not necessarily a problem for the irq support if the chip is otherwise properly setup but it may leave an uncleared fault behind. pmbus_core will pick the fault on the next register_check(). The register check will fails regardless of the actual register support by the chip. This leads to missing attributes or debugfs entries for chips that should provide them. We cannot rely on register_check() as PMBUS_SMBALERT_MASK may be read-only. Unconditionally clear the page fault after setting PMBUS_SMBALERT_MASK to avoid the problem. Suggested-by: Guenter Roeck <linux@roeck-us.net> Fixes: 221819ca4c36 ("hwmon: (pmbus/core) Add interrupt support") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Message-ID: <20241105-tps25990-v4-5-0e312ac70b62@baylibre.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 05b8ea1f16667f07c8e5843fb4bde3e49d49ead8 Author: Uladzislau Rezki (Sony) <urezki@gmail.com> Date: Tue Oct 22 12:53:07 2024 +0200 rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu [ Upstream commit a23da88c6c80e41e0503e0b481a22c9eea63f263 ] KCSAN reports a data race when access the krcp->monitor_work.timer.expires variable in the schedule_delayed_monitor_work() function: <snip> BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1: schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline] kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143 __sys_bpf+0x2e5/0x7a0 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline] __se_sys_bpf kernel/bpf/syscall.c:5739 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0: __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173 add_timer_global+0x51/0x70 kernel/time/timer.c:1330 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552 queue_delayed_work include/linux/workqueue.h:677 [inline] schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline] kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391 kthread+0x1d1/0x210 kernel/kthread.c:389 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_unbound kfree_rcu_monitor <snip> kfree_rcu_monitor() rearms the work if a "krcp" has to be still offloaded and this is done without holding krcp->lock, whereas the kvfree_call_rcu() holds it. Fix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so both functions do not race anymore. Reported-by: syzbot+061d370693bdd99f9d34@syzkaller.appspotmail.com Link: https://lore.kernel.org/lkml/ZxZ68KmHDQYU0yfD@pc636/T/ Fixes: 8fc5494ad5fa ("rcu/kvfree: Move need_offload_krc() out of krcp->lock") Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bd69a2cb7fa0af29084e55bc2be7d4d5420a4a40 Author: Michal Schmidt <mschmidt@redhat.com> Date: Mon Oct 7 12:14:15 2024 +0200 rcu/srcutiny: don't return before reenabling preemption [ Upstream commit 0ea3acbc804c2d5a165442cdf9c0526f4d324888 ] Code after the return statement is dead. Enable preemption before returning from srcu_drive_gp(). This will be important when/if PREEMPT_AUTO (lazy resched) gets merged. Fixes: 65b4a59557f6 ("srcu: Make Tiny SRCU explicitly disable preemption") Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Reviewed-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d3fe044b3e79a7fd60040a5ed3e868bf056ca67c Author: Baruch Siach <baruch@tkos.co.il> Date: Sun Aug 18 11:18:17 2024 +0300 doc: rcu: update printed dynticks counter bits [ Upstream commit 4a09e358922381f9b258e863bcd9c910584203b9 ] The stall warning prints 16 bits since commit 171476775d32 ("context_tracking: Convert state to atomic_t"). Fixes: 171476775d32 ("context_tracking: Convert state to atomic_t") Signed-off-by: Baruch Siach <baruch@tkos.co.il> Reviewed-by: "Paul E. McKenney" <paulmck@kernel.org> Signed-off-by: Neeraj Upadhyay <neeraj.upadhyay@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3ab5281e1ba3bcf41da919afcf84ddb64ad0e039 Author: Christian Loehle <christian.loehle@arm.com> Date: Sat Nov 9 00:24:14 2024 +0000 sched/cpufreq: Ensure sd is rebuilt for EAS check [ Upstream commit 70d8b6485b0bcd135b6699fc4252d2272818d1fb ] Ensure sugov_eas_rebuild_sd() is always called when sugov_init() succeeds. The out goto initialized sugov without forcing the rebuild. Previously the missing call to sugov_eas_rebuild_sd() could lead to EAS not being enabled on boot when it should have been, because it requires all policies to be controlled by schedutil while they might not have been initialized yet. Fixes: e7a1b32e43b1 ("cpufreq: Rebuild sched-domains when removing cpufreq driver") Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/35e572d9-1152-406a-9e34-2525f7548af9@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e74dc7b74e048f8f39580f92b1b1c49b4a93adfc Author: Li Huafei <lihuafei1@huawei.com> Date: Thu Oct 31 19:27:55 2024 +0800 crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init() [ Upstream commit a10549fcce2913be7dc581562ffd8ea35653853e ] The commit 320406cb60b6 ("crypto: inside-secure - Replace generic aes with libaes") replaced crypto_alloc_cipher() with kmalloc(), but did not modify the handling of the return value. When kmalloc() returns NULL, PTR_ERR_OR_ZERO(NULL) returns 0, but in fact, the memory allocation has failed, and -ENOMEM should be returned. Fixes: 320406cb60b6 ("crypto: inside-secure - Replace generic aes with libaes") Signed-off-by: Li Huafei <lihuafei1@huawei.com> Acked-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5b75589d041e69e4c0432db72e9cde7df30bc793 Author: Wang Hai <wanghai38@huawei.com> Date: Tue Oct 29 23:05:23 2024 +0800 crypto: qat - Fix missing destroy_workqueue in adf_init_aer() [ Upstream commit d8920a722a8cec625267c09ed40af8fd433d7f9a ] The adf_init_aer() won't destroy device_reset_wq when alloc_workqueue() for device_sriov_wq failed. Add destroy_workqueue for device_reset_wq to fix this issue. Fixes: 4469f9b23468 ("crypto: qat - re-enable sriov after pf reset") Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e5c7052664b61f9e2f896702d20552707d0ef60a Author: Orange Kao <orange@aiven.io> Date: Mon Nov 4 12:40:52 2024 +0000 EDAC/igen6: Avoid segmentation fault on module unload [ Upstream commit fefaae90398d38a1100ccd73b46ab55ff4610fba ] The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219360 Signed-off-by: Orange Kao <orange@aiven.io> Signed-off-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20241104124237.124109-2-orange@aiven.io Signed-off-by: Sasha Levin <sashal@kernel.org> commit 37ea0b2707281db4bff1a92b6cb73eb3f50bdd70 Author: Weili Qian <qianweili@huawei.com> Date: Sat Oct 26 19:44:29 2024 +0800 crypto: hisilicon/qm - disable same error report before resetting [ Upstream commit c418ba6baca3ae10ffaf47b0803d2a9e6bf1af96 ] If an error indicating that the device needs to be reset is reported, disable the error reporting before device reset is complete, enable the error reporting after the reset is complete to prevent the same error from being reported repeatedly. Fixes: eaebf4c3b103 ("crypto: hisilicon - Unify hardware error init/uninit into QM") Signed-off-by: Weili Qian <qianweili@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 28f9ba491d0b35862a6c2d618bea8f5e2bb31cd3 Author: Gautham R. Shenoy <gautham.shenoy@amd.com> Date: Mon Oct 21 15:48:35 2024 +0530 amd-pstate: Set min_perf to nominal_perf for active mode performance gov [ Upstream commit 0c411b39e4f4ce8861301fa201cb4f817751311e ] The amd-pstate driver sets CPPC_REQ.min_perf to CPPC_REQ.max_perf when in active mode with performance governor. Typically CPPC_REQ.max_perf is set to CPPC.highest_perf. This causes frequency throttling on power-limited platforms which causes performance regressions on certain classes of workloads. Hence, set the CPPC_REQ.min_perf to the CPPC.nominal_perf or CPPC_REQ.max_perf, whichever is lower of the two. Fixes: ffa5096a7c33 ("cpufreq: amd-pstate: implement Pstate EPP support for the AMD processors") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20241021101836.9047-2-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5f03cadef84eb9503d4b74ff33d545f5db174162 Author: Mario Limonciello <mario.limonciello@amd.com> Date: Sat Oct 12 12:45:17 2024 -0500 cpufreq/amd-pstate: Don't update CPPC request in amd_pstate_cpu_boost_update() [ Upstream commit 67c08d303e0a1a5665b3f198037c9fae2d808090 ] When boost is changed the CPPC value is changed in amd_pstate_cpu_boost_update() but then changed again when refresh_frequency_limits() and all it's callbacks occur. The first is a pointless write, so instead just update the limits for the policy and let the policy refresh anchor everything properly. Fixes: c8c68c38b56f ("cpufreq: amd-pstate: initialize core precision boost state") Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Link: https://lore.kernel.org/r/20241012174519.897-2-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0f7fb0fefbe070d36863beb22e5b676431f8a392 Author: Everest K.C <everestkc@everestkc.com.np> Date: Fri Oct 18 10:23:10 2024 -0600 crypto: cavium - Fix the if condition to exit loop after timeout [ Upstream commit 53d91ca76b6c426c546542a44c78507b42008c9e ] The while loop breaks in the first run because of incorrect if condition. It also causes the statements after the if to appear dead. Fix this by changing the condition from if(timeout--) to if(!timeout--). This bug was reported by Coverity Scan. Report: CID 1600859: (#1 of 1): Logically dead code (DEADCODE) dead_error_line: Execution cannot reach this statement: udelay(30UL); Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine") Signed-off-by: Everest K.C. <everestkc@everestkc.com.np> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a8e0074ffb38c9a5964a221bb998034d016c93a2 Author: Yi Yang <yiyang13@huawei.com> Date: Tue Oct 15 02:09:35 2024 +0000 crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY [ Upstream commit 662f2f13e66d3883b9238b0b96b17886179e60e2 ] Since commit 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET"), the pcrypt encryption and decryption operations return -EAGAIN when the CPU goes online or offline. In alg_test(), a WARN is generated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns -EAGAIN, the unnecessary panic will occur when panic_on_warn set 1. Fix this issue by calling crypto layer directly without parallelization in that case. Fixes: 8f4f68e788c3 ("crypto: pcrypt - Fix hungtask for PADATA_RESET") Signed-off-by: Yi Yang <yiyang13@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1f1bbd0adc5bfea7b2c2db441aaf34a99e948638 Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Date: Tue Oct 15 15:22:36 2024 +0800 EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator [ Upstream commit a36667037a0c0e36c59407f8ae636295390239a5 ] The Granite Rapids CPUs with Flat2LM memory configurations may mistakenly report near-memory errors as far-memory errors, resulting in the invalid decoded ADXL results: EDAC skx: Bad imc -1 Fix this incorrect far-memory error source indicator by prefetching the decoded far-memory controller ID, and adjust the error source indicator to near-memory if the far-memory controller ID is invalid. Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support") Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Tested-by: Diego Garcia Rodriguez <diego.garcia.rodriguez@intel.com> Link: https://lore.kernel.org/r/20241015072236.24543-3-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit b6cd339c0322c87eb0ec1355c0e8630c7f099f6e Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Date: Tue Oct 15 15:22:35 2024 +0800 EDAC/skx_common: Differentiate memory error sources [ Upstream commit 2397f795735219caa9c2fe61e7bcdd0652e670d3 ] The current skx_common determines whether the memory error source is the near memory of the 2LM system and then retrieves the decoded error results from the ADXL components (near-memory vs. far-memory) accordingly. However, some memory controllers may have limitations in correctly reporting the memory error source, leading to the retrieval of incorrect decoded parts from the ADXL. To address these limitations, instead of simply determining whether the memory error is from the near memory of the 2LM system, it is necessary to distinguish the memory error source details as follows: Memory error from the near memory of the 2LM system. Memory error from the far memory of the 2LM system. Memory error from the 1LM system. Not a memory error. This will enable the i10nm_edac driver to take appropriate actions for those memory controllers that have limitations in reporting the memory error source. Fixes: ba987eaaabf9 ("EDAC/i10nm: Add Intel Granite Rapids server support") Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Tested-by: Diego Garcia Rodriguez <diego.garcia.rodriguez@intel.com> Link: https://lore.kernel.org/r/20241015072236.24543-2-qiuxu.zhuo@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit f4676ea4ce6aabf66beac054e22f1aa56d4883ec Author: Priyanka Singh <priyanka.singh@nxp.com> Date: Wed Oct 16 16:31:11 2024 -0400 EDAC/fsl_ddr: Fix bad bit shift operations [ Upstream commit 9ec22ac4fe766c6abba845290d5139a3fbe0153b ] Fix undefined behavior caused by left-shifting a negative value in the expression: cap_high ^ (1 << (bad_data_bit - 32)) The variable bad_data_bit ranges from 0 to 63. When it is less than 32, bad_data_bit - 32 becomes negative, and left-shifting by a negative value in C is undefined behavior. Fix this by combining cap_high and cap_low into a 64-bit variable. [ bp: Massage commit message, simplify error bits handling. ] Fixes: ea2eb9a8b620 ("EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx") Signed-off-by: Priyanka Singh <priyanka.singh@nxp.com> Signed-off-by: Li Yang <leoyang.li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20241016-imx95_edac-v3-3-86ae6fc2756a@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit ae0149db9f05ff3d30f34fd7705225f826bf0c46 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Oct 4 21:19:21 2024 +0200 thermal: core: Fix race between zone registration and system suspend [ Upstream commit cdf771ab476bd9acb0948f3088a277d5c3cacc6b ] If the registration of a thermal zone takes place at the time when system suspend is started, thermal_pm_notify() can run before the new thermal zone is added to thermal_tz_list and its "suspended" flag will not be set. Consequently, if __thermal_zone_device_update() is called for that thermal zone, it will not return early as expected which may cause some destructive interference with the system suspend or resume flow to occur. To avoid that, make thermal_zone_init_complete() introduced previously set the "suspended" flag for new thermal zones if it runs during system suspend or resume. Fixes: 4e814173a8c4 ("thermal: core: Fix thermal zone suspend-resume synchronization") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/8490245.NyiUUSuA9g@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d2d530d166c97f7cd23c3e8c0bc70ebe3dd681af Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Oct 4 21:15:04 2024 +0200 thermal: core: Mark thermal zones as initializing to start with [ Upstream commit 7837fa8115e0273d3cfbd3d17b3f7b7291ceac08 ] After thermal_zone_device_register_with_trips() has called device_register() and it has registered the new thermal zone device with the driver core, user space may access its sysfs attributes and, among other things, it may enable the thermal zone before it is ready. To address this, introduce a new thermal zone state flag for initialization and set it before calling device_register() in thermal_zone_device_register_with_trips(). This causes __thermal_zone_device_update() to return early until the new flag is cleared. To clear it when the thermal zone is ready, introduce a new function called thermal_zone_init_complete() that will also invoke __thermal_zone_device_update() after clearing that flag (both under the thernal zone lock) and make thermal_zone_device_register_with_trips() call the new function instead of checking need_update and calling thermal_zone_device_update() when it is set. After this change, if user space enables the thermal zone prematurely, __thermal_zone_device_update() will return early for it until thermal_zone_init_complete() is called. In turn, if the thermal zone is not enabled by user space before thermal_zone_init_complete() is called, the __thermal_zone_device_update() call in it will return early because the thermal zone has not been enabled yet, but that function will be invoked again by thermal_zone_device_set_mode() when the thermal zone is enabled and it will not return early this time. The checking of need_update is not necessary any more because the __thermal_zone_device_update() calls potentially triggered by cooling device binding take place before calling thermal_zone_init_complete(), so they all will return early, which means that thermal_zone_init_complete() must call __thermal_zone_device_update() in case the thermal zone is enabled prematurely by user space. Fixes: 203d3d4aa482 ("the generic thermal sysfs driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/9360231.CDJkKcVGEf@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6413640795e9ce359c7e43db8e97df94e1a9dbcb Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Oct 4 21:11:53 2024 +0200 thermal: core: Represent suspend-related thermal zone flags as bits [ Upstream commit 26c9ab8090cda1eb3d42f491cc32d227404897da ] Instead of using two separate fields in struct thermal_zone_device for representing flags related to thermal zone suspend, represent them explicitly as bits in one u8 "state" field. Subsequently, that field will be used for addressing race conditions related to thermal zone initialization and exit. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/7733910.EvYhyI6sBW@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Stable-dep-of: 7837fa8115e0 ("thermal: core: Mark thermal zones as initializing to start with") Signed-off-by: Sasha Levin <sashal@kernel.org> commit d7c6ffcce8297829dcd30718d1d74f089ab21d59 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Oct 4 21:09:23 2024 +0200 thermal: core: Rearrange PM notification code [ Upstream commit 7ddca5885718c2683d75689aa065c9a3bb317e5a ] Move the code run for each thermal zone by the thermal PM notify handler to separate functions. This will help to make some subsequent changes look somewhat more straightforward, among other things. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2299090.iZASKD2KPV@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Stable-dep-of: 7837fa8115e0 ("thermal: core: Mark thermal zones as initializing to start with") Signed-off-by: Sasha Levin <sashal@kernel.org> commit fbe004e6315c9bf4fd64f3e15ac58078d49d0906 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Mon Aug 26 18:37:16 2024 +0200 thermal: core: Drop thermal_zone_device_is_enabled() [ Upstream commit 54fccad63ec88924db828df6fc0648930bccf345 ] There are only two callers of thermal_zone_device_is_enabled() and one of them call is under the zone lock and the other one uses lockdep_assert_held() on that lock. Thus the lockdep_assert_held() in thermal_zone_device_is_enabled() is redundant and it could be dropped, but then the function would merely become a wrapper around a simple tz->mode check that is more convenient to do directly. Accordingly, drop thermal_zone_device_is_enabled() altogether and update its callers to check tz->mode directly as appropriate. While at it, combine the tz->mode and tz->suspended checks in __thermal_zone_device_update() because they are of a similar category and if any of them evaluates to "true", the outcome is the same. No intentinal functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/9353673.CDJkKcVGEf@rjwysocki.net Stable-dep-of: 7837fa8115e0 ("thermal: core: Mark thermal zones as initializing to start with") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7ad1382a4a80927784a630481f1c7aa0dc998f6f Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Fri Oct 4 21:05:49 2024 +0200 thermal: core: Initialize thermal zones before registering them [ Upstream commit 662f920f7e390db5d1a6792a2b0ffa59b6c962fc ] Since user space can start interacting with a new thermal zone as soon as device_register() called by thermal_zone_device_register_with_trips() returns, it is better to initialize the thermal zone before calling device_register() on it. Fixes: d0df264fbd3c ("thermal/core: Remove pointless thermal_zone_device_reset() function") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3336146.44csPzL39Z@rjwysocki.net Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f12d0dd1e9aa009ca632042b9ce16c5f6867baaf Author: Ahsan Atta <ahsan.atta@intel.com> Date: Mon Oct 7 14:42:40 2024 +0100 crypto: qat - remove faulty arbiter config reset [ Upstream commit 70199359902f1c7187dcb28a1be679a7081de7cc ] Resetting the service arbiter config can cause potential issues related to response ordering and ring flow control check in the event of AER or device hang. This is because it results in changing the default response ring size from 32 bytes to 16 bytes. The service arbiter config reset also disables response ring flow control check. Thus, by removing this reset we can prevent the service arbiter from being configured inappropriately, which leads to undesired device behaviour in the event of errors. Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Signed-off-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit fdb90006184aa84c7b4e09144ed0936d4e1891a7 Author: David Thompson <davthompson@nvidia.com> Date: Mon Sep 30 11:10:56 2024 -0400 EDAC/bluefield: Fix potential integer overflow [ Upstream commit 1fe774a93b46bb029b8f6fa9d1f25affa53f06c6 ] The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument. The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits. Fixes: 82413e562ea6 ("EDAC, mellanox: Add ECC support for BlueField DDR4") Signed-off-by: David Thompson <davthompson@nvidia.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Shravan Kumar Ramani <shravankr@nvidia.com> Link: https://lore.kernel.org/r/20240930151056.10158-1-davthompson@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit 60f0792a8b60d1f95cccd530acd2e9cbb122a585 Author: Yuan Can <yuancan@huawei.com> Date: Tue Oct 15 21:13:44 2024 +0800 firmware: google: Unregister driver_info on failure [ Upstream commit 32b0901e141f6d4cf49d820b53eb09b88b1f72f7 ] When platform_device_register_full() returns error, the gsmi_init() returns without unregister gsmi_driver_info, fix by add missing platform_driver_unregister() when platform_device_register_full() failed. Fixes: 8942b2d5094b ("gsmi: Add GSMI commands to log S0ix info") Signed-off-by: Yuan Can <yuancan@huawei.com> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20241015131344.20272-1-yuancan@huawei.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e69d2845aaa080960f38761f78fd25aa856620c6 Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Sat Sep 28 13:05:08 2024 +0300 crypto: qat/qat_4xxx - fix off by one in uof_get_name() [ Upstream commit 475b5098043eef6e72751aadeab687992a5b63d1 ] The fw_objs[] array has "num_objs" elements so the > needs to be >= to prevent an out of bounds read. Fixes: 10484c647af6 ("crypto: qat - refactor fw config logic for 4xxx") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c23661a36eea840b657e485d48ed88b246da1bb8 Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Sat Sep 28 13:05:01 2024 +0300 crypto: qat/qat_420xx - fix off by one in uof_get_name() [ Upstream commit 93a11608fb3720e1bc2b19a2649ac2b49cca1921 ] This is called from uof_get_name_420xx() where "num_objs" is the ARRAY_SIZE() of fw_objs[]. The > needs to be >= to prevent an out of bounds access. Fixes: fcf60f4bcf54 ("crypto: qat - add support for 420xx devices") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f7af88c3a95022ca2f8ed48a378402cdcea871d2 Author: Cabiddu, Giovanni <giovanni.cabiddu@intel.com> Date: Mon Sep 16 10:42:51 2024 +0100 crypto: qat - remove check after debugfs_create_dir() [ Upstream commit 23717055a79981daf7fafa09a4b0d7566f8384aa ] The debugfs functions are guaranteed to return a valid error code instead of NULL upon failure. Consequently, the driver can directly propagate any error returned without additional checks. Remove the unnecessary `if` statement after debugfs_create_dir(). If this function fails, the error code is stored in accel_dev->debugfs_dir and utilized in subsequent debugfs calls. Additionally, since accel_dev->debugfs_dir is assured to be non-NULL, remove the superfluous NULL pointer checks within the adf_dbgfs_add() and adf_dbgfs_rm(). Fixes: 9260db6640a6 ("crypto: qat - move dbgfs init to separate file") Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 84a185aea7b83f620699de0ea36907d588d89cf6 Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Date: Sun Sep 15 12:22:12 2024 +0200 crypto: caam - Fix the pointer passed to caam_qi_shutdown() [ Upstream commit ad980b04f51f7fb503530bd1cb328ba5e75a250e ] The type of the last parameter given to devm_add_action_or_reset() is "struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to "struct device *". Pass the correct parameter to devm_add_action_or_reset() so that the resources are released as expected. Fixes: f414de2e2fff ("crypto: caam - use devres to de-initialize QI") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 88e6ac37b0d8034dbcd823d901aef2de0b9f2438 Author: Tomas Paukrt <tomaspaukrt@email.cz> Date: Fri Sep 13 11:11:43 2024 +0200 crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys [ Upstream commit 0dbb6854ca14933e194e8e46c894ca7bff95d0f3 ] Fix passing an initialization vector in the payload field which is necessary for AES in CBC mode even with hardware-bound keys. Fixes: 3d16af0b4cfa ("crypto: mxs-dcp: Add support for hardware-bound keys") Signed-off-by: Tomas Paukrt <tomaspaukrt@email.cz> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bcbd1b2efe0589e7387cdd17b983bc85f5ca54e4 Author: Christoph Hellwig <hch@lst.de> Date: Wed Nov 13 16:20:42 2024 +0100 virtio_blk: reverse request order in virtio_queue_rqs [ Upstream commit 7f212e997edbb7a2cb85cef2ac14265dfaf88717 ] blk_mq_flush_plug_list submits requests in the reverse order that they were submitted, which leads to a rather suboptimal I/O pattern especially in rotational devices. Fix this by rewriting virtio_queue_rqs so that it always pops the requests from the passed in request list, and then adds them to the head of a local submit list. This actually simplifies the code a bit as it removes the complicated list splicing, at the cost of extra updates of the rq_next pointer. As that should be cache hot anyway it should be an easy price to pay. Fixes: 0e9911fa768f ("virtio-blk: support mq_ops->queue_rqs()") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20241113152050.157179-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0595c647d45f6599e7e9cc63df8361e7f6bf59a0 Author: Christoph Hellwig <hch@lst.de> Date: Wed Nov 13 16:20:41 2024 +0100 nvme-pci: reverse request order in nvme_queue_rqs [ Upstream commit beadf0088501d9dcf2454b05d90d5d31ea3ba55f ] blk_mq_flush_plug_list submits requests in the reverse order that they were submitted, which leads to a rather suboptimal I/O pattern especially in rotational devices. Fix this by rewriting nvme_queue_rqs so that it always pops the requests from the passed in request list, and then adds them to the head of a local submit list. This actually simplifies the code a bit as it removes the complicated list splicing, at the cost of extra updates of the rq_next pointer. As that should be cache hot anyway it should be an easy price to pay. Fixes: d62cbcf62f2f ("nvme: add support for mq_ops->queue_rqs()") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20241113152050.157179-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 25a5acf88fed59e060405bbb48098f4a3a2c2adc Author: Long Li <leo.lilong@huawei.com> Date: Fri Sep 6 17:17:46 2024 +0800 ext4: fix race in buffer_head read fault injection [ Upstream commit 2f3d93e210b9c2866c8b3662adae427d5bf511ec ] When I enabled ext4 debug for fault injection testing, I encountered the following warning: EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress: Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051 WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0 The root cause of the issue lies in the improper implementation of ext4's buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions. [CPU0] [CPU1] [CPU2] ext4_read_inode_bitmap ext4_read_bh() <bh read complete> ext4_read_inode_bitmap if (buffer_uptodate(bh)) return bh jbd2_journal_commit_transaction __jbd2_journal_refile_buffer __jbd2_journal_unfile_buffer __jbd2_journal_temp_unlink_buffer ext4_simulate_fail_bh() clear_buffer_uptodate mark_buffer_dirty <report warning> WARN_ON_ONCE(!buffer_uptodate(bh)) The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb. Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection. Fixes: 46f870d690fe ("ext4: simulate various I/O and checksum errors when reading metadata") Signed-off-by: Long Li <leo.lilong@huawei.com> Link: https://patch.msgid.link/20240906091746.510163-1-leo.lilong@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> commit eaa3782d8988575bde720abd5ecc4f10688f287b Author: Matthew Wilcox (Oracle) <willy@infradead.org> Date: Thu Jul 18 23:30:01 2024 +0100 ext4: remove array of buffer_heads from mext_page_mkuptodate() [ Upstream commit a40759fb16ae839f8c769174fde017564ea564ff ] Iterate the folio's list of buffer_heads twice instead of keeping an array of pointers. This solves a too-large-array-for-stack problem on architectures with a ridiculoously large PAGE_SIZE and prepares ext4 to support larger folios. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20240718223005.568869-3-willy@infradead.org Signed-off-by: Theodore Ts'o <tytso@mit.edu> Stable-dep-of: 2f3d93e210b9 ("ext4: fix race in buffer_head read fault injection") Signed-off-by: Sasha Levin <sashal@kernel.org> commit e1a181376eecba5deb28f8ce6de7440dfb3b41ee Author: Matthew Wilcox (Oracle) <willy@infradead.org> Date: Thu Jul 18 23:30:00 2024 +0100 ext4: pipeline buffer reads in mext_page_mkuptodate() [ Upstream commit 368a83cebbb949adbcc20877c35367178497d9cc ] Instead of synchronously reading one buffer at a time, submit reads as we walk the buffers in the first loop, then wait for them in the second loop. This should be significantly more efficient, particularly on HDDs, but I have not measured. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://patch.msgid.link/20240718223005.568869-2-willy@infradead.org Signed-off-by: Theodore Ts'o <tytso@mit.edu> Stable-dep-of: 2f3d93e210b9 ("ext4: fix race in buffer_head read fault injection") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2667c9b7b76efcbc7adbfea249892f20c313b0da Author: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Date: Thu Nov 7 08:41:09 2024 -0300 hfsplus: don't query the device logical block size multiple times [ Upstream commit 1c82587cb57687de3f18ab4b98a8850c789bedcf ] Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.951830] print_report+0x14c/0x49e [ 419.952361] ? __virt_addr_valid+0x267/0x278 [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? sb_set_blocksize+0x6d/0xae [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] legacy_get_tree+0x104/0x178 [ 419.968414] vfs_get_tree+0x86/0x296 [ 419.968751] path_mount+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] do_mount+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: 00007ffe306325d0 [ 419.976363] RBP: 00007ffe30632720 R08: 00007ffe30632610 R09: 0000000000000000 [ 419.977034] R10: 0000000000200008 R11: 0000000000000286 R12: 0000000000000000 [ 419.977713] R13: 00007ffe306328e8 R14: 00005a0eb298bc68 R15: 00007c3cb8356000 [ 419.978375] </TASK> [ 419.978589] Fixes: 6596528e391a ("hfsplus: ensure bio requests are not smaller than the hardware sectors") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Link: https://lore.kernel.org/r/20241107114109.839253-1-cascardo@igalia.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8010207e9eaf31d5b3a861ac33df6866fba4643c Author: Masahiro Yamada <masahiroy@kernel.org> Date: Mon Nov 11 22:45:52 2024 +0900 s390/syscalls: Avoid creation of arch/arch/ directory [ Upstream commit 0708967e2d56e370231fd07defa0d69f9ad125e8 ] Building the kernel with ARCH=s390 creates a weird arch/arch/ directory. $ find arch/arch arch/arch arch/arch/s390 arch/arch/s390/include arch/arch/s390/include/generated arch/arch/s390/include/generated/asm arch/arch/s390/include/generated/uapi arch/arch/s390/include/generated/uapi/asm The root cause is 'targets' in arch/s390/kernel/syscalls/Makefile, where the relative path is incorrect. Strictly speaking, 'targets' was not necessary in the first place because this Makefile uses 'filechk' instead of 'if_changed'. However, this commit keeps it, as it will be useful when converting 'filechk' to 'if_changed' later. Fixes: 5c75824d915e ("s390/syscalls: add Makefile to generate system call header files") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20241111134603.2063226-1-masahiroy@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 647e2255fdd509ffd80d726751c12097745b085e Author: Christoph Hellwig <hch@lst.de> Date: Mon Nov 4 07:26:30 2024 +0100 block: fix bio_split_rw_at to take zone_write_granularity into account [ Upstream commit 7ecd2cd4fae3e8410c0a6620f3a83dcdbb254f02 ] Otherwise it can create unaligned writes on zoned devices. Fixes: a805a4fa4fa3 ("block: introduce zone_write_granularity limit") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20241104062647.91160-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bd88dfd6a0d64574770d1f50a0b7c1d375adde47 Author: Christoph Hellwig <hch@lst.de> Date: Mon Nov 4 07:26:29 2024 +0100 block: take chunk_sectors into account in bio_split_write_zeroes [ Upstream commit 60dc5ea6bcfd078b71419640d49afa649acf9450 ] For zoned devices, write zeroes must be split at the zone boundary which is represented as chunk_sectors. For other uses like the internally RAIDed NVMe devices it is probably at least useful. Enhance get_max_io_size to know about write zeroes and use it in bio_split_write_zeroes. Also add a comment about the seemingly nonsensical zero max_write_zeroes limit. Fixes: 885fa13f6559 ("block: implement splitting of REQ_OP_WRITE_ZEROES bios") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20241104062647.91160-2-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bf937fce96a353c68887adce75963233718fffa9 Author: Christoph Hellwig <hch@lst.de> Date: Mon Aug 26 19:37:56 2024 +0200 block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits [ Upstream commit 1e8a7f6af926e266cc1d7ac49b56bd064057d625 ] Currently REQ_OP_ZONE_APPEND is handled by the bio_split_rw case in __bio_split_to_limits. This is harmful because REQ_OP_ZONE_APPEND bios do not adhere to the soft max_limits value but instead use their own capped version of max_hw_sectors, leading to incorrect splits that later blow up in bio_split. We still need the bio_split_rw logic to count nr_segs for blk-mq code, so add a new wrapper that passes in the right limit, and turns any bio that would need a split into an error as an additional debugging aid. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Tested-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Link: https://lore.kernel.org/r/20240826173820.1690925-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Stable-dep-of: 60dc5ea6bcfd ("block: take chunk_sectors into account in bio_split_write_zeroes") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 829de6594c78c684914928f98a0f31ab2ddcbab8 Author: Christoph Hellwig <hch@lst.de> Date: Mon Aug 26 19:37:55 2024 +0200 block: constify the lim argument to queue_limits_max_zone_append_sectors [ Upstream commit 379b122a3ec8033aa43cb70e8ecb6fb7f98aa68f ] queue_limits_max_zone_append_sectors doesn't change the lim argument, so mark it as const. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Tested-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Link: https://lore.kernel.org/r/20240826173820.1690925-3-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8beb682cc9a0798a280bbb95e3e41617237090b2 Author: Zizhi Wo <wozizhi@huawei.com> Date: Thu Nov 7 19:06:49 2024 +0800 netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING [ Upstream commit 22f9400a6f3560629478e0a64247b8fcc811a24d ] In fscache_create_volume(), there is a missing memory barrier between the bit-clearing operation and the wake-up operation. This may cause a situation where, after a wake-up, the bit-clearing operation hasn't been detected yet, leading to an indefinite wait. The triggering process is as follows: [cookie1] [cookie2] [volume_work] fscache_perform_lookup fscache_create_volume fscache_perform_lookup fscache_create_volume fscache_create_volume_work cachefiles_acquire_volume clear_and_wake_up_bit test_and_set_bit test_and_set_bit goto maybe_wait goto no_wait In the above process, cookie1 and cookie2 has the same volume. When cookie1 enters the -no_wait- process, it will clear the bit and wake up the waiting process. If a barrier is missing, it may cause cookie2 to remain in the -wait- process indefinitely. In commit 3288666c7256 ("fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work()"), barriers were added to similar operations in fscache_create_volume_work(), but fscache_create_volume() was missed. By combining the clear and wake operations into clear_and_wake_up_bit() to fix this issue. Fixes: bfa22da3ed65 ("fscache: Provide and use cache methods to lookup/create/free a volume") Signed-off-by: Zizhi Wo <wozizhi@huawei.com> Link: https://lore.kernel.org/r/20241107110649.3980193-6-wozizhi@huawei.com Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f98770440c9bc468e2fd878212ec9526dbe08293 Author: Zizhi Wo <wozizhi@huawei.com> Date: Thu Nov 7 19:06:48 2024 +0800 cachefiles: Fix NULL pointer dereference in object->file [ Upstream commit 31ad74b20227ce6b40910ff78b1c604e42975cf1 ] At present, the object->file has the NULL pointer dereference problem in ondemand-mode. The root cause is that the allocated fd and object->file lifetime are inconsistent, and the user-space invocation to anon_fd uses object->file. Following is the process that triggers the issue: [write fd] [umount] cachefiles_ondemand_fd_write_iter fscache_cookie_state_machine cachefiles_withdraw_cookie if (!file) return -ENOBUFS cachefiles_clean_up_object cachefiles_unmark_inode_in_use fput(object->file) object->file = NULL // file NULL pointer dereference! __cachefiles_write(..., file, ...) Fix this issue by add an additional reference count to the object->file before write/llseek, and decrement after it finished. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo <wozizhi@huawei.com> Link: https://lore.kernel.org/r/20241107110649.3980193-5-wozizhi@huawei.com Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2eaafb379eefd5e2c067342d29237c3cbea93893 Author: Zizhi Wo <wozizhi@huawei.com> Date: Thu Nov 7 19:06:46 2024 +0800 cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter() [ Upstream commit 56f4856b425a30e1d8b3e41e6cde8bfba90ba5f8 ] In the erofs on-demand loading scenario, read and write operations are usually delivered through "off" and "len" contained in read req in user mode. Naturally, pwrite is used to specify a specific offset to complete write operations. However, if the write(not pwrite) syscall is called multiple times in the read-ahead scenario, we need to manually update ki_pos after each write operation to update file->f_pos. This step is currently missing from the cachefiles_ondemand_fd_write_iter function, added to address this issue. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo <wozizhi@huawei.com> Link: https://lore.kernel.org/r/20241107110649.3980193-3-wozizhi@huawei.com Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a273892284546d5ae2ad41731ba04428cc473417 Author: Zizhi Wo <wozizhi@huawei.com> Date: Thu Nov 7 19:06:45 2024 +0800 cachefiles: Fix incorrect length return value in cachefiles_ondemand_fd_write_iter() [ Upstream commit 10c35abd35aa62c9aac56898ae0c63b4d7d115e5 ] cachefiles_ondemand_fd_write_iter() function first aligns "pos" and "len" to block boundaries. When calling __cachefiles_write(), the aligned "pos" is passed in, but "len" is the original unaligned value(iter->count). Additionally, the returned length of the write operation is the modified "len" aligned by block size, which is unreasonable. The alignment of "pos" and "len" is intended only to check whether the cache has enough space. But the modified len should not be used as the return value of cachefiles_ondemand_fd_write_iter() because the length we passed to __cachefiles_write() is the previous "len". Doing so would result in a mismatch in the data written on-demand. For example, if the length of the user state passed in is not aligned to the block size (the preread scene/DIO writes only need 512 alignment/Fault injection), the length of the write will differ from the actual length of the return. To solve this issue, since the __cachefiles_prepare_write() modifies the size of "len", we pass "aligned_len" to __cachefiles_prepare_write() to calculate the free blocks and use the original "len" as the return value of cachefiles_ondemand_fd_write_iter(). Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Zizhi Wo <wozizhi@huawei.com> Link: https://lore.kernel.org/r/20241107110649.3980193-2-wozizhi@huawei.com Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 81d8d44004e0d747949ec2a33fd5abae90df8942 Author: Li Wang <liwang@redhat.com> Date: Sat Nov 9 10:27:44 2024 +0800 loop: fix type of block size [ Upstream commit 8e604cac499248c75ad3a26695a743ff879ded5c ] PAGE_SIZE may be 64K, and the max block size can be PAGE_SIZE, so any variable for holding block size can't be defined as 'unsigned short'. Unfortunately commit 473516b36193 ("loop: use the atomic queue limits update API") passes 'bsize' with type of 'unsigned short' to loop_reconfigure_limits(), and causes LTP/ioctl_loop06 test failure: 12 ioctl_loop06.c:76: TINFO: Using LOOP_SET_BLOCK_SIZE with arg > PAGE_SIZE 13 ioctl_loop06.c:59: TFAIL: Set block size succeed unexpectedly ... 18 ioctl_loop06.c:76: TINFO: Using LOOP_CONFIGURE with block_size > PAGE_SIZE 19 ioctl_loop06.c:59: TFAIL: Set block size succeed unexpectedly Fixes the issue by defining 'block size' variable with 'unsigned int', which is aligned with block layer's definition. (improve commit log & add fixes tag) Fixes: 473516b36193 ("loop: use the atomic queue limits update API") Cc: John Garry <john.g.garry@oracle.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Li Wang <liwang@redhat.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/r/20241109022744.1126003-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 48410a1b9be7ce5f90f3275cecebcd1bc4ef815b Author: Aleksandr Mishin <amishin@t-argos.ru> Date: Tue Aug 27 13:12:39 2024 +0300 acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block() [ Upstream commit 1a9de2f6fda69d5f105dd8af776856a66abdaa64 ] In case of error in gtdt_parse_timer_block() invalid 'gtdt_frame' will be used in 'do {} while (i-- >= 0 && gtdt_frame--);' statement block because do{} block will be executed even if 'i == 0'. Adjust error handling procedure by replacing 'i-- >= 0' with 'i-- > 0'. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Acked-by: Hanjun Guo <guohanjun@huawei.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Aleksandr Mishin <amishin@t-argos.ru> Link: https://lore.kernel.org/r/20240827101239.22020-1-amishin@t-argos.ru Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 55efab5cd8cec81743912d217ebcba8f12a51e45 Author: Masahiro Yamada <masahiroy@kernel.org> Date: Thu Nov 7 01:18:42 2024 +0900 arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG [ Upstream commit 340fd66c856651d8c1d29f392dd26ad674d2db0e ] Commit be2881824ae9 ("arm64/build: Assert for unwanted sections") introduced an assertion to ensure that the .data.rel.ro section does not exist. However, this check does not work when CONFIG_LTO_CLANG is enabled, because .data.rel.ro matches the .data.[0-9a-zA-Z_]* pattern in the DATA_MAIN macro. Move the ASSERT() above the RW_DATA() line. Fixes: be2881824ae9 ("arm64/build: Assert for unwanted sections") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20241106161843.189927-1-masahiroy@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 24803c588e61635bebcad7f848b7e108c405dc9e Author: Daniel Palmer <daniel@0x0f.com> Date: Wed Nov 6 10:51:24 2024 +1100 m68k: mvme147: Reinstate early console [ Upstream commit 077b33b9e2833ff25050d986178a2c4c4036cbac ] Commit a38eaa07a0ce ("m68k/mvme147: config.c - Remove unused functions"), removed the console functionality for the mvme147 instead of wiring it up to an early console. Put the console write function back and wire it up like mvme16x does so it's possible to see Linux boot on this fine hardware once more. Fixes: a38eaa07a0ce ("m68k/mvme147: config.c - Remove unused functions") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Co-developed-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/a82e8f0068a8722996a0ccfe666abb5e0a5c120d.1730850684.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit fa7cc668e3e6c6cf0fdd28d54bac68ae5b0c3e08 Author: Daniel Palmer <daniel@0x0f.com> Date: Thu Oct 3 13:29:47 2024 +1000 m68k: mvme147: Fix SCSI controller IRQ numbers [ Upstream commit 47bc874427382018fa2e3e982480e156271eee70 ] Sometime long ago the m68k IRQ code was refactored and the interrupt numbers for SCSI controller on this board ended up wrong, and it hasn't worked since. The PCC adds 0x40 to the vector for its interrupts so they end up in the user interrupt range. Hence, the kernel number should be the kernel offset for user interrupt range + the PCC interrupt number. Fixes: 200a3d352cd5 ("[PATCH] m68k: convert VME irq code") Signed-off-by: Daniel Palmer <daniel@0x0f.com> Reviewed-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/0e7636a21a0274eea35bfd5d874459d5078e97cc.1727926187.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6d0f599db73b099aa724a12736369c4d4d92849d Author: Christoph Hellwig <hch@lst.de> Date: Fri Nov 1 05:40:04 2024 +0100 nvme-pci: fix freeing of the HMB descriptor table [ Upstream commit 3c2fb1ca8086eb139b2a551358137525ae8e0d7a ] The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. Fixes: 87ad72a59a38 ("nvme-pci: implement host memory buffer support") Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 70df8758130ec59c9f75629ebf15bee24c81106c Author: Mark Brown <broonie@kernel.org> Date: Mon Oct 28 20:22:31 2024 +0000 kselftest/arm64: Fix encoding for SVE B16B16 test [ Upstream commit 69c0d824779843b51ca2339b2163db4d3b40c54c ] The test for SVE_B16B16 had a cut'n'paste of a SME instruction, fix it with a relevant SVE instruction. Fixes: 44d10c27bd75 ("kselftest/arm64: Add 2023 DPISA hwcap test coverage") Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241028-arm64-b16b16-test-v1-1-59a4a7449bdf@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit bec5dc18d0ea3dfb86f52ae670e17b5c0d308814 Author: Marc Zyngier <maz@kernel.org> Date: Thu Oct 31 08:35:19 2024 +0000 arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers [ Upstream commit 2287a4c1e11822d05a70d22f28b26bd810dd204e ] Despite KVM now being able to deal with XS-tagged TLBIs, we still don't expose these feature bits to KVM. Plumb in the feature in ID_AA64ISAR1_EL1. Fixes: 0feec7769a63 ("KVM: arm64: nv: Add handling of NXS-flavoured TLBI operations") Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241031083519.364313-1-maz@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 49d01e736c3045319e030d1e75fb983011abaca7 Author: David Disseldorp <ddiss@suse.de> Date: Wed Oct 30 03:55:10 2024 +0000 initramfs: avoid filename buffer overrun [ Upstream commit e017671f534dd3f568db9e47b0583e853d2da9b5 ] The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2") Signed-off-by: David Disseldorp <ddiss@suse.de> Link: https://lore.kernel.org/r/20241030035509.20194-2-ddiss@suse.de Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 916d8c0b579f6e78d568b7c8a83ca761de45b11a Author: Jonas Gorski <jonas.gorski@gmail.com> Date: Sat Oct 12 12:12:14 2024 +0200 mips: asm: fix warning when disabling MIPS_FP_SUPPORT [ Upstream commit da09935975c8f8c90d6f57be2422dee5557206cd ] When MIPS_FP_SUPPORT is disabled, __sanitize_fcr31() is defined as nothing, which triggers a gcc warning: In file included from kernel/sched/core.c:79: kernel/sched/core.c: In function 'context_switch': ./arch/mips/include/asm/switch_to.h:114:39: warning: suggest braces around empty body in an 'if' statement [-Wempty-body] 114 | __sanitize_fcr31(next); \ | ^ kernel/sched/core.c:5316:9: note: in expansion of macro 'switch_to' 5316 | switch_to(prev, next, prev); | ^~~~~~~~~ Fix this by providing an empty body for __sanitize_fcr31() like one is defined for __mips_mt_fpaff_switch_to(). Fixes: 36a498035bd2 ("MIPS: Avoid FCSR sanitization when CONFIG_MIPS_FP_SUPPORT=n") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0584d461942b1a2cbfa86ba102afad5125f19523 Author: Jan Kara <jack@suse.cz> Date: Sat Oct 5 00:15:56 2024 +0200 ext4: avoid remount errors with 'abort' mount option [ Upstream commit 76486b104168ae59703190566e372badf433314b ] When we remount filesystem with 'abort' mount option while changing other mount options as well (as is LTP test doing), we can return error from the system call after commit d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") because the application of mount option changes detects shutdown filesystem and refuses to do anything. The behavior of application of other mount options in presence of 'abort' mount option is currently rather arbitary as some mount option changes are handled before 'abort' and some after it. Move aborting of the filesystem to the end of remount handling so all requested changes are properly applied before the filesystem is shutdown to have a reasonably consistent behavior. Fixes: d3476f3dad4a ("ext4: don't set SB_RDONLY after filesystem errors") Reported-by: Jan Stancek <jstancek@redhat.com> Link: https://lore.kernel.org/all/Zvp6L+oFnfASaoHl@t14s Signed-off-by: Jan Kara <jack@suse.cz> Tested-by: Jan Stancek <jstancek@redhat.com> Link: https://patch.msgid.link/20241004221556.19222-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c0c2744cd2939ec5999c51dbaf2af16886548b7b Author: Yang Erkun <yangerkun@huawei.com> Date: Wed Oct 30 11:49:14 2024 +0800 brd: defer automatic disk creation until module initialization succeeds [ Upstream commit 826cc42adf44930a633d11a5993676d85ddb0842 ] My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list. Fixes: 7f9b348cb5e9 ("brd: convert to blk_alloc_disk/blk_cleanup_disk") Reported-by: Wupeng Ma <mawupeng1@huawei.com> Signed-off-by: Yang Erkun <yangerkun@huawei.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20241030034914.907829-1-yangerkun@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4b876507d4fc8e146acf86f898af1784558d5f46 Author: Ard Biesheuvel <ardb@kernel.org> Date: Wed Oct 9 18:04:40 2024 +0200 x86/pvh: Call C code via the kernel virtual mapping [ Upstream commit e8fbc0d9cab6c1ee6403f42c0991b0c1d5dbc092 ] Calling C code via a different mapping than it was linked at is problematic, because the compiler assumes that RIP-relative and absolute symbol references are interchangeable. GCC in particular may use RIP-relative per-CPU variable references even when not using -fpic. So call xen_prepare_pvh() via its kernel virtual mapping on x86_64, so that those RIP-relative references produce the correct values. This matches the pre-existing behavior for i386, which also invokes xen_prepare_pvh() via the kernel virtual mapping before invoking startup_32 with paging disabled again. Fixes: 7243b93345f7 ("xen/pvh: Bootstrap PVH guest") Tested-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Jason Andryuk <jason.andryuk@amd.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Message-ID: <20241009160438.3884381-8-ardb+git@google.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 95ea325742dcac40fc5baa7275d6d801fc58ea1e Author: Jason Andryuk <jason.andryuk@amd.com> Date: Fri Aug 23 15:36:28 2024 -0400 x86/pvh: Set phys_base when calling xen_prepare_pvh() [ Upstream commit b464b461d27d564125db760938643374864c1b1f ] phys_base needs to be set for __pa() to work in xen_pvh_init() when finding the hypercall page. Set it before calling into xen_prepare_pvh(), which calls xen_pvh_init(). Clear it afterward to avoid __startup_64() adding to it and creating an incorrect value. Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Juergen Gross <jgross@suse.com> Message-ID: <20240823193630.2583107-4-jason.andryuk@amd.com> Signed-off-by: Juergen Gross <jgross@suse.com> Stable-dep-of: e8fbc0d9cab6 ("x86/pvh: Call C code via the kernel virtual mapping") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 390931bd7c612fecb1b171799be8cd1e84284056 Author: Heiko Carstens <hca@linux.ibm.com> Date: Fri Oct 18 14:26:23 2024 +0200 s390/pageattr: Implement missing kernel_page_present() [ Upstream commit 2835f8bf5530750c3381166005934f996a83ad05 ] kernel_page_present() was intentionally not implemented when adding ARCH_HAS_SET_DIRECT_MAP support, since it was only used for suspend/resume which is not supported anymore on s390. A new bpf use case led to a compile error specific to s390. Even though this specific use case went away implement kernel_page_present(), so that the API is complete and potential future users won't run into this problem. Reported-by: Daniel Borkmann <daniel@iogearbox.net> Closes: https://lore.kernel.org/all/045de961-ac69-40cc-b141-ab70ec9377ec@iogearbox.net Fixes: 0490d6d7ba0a ("s390/mm: enable ARCH_HAS_SET_DIRECT_MAP") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 6c268349724952b105a01245d0490bc02856b081 Author: Vineeth Vijayan <vneethv@linux.ibm.com> Date: Mon Sep 23 22:16:43 2024 +0200 s390/cio: Do not unregister the subchannel based on DNV [ Upstream commit 8c58a229688ce3a097b3b1a2efe1b4f5508c2123 ] Starting with commit 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers"), CIO does not unregister subchannels when the attached device is invalid or unavailable. Instead, it allows subchannels to exist without a connected device. However, if the DNV value is 0, such as, when all the CHPIDs of a subchannel are configured in standby state, the subchannel is unregistered, which contradicts the current subchannel specification. Update the logic so that subchannels are not unregistered based on the DNV value. Also update the SCHIB information even if the DNV bit is zero. Suggested-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers") Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5d40406f9a695008f1613ce5edb24e36a1143f04 Author: John Garry <john.g.garry@oracle.com> Date: Sat Oct 19 12:51:07 2024 +0000 fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid() [ Upstream commit c3be7ebbbce5201e151f17e28a6c807602f369c9 ] Currently FMODE_CAN_ATOMIC_WRITE is set if the bdev can atomic write and the file is open for direct IO. This does not work if the file is not opened for direct IO, yet fcntl(O_DIRECT) is used on the fd later. Change to check for direct IO on a per-IO basis in generic_atomic_write_valid(). Since we want to report -EOPNOTSUPP for non-direct IO for an atomic write, change to return an error code. Relocate the block fops atomic write checks to the common write path, as to catch non-direct IO. Fixes: c34fc6f26ab8 ("fs: Initial atomic write support") Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/r/20241019125113.369994-3-john.g.garry@oracle.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 80cca37bd6c4da685873120a3bd5c3cfa60c2525 Author: John Garry <john.g.garry@oracle.com> Date: Sat Oct 19 12:51:06 2024 +0000 block/fs: Pass an iocb to generic_atomic_write_valid() [ Upstream commit 9a8dbdadae509e5717ff6e5aa572ca0974d2101d ] Darrick and Hannes both thought it better that generic_atomic_write_valid() should be passed a struct iocb, and not just the member of that struct which is referenced; see [0] and [1]. I think that makes a more generic and clean API, so make that change. [0] https://lore.kernel.org/linux-block/680ce641-729b-4150-b875-531a98657682@suse.de/ [1] https://lore.kernel.org/linux-xfs/20240620212401.GA3058325@frogsfrogsfrogs/ Fixes: c34fc6f26ab8 ("fs: Initial atomic write support") Suggested-by: Darrick J. Wong <djwong@kernel.org> Suggested-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/r/20241019125113.369994-2-john.g.garry@oracle.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4fbdc1e517c7a696520b057fbe663adbe8a11edc Author: Andre Przywara <andre.przywara@arm.com> Date: Fri Aug 16 16:32:51 2024 +0100 kselftest/arm64: mte: fix printf type warnings about longs [ Upstream commit 96dddb7b9406259baace9a1831e8da155311be6f ] When checking MTE tags, we print some diagnostic messages when the tests fail. Some variables uses there are "longs", however we only use "%x" for the format specifier. Update the format specifiers to "%lx", to match the variable types they are supposed to print. Fixes: f3b2a26ca78d ("kselftest/arm64: Verify mte tag inclusion via prctl") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240816153251.2833702-9-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4bf52e627bc9feb65124d31dd45084d62cfe0a93 Author: Andre Przywara <andre.przywara@arm.com> Date: Fri Aug 16 16:32:49 2024 +0100 kselftest/arm64: mte: fix printf type warnings about __u64 [ Upstream commit 7e893dc81de3e342156389ea0b83ec7d07f25281 ] When printing the signal context's PC, we use a "%lx" format specifier, which matches the common userland (glibc's) definition of uint64_t as an "unsigned long". However the structure in question is defined in a kernel uapi header, which uses a self defined __u64 type, and the arm64 kernel headers define this using "int-ll64.h", so it becomes an "unsigned long long". This mismatch leads to the usual compiler warning. The common fix would be to use "PRIx64", but because this is defined by the userland's toolchain libc headers, it wouldn't match as well. Since we know the exact type of __u64, just use "%llx" here instead, to silence this warning. This also fixes a more severe typo: "$lx" is not a valid format specifier. Fixes: 191e678bdc9b ("kselftest/arm64: Log unexpected asynchronous MTE faults") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240816153251.2833702-7-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 4c594e815cb5675b5b590e17acf29c3ad33cb1ec Author: Andre Przywara <andre.przywara@arm.com> Date: Fri Aug 16 16:32:45 2024 +0100 kselftest/arm64: hwcap: fix f8dp2 cpuinfo name [ Upstream commit b0d80dbc378d52155c9ecf9579986edccceed3aa ] The F8DP2 DPISA extension has a separate cpuinfo field, named accordingly. Change the erroneously placed name of "f8dp4" to "f8dp2". Fixes: 44d10c27bd75 ("kselftest/arm64: Add 2023 DPISA hwcap test coverage") Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20240816153251.2833702-3-andre.przywara@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 428b40d4d0e1ca130d1176f18081b894c9646af6 Author: Kristina Martsenko <kristina.martsenko@arm.com> Date: Mon Sep 30 17:10:47 2024 +0100 arm64: probes: Disable kprobes/uprobes on MOPS instructions [ Upstream commit c56c599d9002d44f559be3852b371db46adac87c ] FEAT_MOPS instructions require that all three instructions (prologue, main and epilogue) appear consecutively in memory. Placing a kprobe/uprobe on one of them doesn't work as only a single instruction gets executed out-of-line or simulated. So don't allow placing a probe on a MOPS instruction. Fixes: b7564127ffcb ("arm64: mops: detect and enable FEAT_MOPS") Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com> Link: https://lore.kernel.org/r/20240930161051.3777828-2-kristina.martsenko@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f6fd7400cc0156dd8db8c4775d6763288a7b8ae3 Author: Bill O'Donnell <bodonnel@redhat.com> Date: Mon Oct 14 14:02:41 2024 -0500 efs: fix the efs new mount api implementation [ Upstream commit 51ceeb1a8142537b9f65aeaac6c301560a948197 ] Commit 39a6c668e4 (efs: convert efs to use the new mount api) did not include anything from v2 and v3 that were also submitted. Fix this by bringing in those changes that were proposed in v2 and v3. Fixes: 39a6c668e4 efs: convert efs to use the new mount api. Signed-off-by: Bill O'Donnell <bodonnel@redhat.com> Link: https://lore.kernel.org/r/20241014190241.4093825-1-bodonnel@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7a6d5b454916fd5d96b68772699a729cb1dd0cc6 Author: Gerd Bayer <gbayer@linux.ibm.com> Date: Thu Sep 26 17:37:06 2024 +0200 s390/facilities: Fix warning about shadow of global variable [ Upstream commit 61997c1e947dbf8bc625ef86ceee00fdf2a5dba1 ] Compiling the kernel with clang W=2 produces a warning that the parameter declarations in some routines would shadow the definition of the global variable stfle_fac_list. Address this warning by renaming the parameters to fac_list. Fixes: 17e89e1340a3 ("s390/facilities: move stfl information from lowcore to global data") Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1e4b4c9019b19fb79df7be204befc751dc690c61 Author: Fangzhi Zuo <Jerry.Zuo@amd.com> Date: Wed Sep 4 16:56:45 2024 -0400 drm/amd/display: Fix incorrect DSC recompute trigger [ Upstream commit 4641169a8c95d9efc35d2d3c55c3948f3b375ff9 ] A stream without dsc_aux should not be eliminated from the dsc determination. Whether it needs a dsc recompute depends on whether its mode has changed or not. Eliminating such a no-dsc stream from the dsc determination policy will end up with inconsistencies in the new dc_state when compared to the current dc_state, triggering a dsc recompute that should not have happened. Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 398da084db45efeb44a17648b5ca507f167f05be Author: Fangzhi Zuo <Jerry.Zuo@amd.com> Date: Mon Sep 23 16:20:40 2024 -0400 drm/amd/display: Skip Invalid Streams from DSC Policy [ Upstream commit 9afeda04964281e9f708b92c2a9c4f8a1387b46e ] Streams with invalid new connector state should be elimiated from dsc policy. Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5cda4da30d0b346a36188d4ec6174e72cf02cd30 Author: Xiuhong Wang <xiuhong.wang@unisoc.com> Date: Tue Oct 29 14:15:35 2024 +0800 f2fs: fix fiemap failure issue when page size is 16KB commit a7a7c1d423a6351a6541e95c797da5358e5ad1ea upstream. After enable 16K page size, an infinite loop may occur in fiemap (fm_length=UINT64_MAX) on a file, such as the 16KB scratch.img during the remount operation in Android. The condition for whether fiemap continues to map is to check whether the number of bytes corresponding to the next map.m_lblk exceeds blks_to_bytes(inode,max_inode_blocks(inode)) if there are HOLE. The latter does not take into account the maximum size of a file with 16KB page size, so the loop cannot be jumped out. The following is the fail trace: When f2fs_map_blocks reaches map.m_lblk=3936, it needs to go to the first direct node block, so the map is 3936 + 4090 = 8026, The next map is the second direct node block, that is, 8026 + 4090 = 12116, The next map is the first indirect node block, that is, 12116 + 4090 * 4090 = 16740216, The next map is the second indirect node block, that is, 16740216 + 4090 * 4090 = 33468316, The next map is the first double indirect node block, that is, 33468316 + 4090 * 4090 * 4090 = 68451397316 Since map.m_lblk represents the address of a block, which is 32 bits, truncation will occur, that is, 68451397316 becomes 4026887876, and the number of bytes corresponding to the block number does not exceed blks_to_bytes(inode,max_inode_blocks(inode)), so the loop will not be jumped out. The next time, it will be considered that it should still be a double indirect node block, that is, 4026887876 + 4090 * 4090 * 4090 = 72444816876, which will be truncated to 3725340140, and the loop will not be jumped out. 156.374871: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 0, start blkaddr = 0x8e00, len = 0x200, flags = 2,seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.374916: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 512, start blkaddr = 0x0, len = 0x0, flags = 0 , seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.374920: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 513, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 ...... 156.385747: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3935, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385752: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3936, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385755: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 8026, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385758: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 12116, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385761: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 16740216, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385764: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 33468316, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385767: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 4026887876, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385770: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3725340140, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385772: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 4026887876, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 156.385775: f2fs_map_blocks: dev = (254,57), ino = 7449, file offset = 3725340140, start blkaddr = 0x0, len = 0x0, flags = 0, seg_type = 8, may_create = 0, multidevice = 0, flag = 1, err = 0 Commit a6a010f5def5 ("f2fs: Restrict max filesize for 16K f2fs") has set the maximum allowed file size to (U32_MAX + 1) * F2FS_BLKSIZE, so max_file_blocks should be used here to limit it, that is, maxbytes defined above. And the max_inode_blocks function is not called by other functions except here, so cleanup it. Signed-off-by: Xiuhong Wang <xiuhong.wang@unisoc.com> Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Cc: Daniel Rosenberg <drosen@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> commit c50cb46df91fdcbdfa5f7f45cfad5a45f9b45d10 Author: Breno Leitao <leitao@debian.org> Date: Fri Nov 8 06:08:36 2024 -0800 ipmr: Fix access to mfc_cache_list without lock held [ Upstream commit e28acc9c1ccfcb24c08e020828f69d0a915b06ae ] Accessing `mr_table->mfc_cache_list` is protected by an RCU lock. In the following code flow, the RCU read lock is not held, causing the following error when `RCU_PROVE` is not held. The same problem might show up in the IPv6 code path. 6.12.0-rc5-kbuilder-01145-gbac17284bdcb #33 Tainted: G E N ----------------------------- net/ipv4/ipmr_base.c:313 RCU-list traversed in non-reader section!! rcu_scheduler_active = 2, debug_locks = 1 2 locks held by RetransmitAggre/3519: #0: ffff88816188c6c0 (nlk_cb_mutex-ROUTE){+.+.}-{3:3}, at: __netlink_dump_start+0x8a/0x290 #1: ffffffff83fcf7a8 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_dumpit+0x6b/0x90 stack backtrace: lockdep_rcu_suspicious mr_table_dump ipmr_rtm_dumproute rtnl_dump_all rtnl_dumpit netlink_dump __netlink_dump_start rtnetlink_rcv_msg netlink_rcv_skb netlink_unicast netlink_sendmsg This is not a problem per see, since the RTNL lock is held here, so, it is safe to iterate in the list without the RCU read lock, as suggested by Eric. To alleviate the concern, modify the code to use list_for_each_entry_rcu() with the RTNL-held argument. The annotation will raise an error only if RTNL or RCU read lock are missing during iteration, signaling a legitimate problem, otherwise it will avoid this false positive. This will solve the IPv6 case as well, since ip6mr_rtm_dumproute() calls this function as well. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20241108-ipmr_rcu-v2-1-c718998e209b@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c98339df1e3a2b2a35d2486c25a7a67a3ab0e40e Author: Linus Walleij <linus.walleij@linaro.org> Date: Mon Nov 11 00:17:03 2024 +0100 ARM: 9434/1: cfi: Fix compilation corner case [ Upstream commit 4aea16b7cfb76bd3361858ceee6893ef5c9b5570 ] When enabling expert mode CONFIG_EXPERT and using that power user mode to disable the branch prediction hardening !CONFIG_HARDEN_BRANCH_PREDICTOR, the assembly linker in CLANG notices that some assembly in proc-v7.S does not have corresponding C call sites, i.e. the prototypes in proc-v7-bugs.c are enclosed in ifdef CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly: SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm) SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm) Results in: ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm >>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94) >>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm >>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105) >>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a Fix this by adding an additional requirement that CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile these assembly calls. Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9813278e45b233069b29cb9a957cb2c981fac385 Author: Harith G <harith.g@alifsemi.com> Date: Wed Sep 18 06:57:53 2024 +0100 ARM: 9420/1: smp: Fix SMP for xip kernels [ Upstream commit 9e9b0cf9319b4db143014477b0bc4b39894248f1 ] Fix the physical address calculation of the following to get smp working on xip kernels. - secondary_data needed for secondary cpu bootup. - secondary_startup address passed through psci. - identity mapped code region needed for enabling mmu for secondary cpus. Signed-off-by: Harith George <harith.g@alifsemi.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org> commit b4325477af6b032f606923844e88a5d3c3228869 Author: Eryk Zagorski <erykzagorski@gmail.com> Date: Mon Nov 11 11:45:21 2024 -0500 ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry [ Upstream commit 6f891ca15b017707840c9e7f5afd9fc6cfd7d8b1 ] This patch switches the P-125 quirk entry to use a composite quirk as the P-125 supplies both MIDI and Audio like many of the other Yamaha keyboards Signed-off-by: Eryk Zagorski <erykzagorski@gmail.com> Link: https://patch.msgid.link/20241111164520.9079-2-erykzagorski@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2b8192781fd68820524e5f439463777a76d4a197 Author: Mark Brown <broonie@kernel.org> Date: Tue Nov 12 13:09:50 2024 +0000 ASoC: max9768: Fix event generation for playback mute [ Upstream commit 2ae6da569e34e1d26c5275442d17ffd75fd343b3 ] The max9768 has a custom control for playback mute which unconditionally returns 0 from the put() operation, rather than returning 1 on change to ensure notifications are generated to userspace. Check to see if the value has changed and return appropriately. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20241112-asoc-max9768-event-v1-1-ba5d50599787@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5eef420db5d591c39514880d748abb4830b1482c Author: Yuli Wang <wangyuli@uniontech.com> Date: Tue Nov 12 16:35:39 2024 +0800 LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS [ Upstream commit c859900a841b0a6cd9a73d16426465e44cdde29c ] This is a trivial cleanup, commit c62da0c35d58518d ("mm/vma: define a default value for VM_DATA_DEFAULT_FLAGS") has unified default values of VM_DATA_DEFAULT_FLAGS across different platforms. Apply the same consistency to LoongArch. Suggested-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: Yuli Wang <wangyuli@uniontech.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9775c22fe071ead067b164be7295a7ec7e1c7f7d Author: Huacai Chen <chenhuacai@kernel.org> Date: Tue Nov 12 16:35:36 2024 +0800 LoongArch: For all possible CPUs setup logical-physical CPU mapping [ Upstream commit a6654a40a852a4ca18aacced4cf5ca87997818d7 ] In order to support ACPI-based physical CPU hotplug, we suppose for all "possible" CPUs cpu_logical_map() can work. Because some drivers want to use cpu_logical_map() for all "possible" CPUs, while currently we only setup logical-physical mapping for "present" CPUs. This lack of mapping also causes cpu_to_node() cannot work for hot-added CPUs. All "possible" CPUs are listed in MADT, and the "present" subset is marked as ACPI_MADT_ENABLED. To setup logical-physical CPU mapping for all possible CPUs and keep present CPUs continuous in cpu_present_mask, we parse MADT twice. The first pass handles CPUs with ACPI_MADT_ENABLED and the second pass handles CPUs without ACPI_MADT_ENABLED. The global flag (cpu_enumerated) is removed because acpi_map_cpu() calls cpu_number_map() rather than set_processor_mask() now. Reported-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 102216a2ae244c913add6f5b856b96ce02197352 Author: John Watts <contact@jookia.org> Date: Fri Nov 8 12:37:15 2024 +1100 ASoC: audio-graph-card2: Purge absent supplies for device tree nodes [ Upstream commit f8da001ae7af0abd9f6250c02c01a1121074ca60 ] The audio graph card doesn't mark its subnodes such as multi {}, dpcm {} and c2c {} as not requiring any suppliers. This causes a hang as Linux waits for these phantom suppliers to show up on boot. Make it clear these nodes have no suppliers. Example error message: [ 15.208558] platform 2034000.i2s: deferred probe pending: platform: wait for supplier /sound/multi [ 15.208584] platform sound: deferred probe pending: asoc-audio-graph-card2: parse error Signed-off-by: John Watts <contact@jookia.org> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/20241108-graph_dt_fix-v1-1-173e2f9603d6@jookia.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ec1e8baa5da3888ca93fe1607ded32a31fcf1de8 Author: Gustavo A. R. Silva <gustavoars@kernel.org> Date: Thu Aug 8 16:04:59 2024 -0600 integrity: Use static_assert() to check struct sizes [ Upstream commit 08ae3e5f5fc8edb9bd0c7ef9696ff29ef18b26ef ] Commit 38aa3f5ac6d2 ("integrity: Avoid -Wflex-array-member-not-at-end warnings") introduced tagged `struct evm_ima_xattr_data_hdr` and `struct ima_digest_data_hdr`. We want to ensure that when new members need to be added to the flexible structures, they are always included within these tagged structs. So, we use `static_assert()` to ensure that the memory layout for both the flexible structure and the tagged struct is the same after any changes. Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Tested-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 48c8d9f0476bbb5c88ecdab73fc5b0238c28337b Author: David Wang <00107082@163.com> Date: Wed Nov 6 10:12:28 2024 +0800 proc/softirqs: replace seq_printf with seq_put_decimal_ull_width [ Upstream commit 84b9749a3a704dcc824a88aa8267247c801d51e4 ] seq_printf is costy, on a system with n CPUs, reading /proc/softirqs would yield 10*n decimal values, and the extra cost parsing format string grows linearly with number of cpus. Replace seq_printf with seq_put_decimal_ull_width have significant performance improvement. On an 8CPUs system, reading /proc/softirqs show ~40% performance gain with this patch. Signed-off-by: David Wang <00107082@163.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit df194b7febfaa99e90e284ed9e2b52fd4114f285 Author: Hans de Goede <hdegoede@redhat.com> Date: Sun Aug 25 15:21:31 2024 +0200 drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less strict [ Upstream commit 052ef642bd6c108a24f375f9ad174b97b425a50b ] There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it turns out that the 2G version has a DMI product name of "CHERRYVIEW D1 PLATFORM" where as the 4G version has "CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are unique enough that the product-name check is not necessary. Drop the product-name check so that the existing DMI match for the 4G RAM version also matches the 2G RAM version. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240825132131.6643-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit ecf3dbc27da23e2b88cb8c44687a22d7bb57cd6f Author: Luo Yifan <luoyifan@cmss.chinamobile.com> Date: Thu Nov 7 09:59:36 2024 +0800 ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div() [ Upstream commit 23569c8b314925bdb70dd1a7b63cfe6100868315 ] This patch checks if div is less than or equal to zero (div <= 0). If div is zero or negative, the function returns -EINVAL, ensuring the division operation is safe to perform. Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com> Reviewed-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241107015936.211902-1-luoyifan@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 498a382697ab498fb820d429381db6a735a6728c Author: Luo Yifan <luoyifan@cmss.chinamobile.com> Date: Wed Nov 6 09:46:54 2024 +0800 ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate() [ Upstream commit 63c1c87993e0e5bb11bced3d8224446a2bc62338 ] This patch checks if div is less than or equal to zero (div <= 0). If div is zero or negative, the function returns -EINVAL, ensuring the division operation (*prate / div) is safe to perform. Signed-off-by: Luo Yifan <luoyifan@cmss.chinamobile.com> Link: https://patch.msgid.link/20241106014654.206860-1-luoyifan@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3e1e243517c23a8a129f1a6d8b24cec7b280ffd7 Author: Markus Petri <mp@mpetri.org> Date: Thu Nov 7 10:40:20 2024 +0100 ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6 [ Upstream commit 8c21e40e1e481f7fef6e570089e317068b972c45 ] Another model of Thinkpad E14 Gen 6 (21M4) needs a quirk entry for the dmic to be detected. Signed-off-by: Markus Petri <mp@mpetri.org> Link: https://patch.msgid.link/20241107094020.1050935-1-mp@localhost Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3e275d4e446ec1e7a85d49e69e06b61980761f91 Author: Vishnu Sankar <vishnuocv@gmail.com> Date: Wed Nov 6 08:55:05 2024 +0900 platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect fan speed [ Upstream commit 1be765b292577c752e0b87bf8c0e92aff6699d8e ] Fix for Thinkpad's with ECFW showing incorrect fan speed. Some models use decimal instead of hexadecimal for the speed stored in the EC registers. For example the rpm register will have 0x4200 instead of 0x1068, here the actual RPM is "4200" in decimal. Add a quirk to handle this. Signed-off-by: Vishnu Sankar <vishnuocv@gmail.com> Suggested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Link: https://lore.kernel.org/r/20241105235505.8493-1-vishnuocv@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 257e483d48a5c3a5cceb597134c2add1f3b3576d Author: Alexander Hölzl <alexander.hoelzl@gmx.net> Date: Wed Oct 23 16:52:57 2024 +0200 can: j1939: fix error in J1939 documentation. [ Upstream commit b6ec62e01aa4229bc9d3861d1073806767ea7838 ] The description of PDU1 format usage mistakenly referred to PDU2 format. Signed-off-by: Alexander Hölzl <alexander.hoelzl@gmx.net> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20241023145257.82709-1-alexander.hoelzl@gmx.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5168ef8450dfe7399cc337d9c8d5564e68568634 Author: zhang jiao <zhangjiao2@cmss.chinamobile.com> Date: Thu Sep 12 12:50:31 2024 +0800 tools/lib/thermal: Remove the thermal.h soft link when doing make clean [ Upstream commit c5426dcc5a3a064bbd2de383e29035a14fe933e0 ] Run "make -C tools thermal" can create a soft link for thermal.h in tools/include/uapi/linux. Just rm it when make clean. Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20240912045031.18426-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5dbc4560a3e7359c901a537183d4122aba769b22 Author: Shenghao Ding <shenghao-ding@ti.com> Date: Mon Nov 4 18:00:55 2024 +0800 ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip [ Upstream commit fe09de2db2365eed8b44b572cff7d421eaf1754a ] Add new driver version to support tas2563 & tas2781 qfn chip Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20241104100055.48-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 16f045916d636576f91a037666d8c1b845862b06 Author: Renato Caldas <renato@calgera.com> Date: Sat Nov 2 18:31:16 2024 +0000 platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys [ Upstream commit 36e66be874a7ea9d28fb9757629899a8449b8748 ] The scancodes for the Mic Mute and Airplane keys on the Ideapad Pro 5 (14AHP9 at least, probably the other variants too) are different and were not being picked up by the driver. This adds them to the keymap. Apart from what is already supported, the remaining fn keys are unfortunately producing windows-specific key-combos. Signed-off-by: Renato Caldas <renato@calgera.com> Link: https://lore.kernel.org/r/20241102183116.30142-1-renato@calgera.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ac8d8cf686789dafc6a1cc7cbfc12f9763b522c4 Author: Kurt Borja <kuurtb@gmail.com> Date: Thu Oct 31 12:44:42 2024 -0300 platform/x86: dell-wmi-base: Handle META key Lock/Unlock events [ Upstream commit ec61f0bb4feec3345626a2b93b970b6719743997 ] Some Alienware devices have a key that locks/unlocks the Meta key. This key triggers a WMI event that should be ignored by the kernel, as it's handled by internally the firmware. There is no known way of changing this default behavior. The firmware would lock/unlock the Meta key, regardless of how the event is handled. Tested on an Alienware x15 R1. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20241031154441.6663-2-kuurtb@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 95a743d7c7676bbb4efcf372fcc5d219d17fbb40 Author: Kurt Borja <kuurtb@gmail.com> Date: Thu Oct 31 12:40:24 2024 -0300 platform/x86: dell-smbios-base: Extends support to Alienware products [ Upstream commit a36b8b84ac4327b90ef5a22bc97cc96a92073330 ] Fixes the following error: dell_smbios: Unable to run on non-Dell system Which is triggered after dell-wmi driver fails to initialize on Alienware systems, as it depends on dell-smbios. This effectively extends dell-wmi, dell-smbios and dcdbas support to Alienware devices, that might share some features of the SMBIOS intereface calling interface with other Dell products. Tested on an Alienware X15 R1. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20241031154023.6149-2-kuurtb@gmail.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 8a5b8a5e3545a59a13c1fbad9a0f4f8fa5cac81e Author: Mikhail Rudenko <mike.rudenko@gmail.com> Date: Thu Oct 17 21:37:28 2024 +0300 regulator: rk808: Add apply_bit for BUCK3 on RK809 [ Upstream commit 5e53e4a66bc7430dd2d11c18a86410e3a38d2940 ] Currently, RK809's BUCK3 regulator is modelled in the driver as a configurable regulator with 0.5-2.4V voltage range. But the voltage setting is not actually applied, because when bit 6 of PMIC_POWER_CONFIG register is set to 0 (default), BUCK3 output voltage is determined by the external feedback resistor. Fix this, by setting bit 6 when voltage selection is set. Existing users which do not specify voltage constraints in their device trees will not be affected by this change, since no voltage setting is applied in those cases, and bit 6 is not enabled. Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> Link: https://patch.msgid.link/20241017-rk809-dcdc3-v1-1-e3c3de92f39c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d6ef99a4cd07118b78135553917fef09ad51c085 Author: Cristian Marussi <cristian.marussi@arm.com> Date: Mon Oct 21 18:15:44 2024 +0100 firmware: arm_scmi: Reject clear channel request on A2P [ Upstream commit a0a18e91eb3a6ef75a6de69dc00f206b913e3848 ] The clear channel transport operation is supposed to be called exclusively on the P2A channel from the agent, since it relinquishes the ownership of the channel to the platform, after this latter has initiated some sort of P2A communication. Make sure that, if it is ever called on a A2P, is logged and ignored. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Message-Id: <20241021171544.2579551-1-cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9c2c33056b6e23e11ef18892862ac5b8b8869310 Author: Charles Han <hanchunchao@inspur.com> Date: Sun Sep 29 15:23:49 2024 +0800 soc: qcom: Add check devm_kasprintf() returned value [ Upstream commit e694d2b5c58ba2d1e995d068707c8d966e7f5f2a ] devm_kasprintf() can return a NULL pointer on failure but this returned value in qcom_socinfo_probe() is not checked. Signed-off-by: Charles Han <hanchunchao@inspur.com> Link: https://lore.kernel.org/r/20240929072349.202520-1-hanchunchao@inspur.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7cc7b5e575010834c1c2b1f8a8205908958b7c84 Author: Benoît Monin <benoit.monin@gmx.fr> Date: Thu Oct 24 17:11:13 2024 +0200 net: usb: qmi_wwan: add Quectel RG650V [ Upstream commit 6b3f18a76be6bbd237c7594cf0bf2912b68084fe ] Add support for Quectel RG650V which is based on Qualcomm SDX65 chip. The composition is DIAG / NMEA / AT / AT / QMI. T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2c7c ProdID=0122 Rev=05.15 S: Manufacturer=Quectel S: Product=RG650V-EU S: SerialNumber=xxxxxxx C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=9ms I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=9ms Signed-off-by: Benoît Monin <benoit.monin@gmx.fr> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241024151113.53203-1-benoit.monin@gmx.fr Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5e9c2a58f9e6b6993bc3585ff562a81152f539db Author: Jiayuan Chen <mrpre@163.com> Date: Mon Oct 28 14:52:26 2024 +0800 bpf: fix filed access without lock [ Upstream commit a32aee8f0d987a7cba7fcc28002553361a392048 ] The tcp_bpf_recvmsg_parser() function, running in user context, retrieves seq_copied from tcp_sk without holding the socket lock, and stores it in a local variable seq. However, the softirq context can modify tcp_sk->seq_copied concurrently, for example, n tcp_read_sock(). As a result, the seq value is stale when it is assigned back to tcp_sk->copied_seq at the end of tcp_bpf_recvmsg_parser(), leading to incorrect behavior. Due to concurrency, the copied_seq field in tcp_bpf_recvmsg_parser() might be set to an incorrect value (less than the actual copied_seq) at the end of function: 'WRITE_ONCE(tcp->copied_seq, seq)'. This causes the 'offset' to be negative in tcp_read_sock()->tcp_recv_skb() when processing new incoming packets (sk->copied_seq - skb->seq becomes less than 0), and all subsequent packets will be dropped. Signed-off-by: Jiayuan Chen <mrpre@163.com> Link: https://lore.kernel.org/r/20241028065226.35568-1-mrpre@163.com Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit fd1b4812b0588f8dc4a3d685e8f69d9b6d885cb9 Author: Arnd Bergmann <arnd@arndb.de> Date: Tue Oct 29 09:23:20 2024 +0000 x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB [ Upstream commit fce9642c765a18abd1db0339a7d832c29b68456a ] node_to_amd_nb() is defined to NULL in non-AMD configs: drivers/platform/x86/amd/hsmp/plat.c: In function 'init_platform_device': drivers/platform/x86/amd/hsmp/plat.c:165:68: error: dereferencing 'void *' pointer [-Werror] 165 | sock->root = node_to_amd_nb(i)->root; | ^~ drivers/platform/x86/amd/hsmp/plat.c:165:68: error: request for member 'root' in something not a structure or union Users of the interface who also allow COMPILE_TEST will cause the above build error so provide an inline stub to fix that. [ bp: Massage commit message. ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20241029092329.3857004-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> commit fea38203891c4d060c135c6b822e479f19e443af Author: Alexey Klimov <alexey.klimov@linaro.org> Date: Tue Oct 22 04:31:31 2024 +0100 ASoC: codecs: wcd937x: relax the AUX PDM watchdog [ Upstream commit 107a5c853eef5336a9846e7dd2f9184b6e3c07c7 ] On a system with wcd937x, rxmacro and Qualcomm audio DSP, which is pretty common set of devices on Qualcomm platforms, and due to the order of how DAPM widgets are powered on (they are sorted), there is a small time window when wcd937x chip is online and expects the flow of incoming data but rxmacro is not yet online. When wcd937x is programmed to receive data via AUX port then its AUX PDM watchdog is enabled in wcd937x_codec_enable_aux_pa(). If due to some reasons the rxmacro and soundwire machinery are delayed to start streaming data, then there is a chance for this AUX PDM watchdog to reset the wcd937x codec. Such event is not logged as a message and only wcd937x IRQ counter is increased however there could be a lot of other reasons for that IRQ. There is a similar opportunity for such delay during DAPM widgets power down sequence. If wcd937x codec reset happens on the start of the playback, then there will be no sound and if such reset happens at the end of a playback then it may generate additional clicks and pops noises. On qrb4210 RB2 board without any debugging bits the wcd937x resets are sometimes observed at the end of a playback though not always. With some debugging messages or with some tracing enabled the AUX PDM watchdog resets the wcd937x codec at the start of a playback and there is no sound output at all. In this patch: - TIMEOUT_SEL bit in PDM_WD_CTL2 register is set to increase the watchdog reset delay to 100ms which eliminates the AUX PDM watchdog IRQs on qrb4210 RB2 board completely and decreases the number of unwanted clicks noises; - HOLD_OFF bit postpones triggering such watchdog IRQ till wcd937x codec reset which usually happens at the end of a playback. This allows to actually output some sound in case of debugging. Cc: Adam Skladowski <a39.skl@gmail.com> Cc: Mohammad Rafi Shaik <quic_mohs@quicinc.com> Cc: Prasad Kumpatla <quic_pkumpatl@quicinc.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20241022033132.787416-3-alexey.klimov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 24ed159e56379da8f12fb135e6ee5ef5abe199e8 Author: Alexey Klimov <alexey.klimov@linaro.org> Date: Tue Oct 22 04:31:30 2024 +0100 ASoC: codecs: wcd937x: add missing LO Switch control [ Upstream commit 041db4bbe04e8e0b48350b3bbbd9a799794d5c1e ] The wcd937x supports also AUX input but the control that sets correct soundwire port for this is missing. This control is required for audio playback, for instance, on qrb4210 RB2 board as well as on other SoCs. Reported-by: Adam Skladowski <a39.skl@gmail.com> Reported-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com> Suggested-by: Adam Skladowski <a39.skl@gmail.com> Suggested-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Mohammad Rafi Shaik <quic_mohs@quicinc.com> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20241022033132.787416-2-alexey.klimov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit ce71f0ba4d45f7f1e0f5a0f3e1e0cc202acd21f0 Author: Piyush Raj Chouhan <piyushchouhan1598@gmail.com> Date: Mon Oct 28 15:55:16 2024 +0000 ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13 [ Upstream commit ef5fbdf732a158ec27eeba69d8be851351f29f73 ] Infinix ZERO BOOK 13 has a 2+2 speaker system which isn't probed correctly. This patch adds a quirk with the proper pin connections. Also The mic in this laptop suffers too high gain resulting in mostly fan noise being recorded, This patch Also limit mic boost. HW Probe for device; https://linux-hardware.org/?probe=a2e892c47b Test: All 4 speaker works, Mic has low noise. Signed-off-by: Piyush Raj Chouhan <piyushchouhan1598@gmail.com> Link: https://patch.msgid.link/20241028155516.15552-1-piyuschouhan1598@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 25292b64d9428b459e9694415df95623e437fb43 Author: Li Zhijian <lizhijian@fujitsu.com> Date: Tue Oct 29 11:13:24 2024 +0800 selftests/watchdog-test: Fix system accidentally reset after watchdog-test [ Upstream commit dc1308bee1ed03b4d698d77c8bd670d399dcd04d ] When running watchdog-test with 'make run_tests', the watchdog-test will be terminated by a timeout signal(SIGTERM) due to the test timemout. And then, a system reboot would happen due to watchdog not stop. see the dmesg as below: ``` [ 1367.185172] watchdog: watchdog0: watchdog did not stop! ``` Fix it by registering more signals(including SIGTERM) in watchdog-test, where its signal handler will stop the watchdog. After that # timeout 1 ./watchdog-test Watchdog Ticking Away! . Stopping watchdog ticks... Link: https://lore.kernel.org/all/20241029031324.482800-1-lizhijian@fujitsu.com/ Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 32eef3be6047c7832f7c2abec15c7cafe70fef39 Author: Javier Carrasco <javier.carrasco.cruz@gmail.com> Date: Mon Oct 21 22:45:30 2024 +0200 usb: typec: use cleanup facility for 'altmodes_node' [ Upstream commit 1ab0b9ae587373f9f800b6fda01b8faf02b3530b ] Use the __free() macro for 'altmodes_node' to automatically release the node when it goes out of scope, removing the need for explicit calls to fwnode_handle_put(). Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20241021-typec-class-fwnode_handle_put-v2-2-3281225d3d27@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0a80f272667dc9bf32fbffb808eb31db45e24efa Author: Benjamin Große <ste3ls@gmail.com> Date: Sun Oct 20 18:41:28 2024 +0100 usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver [ Upstream commit 94c11e852955b2eef5c4f0b36cfeae7dcf11a759 ] This patch adds support for another Lenovo Mini dock 0x17EF:0x3098 to the r8152 driver. The device has been tested on NixOS, hotplugging and sleep included. Signed-off-by: Benjamin Große <ste3ls@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20241020174128.160898-1-ste3ls@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f8df56fd4fa74381f9255edca5ab7763ed567fda Author: Ben Greear <greearb@candelatech.com> Date: Thu Oct 10 13:39:54 2024 -0700 mac80211: fix user-power when emulating chanctx [ Upstream commit 9b15c6cf8d2e82c8427cd06f535d8de93b5b995c ] ieee80211_calc_hw_conf_chan was ignoring the configured user_txpower. If it is set, use it to potentially decrease txpower as requested. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20241010203954.1219686-1-greearb@candelatech.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit dcfbe60f12e9eb13bad7c57eb979030d2420d593 Author: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Date: Thu Oct 10 14:05:04 2024 +0300 wifi: iwlwifi: mvm: SAR table alignment [ Upstream commit 32d95ab330069f9c551b8e99770bb4e799730b55 ] SAR table format in ACPI and local data base are different, So modified code to read data properly. Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241010140328.f077aced4dee.I4dc618f12d01f7ad19f9f8881f6e09eea77e9a14@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a34d1461943394d19ae55eedb856789444963e00 Author: Daniel Gabay <daniel.gabay@intel.com> Date: Thu Oct 10 14:05:03 2024 +0300 wifi: iwlwifi: mvm: Use the sync timepoint API in suspend [ Upstream commit 9715246ca0bfc9feaec1b4ff5b3d38de65a7025d ] When starting the suspend flow, HOST_D3_START triggers an _async_ firmware dump collection for debugging purposes. The async worker may race with suspend flow and fail to get NIC access, resulting in the following warning: "Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)" Fix this by switching to the sync version to ensure the dump completes before proceeding with the suspend flow, avoiding potential race issues. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20241010140328.9aae318cd593.I4b322009f39489c0b1d8893495c887870f73ed9c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 631c91dd5315ad3c3431f532ea46eba75abf3e38 Author: Hans de Goede <hdegoede@redhat.com> Date: Fri Oct 25 11:02:21 2024 +0200 ASoC: Intel: sst: Support LPE0F28 ACPI HID [ Upstream commit 6668610b4d8ce9a3ee3ed61a9471f62fb5f05bf9 ] Some old Bay Trail tablets which shipped with Android as factory OS have the SST/LPE audio engine described by an ACPI device with a HID (Hardware-ID) of LPE0F28 instead of 80860F28. Add support for this. Note this uses a new sst_res_info for just the LPE0F28 case because it has a different layout for the IO-mem ACPI resources then the 80860F28. An example of a tablet which needs this is the Vexia EDU ATLA 10 tablet, which has been distributed to schools in the Spanish Andalucía region. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241025090221.52198-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 80bf8c5688f3800b56dc825ba5c075e1e9706ad8 Author: Hans de Goede <hdegoede@redhat.com> Date: Thu Oct 24 23:16:15 2024 +0200 ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet [ Upstream commit 0107f28f135231da22a9ad5756bb16bd5cada4d5 ] The Vexia Edu Atla 10 tablet mostly uses the BYTCR tablet defaults, but as happens on more models it is using IN1 instead of IN3 for its internal mic and JD_SRC_JD2_IN4N instead of JD_SRC_JD1_IN4P for jack-detection. Add a DMI quirk for this to fix the internal-mic and jack-detection. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241024211615.79518-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 61cc3cff10f030eb753cc10c72f05805eb2d341f Author: Hans de Goede <hdegoede@redhat.com> Date: Thu Oct 24 23:16:14 2024 +0200 ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec [ Upstream commit d48696b915527b5bcdd207a299aec03fb037eb17 ] On some x86 Bay Trail tablets which shipped with Android as factory OS, the DSDT is so broken that the codec needs to be manually instantatiated by the special x86-android-tablets.ko "fixup" driver for cases like this. This means that the codec-dev cannot be retrieved through its ACPI fwnode, add support to the bytcr_rt5640 machine driver for such manually instantiated rt5640 i2c_clients. An example of a tablet which needs this is the Vexia EDU ATLA 10 tablet, which has been distributed to schools in the Spanish Andalucía region. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241024211615.79518-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e828412d19eced85a87cf1c420dcd9d355f3af3d Author: Hans de Goede <hdegoede@redhat.com> Date: Thu Oct 24 23:56:12 2024 +0200 ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work() [ Upstream commit 032532f91a1d06d0750f16c49a9698ef5374a68f ] Disable IRQs from rt5640_cancel_work(), this fixes a crash caused by the IRQ never getting freed when the driver is unbound from the i2c_client with jack-detection active: [ 193.138780] rt5640 i2c-rt5640: ASoC: unknown pin LDO2 [ 193.138830] rt5640 i2c-rt5640: ASoC: unknown pin MICBIAS1 [ 193.671218] BUG: kernel NULL pointer dereference, address: 0000000000000078 [ 193.671239] #PF: supervisor read access in kernel mode [ 193.671248] #PF: error_code(0x0000) - not-present page ... [ 193.671531] ? asm_exc_page_fault+0x22/0x30 [ 193.671551] ? rt5640_jack_inserted+0x10/0x80 [snd_soc_rt5640] [ 193.671574] rt5640_detect_headset+0x93/0x130 [snd_soc_rt5640] [ 193.671596] rt5640_jack_work+0x93/0x355 [snd_soc_rt5640] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241024215612.92147-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3a691880832449bf4c37400b4c13185e401647f8 Author: Alain Volmat <alain.volmat@foss.st.com> Date: Wed Oct 9 18:15:52 2024 +0200 spi: stm32: fix missing device mode capability in stm32mp25 [ Upstream commit b5a468199b995bd8ee3c26f169a416a181210c9e ] The STM32MP25 SOC has capability to behave in device mode however missing .has_device_mode within its stm32mp25_spi_cfg structure leads to not being able to enable the device mode. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20241009-spi-mp25-device-fix-v1-1-8e5ca7db7838@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 119f99d7f6eff6d97f3b4f656ba4828c42e82bff Author: Gustavo A. R. Silva <gustavoars@kernel.org> Date: Fri Oct 4 14:14:44 2024 -0600 wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings [ Upstream commit 57be3d3562ca4aa62b8047bc681028cc402af8ce ] -Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. So, in order to avoid ending up with a flexible-array member in the middle of multiple other structs, we use the `__struct_group()` helper to create a new tagged `struct ieee80211_radiotap_header_fixed`. This structure groups together all the members of the flexible `struct ieee80211_radiotap_header` except the flexible array. As a result, the array is effectively separated from the rest of the members without modifying the memory layout of the flexible structure. We then change the type of the middle struct members currently causing trouble from `struct ieee80211_radiotap_header` to `struct ieee80211_radiotap_header_fixed`. We also want to ensure that in case new members need to be added to the flexible structure, they are always included within the newly created tagged struct. For this, we use `static_assert()`. This ensures that the memory layout for both the flexible structure and the new tagged struct is the same after any changes. This approach avoids having to implement `struct ieee80211_radiotap_header_fixed` as a completely separate structure, thus preventing having to maintain two independent but basically identical structures, closing the door to potential bugs in the future. So, with these changes, fix the following warnings: drivers/net/wireless/ath/wil6210/txrx.c:309:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/ipw2100.c:2521:50: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/ipw2200.h:1146:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/intel/ipw2x00/libipw.h:595:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/marvell/libertas/radiotap.h:34:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/marvell/libertas/radiotap.h:5:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/microchip/wilc1000/mon.c:10:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/microchip/wilc1000/mon.c:15:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/virtual/mac80211_hwsim.c:758:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/virtual/mac80211_hwsim.c:767:42: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://patch.msgid.link/ZwBMtBZKcrzwU7l4@kspp Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 7dc8af06841c8416dce2533528ce06300e34e457 Author: Remi Pommarel <repk@triplefau.lt> Date: Tue Sep 24 21:28:05 2024 +0200 wifi: mac80211: Convert color collision detection to wiphy work [ Upstream commit 4cc6f3e5e5765abad9c091989970d67d8c1d2204 ] Call to ieee80211_color_collision_detection_work() needs wiphy lock to be held (see lockdep assert in cfg80211_bss_color_notify()). Not locking wiphy causes the following lockdep error: WARNING: CPU: 2 PID: 42 at net/wireless/nl80211.c:19505 cfg80211_bss_color_notify+0x1a4/0x25c Modules linked in: CPU: 2 PID: 42 Comm: kworker/u8:3 Tainted: G W 6.4.0-02327-g36c6cb260481 #1048 Hardware name: Workqueue: phy1 ieee80211_color_collision_detection_work pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cfg80211_bss_color_notify+0x1a4/0x25c lr : cfg80211_bss_color_notify+0x1a0/0x25c sp : ffff000002947d00 x29: ffff000002947d00 x28: ffff800008e1a000 x27: ffff000002bd4705 x26: ffff00000d034000 x25: ffff80000903cf40 x24: 0000000000000000 x23: ffff00000cb70720 x22: 0000000000800000 x21: ffff800008dfb008 x20: 000000000000008d x19: ffff00000d035fa8 x18: 0000000000000010 x17: 0000000000000001 x16: 000003564b1ce96a x15: 000d69696d057970 x14: 000000000000003b x13: 0000000000000001 x12: 0000000000040000 x11: 0000000000000001 x10: ffff80000978f9c0 x9 : ffff0000028d3174 x8 : ffff800008e30000 x7 : 0000000000000000 x6 : 0000000000000028 x5 : 000000000002f498 x4 : ffff00000d034a80 x3 : 0000000000800000 x2 : ffff800016143000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: cfg80211_bss_color_notify+0x1a4/0x25c ieee80211_color_collision_detection_work+0x20/0x118 process_one_work+0x294/0x554 worker_thread+0x70/0x440 kthread+0xf4/0xf8 ret_from_fork+0x10/0x20 irq event stamp: 77372 hardirqs last enabled at (77371): [<ffff800008a346fc>] _raw_spin_unlock_irq+0x2c/0x4c hardirqs last disabled at (77372): [<ffff800008a28754>] el1_dbg+0x20/0x48 softirqs last enabled at (77350): [<ffff8000089e120c>] batadv_send_outstanding_bcast_packet+0xb8/0x120 softirqs last disabled at (77348): [<ffff8000089e11d4>] batadv_send_outstanding_bcast_packet+0x80/0x120 The wiphy lock cannot be taken directly from color collision detection delayed work (ieee80211_color_collision_detection_work()) because this work is cancel_delayed_work_sync() under this wiphy lock causing a potential deadlock( see [0] for details). To fix that ieee80211_color_collision_detection_work() could be converted to a wiphy work and cancel_delayed_work_sync() can be simply replaced by wiphy_delayed_work_cancel() serving the same purpose under wiphy lock. This could potentially fix [1]. [0]: https://lore.kernel.org/linux-wireless/D4A40Q44OAY2.W3SIF6UEPBUN@freebox.fr/ [1]: https://lore.kernel.org/lkml/000000000000612f290618eee3e5@google.com/ Reported-by: Nicolas Escande <nescande@freebox.fr> Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/20240924192805.13859-3-repk@triplefau.lt Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 58b1007e603a47ad82b853bc823b85ce418824b7 Author: Remi Pommarel <repk@triplefau.lt> Date: Tue Sep 24 21:28:04 2024 +0200 wifi: cfg80211: Add wiphy_delayed_work_pending() [ Upstream commit 68d0021fe7231eec0fb84cd110cf62a6e782b72d ] Add wiphy_delayed_work_pending() to check if any delayed work timer is pending, that can be used to be sure that wiphy_delayed_work_queue() won't postpone an already pending delayed work. Signed-off-by: Remi Pommarel <repk@triplefau.lt> Link: https://patch.msgid.link/20240924192805.13859-2-repk@triplefau.lt [fix return value kernel-doc] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 38745b811776b39267a6ace7a0261b10a5d2d807 Author: Ben Greear <greearb@candelatech.com> Date: Mon Sep 23 18:13:25 2024 -0700 wifi: mac80211: Fix setting txpower with emulate_chanctx [ Upstream commit 8dd0498983eef524a8d104eb8abb32ec4c595bec ] Propagate hw conf into the driver when txpower changes and driver is emulating channel contexts. Signed-off-by: Ben Greear <greearb@candelatech.com> Link: https://patch.msgid.link/20240924011325.1509103-1-greearb@candelatech.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>