commit 22a054ea1f081d7837cc8e24ad4c7aa36e8bba04 Author: Greg Kroah-Hartman Date: Mon Dec 9 10:33:11 2024 +0100 Linux 6.6.64 Link: https://lore.kernel.org/r/20241206143653.344873888@linuxfoundation.org Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: kernelci.org bot Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Tested-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman commit f3b82bb26f5beeae830a9eff1538e89a4bbca0e7 Author: Frederic Weisbecker Date: Sat Nov 23 00:48:11 2024 +0100 posix-timers: Target group sigqueue to current task only if not exiting commit 63dffecfba3eddcf67a8f76d80e0c141f93d44a5 upstream. A sigqueue belonging to a posix timer, which target is not a specific thread but a whole thread group, is preferrably targeted to the current task if it is part of that thread group. However nothing prevents a posix timer event from queueing such a sigqueue from a reaped yet running task. The interruptible code space between exit_notify() and the final call to schedule() is enough for posix_timer_fn() hrtimer to fire. If that happens while the current task is part of the thread group target, it is proposed to handle it but since its sighand pointer may have been cleared already, the sigqueue is dropped even if there are other tasks running within the group that could handle it. As a result posix timers with thread group wide target may miss signals when some of their threads are exiting. Fix this with verifying that the current task hasn't been through exit_notify() before proposing it as a preferred target so as to ensure that its sighand is still here and stable. complete_signal() might still reconsider the choice and find a better target within the group if current has passed retarget_shared_pending() already. Fixes: bcb7ee79029d ("posix-timers: Prefer delivery of signals to the current thread") Reported-by: Anthony Mallet Suggested-by: Oleg Nesterov Signed-off-by: Frederic Weisbecker Signed-off-by: Thomas Gleixner Acked-by: Oleg Nesterov Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241122234811.60455-1-frederic@kernel.org Closes: https://lore.kernel.org/all/26411.57288.238690.681680@gargle.gargle.HOWL Signed-off-by: Greg Kroah-Hartman commit 8a799149ab451199d6acbec37944d66b3e964573 Author: Umio Yasuno Date: Thu Nov 14 16:15:27 2024 +0900 drm/amd/pm: update current_socclk and current_uclk in gpu_metrics on smu v13.0.7 commit 2abf2f7032df4c4e7f6cf7906da59d0e614897d6 upstream. These were missed before. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3751 Signed-off-by: Umio Yasuno Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 3990ef742c064e22189b954522930db04fc6b1a7 Author: Vitaly Prosyak Date: Mon Nov 11 17:24:08 2024 -0500 drm/amdgpu: fix usage slab after free commit b61badd20b443eabe132314669bb51a263982e5c upstream. [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_probe+0x361/0xf30 [amdgpu] [ +0.000651] local_pci_probe+0xe7/0x1b0 [ +0.000009] pci_device_probe+0x248/0x890 [ +0.000008] really_probe+0x1fd/0x950 [ +0.000008] __driver_probe_device+0x307/0x410 [ +0.000007] driver_probe_device+0x4e/0x150 [ +0.000007] __driver_attach+0x223/0x510 [ +0.000006] bus_for_each_dev+0x102/0x1a0 [ +0.000007] driver_attach+0x3d/0x60 [ +0.000006] bus_add_driver+0x2ac/0x5f0 [ +0.000006] driver_register+0x13d/0x490 [ +0.000008] __pci_register_driver+0x1ee/0x2b0 [ +0.000007] llc_sap_close+0xb0/0x160 [llc] [ +0.000009] do_one_initcall+0x9c/0x3e0 [ +0.000008] do_init_module+0x241/0x760 [ +0.000008] load_module+0x51ac/0x6c30 [ +0.000006] __do_sys_init_module+0x234/0x270 [ +0.000007] __x64_sys_init_module+0x73/0xc0 [ +0.000006] x64_sys_call+0xe3/0x2680 [ +0.000006] do_syscall_64+0x70/0x130 [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000015] Freed by task 2147 on cpu 6 at 160.507651s: [ +0.000013] kasan_save_stack+0x28/0x60 [ +0.000007] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_free_info+0x3b/0x60 [ +0.000007] poison_slab_object+0x115/0x1c0 [ +0.000007] __kasan_slab_free+0x34/0x60 [ +0.000007] kfree+0xfa/0x2f0 [ +0.000007] drm_sched_fini+0x19d/0x410 [gpu_sched] [ +0.000012] amdgpu_fence_driver_sw_fini+0xc4/0x2f0 [amdgpu] [ +0.000662] amdgpu_device_fini_sw+0x77/0xfc0 [amdgpu] [ +0.000653] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000655] drm_minor_release+0xc9/0x140 [drm] [ +0.000071] drm_release+0x1fd/0x390 [drm] [ +0.000071] __fput+0x36c/0xad0 [ +0.000008] __fput_sync+0x3c/0x50 [ +0.000007] __x64_sys_close+0x7d/0xe0 [ +0.000007] x64_sys_call+0x1bc6/0x2680 [ +0.000007] do_syscall_64+0x70/0x130 [ +0.000007] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] The buggy address belongs to the object at ffff8881b8605f80 which belongs to the cache kmalloc-64 of size 64 [ +0.000020] The buggy address is located 8 bytes inside of freed 64-byte region [ffff8881b8605f80, ffff8881b8605fc0) [ +0.000028] The buggy address belongs to the physical page: [ +0.000011] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1b8605 [ +0.000008] anon flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ +0.000007] page_type: 0xffffefff(slab) [ +0.000009] raw: 0017ffffc0000000 ffff8881000428c0 0000000000000000 dead000000000001 [ +0.000006] raw: 0000000000000000 0000000000200020 00000001ffffefff 0000000000000000 [ +0.000006] page dumped because: kasan: bad access detected [ +0.000012] Memory state around the buggy address: [ +0.000011] ffff8881b8605e80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ +0.000015] ffff8881b8605f00: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc [ +0.000015] >ffff8881b8605f80: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc [ +0.000013] ^ [ +0.000011] ffff8881b8606000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc [ +0.000014] ffff8881b8606080: fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb [ +0.000013] ================================================================== The issue reproduced on VG20 during the IGT pci_unplug test. The root cause of the issue is that the function drm_sched_fini is called before drm_sched_entity_kill. In drm_sched_fini, the drm_sched_rq structure is freed, but this structure is later accessed by each entity within the run queue, leading to invalid memory access. To resolve this, the order of cleanup calls is updated: Before: amdgpu_fence_driver_sw_fini amdgpu_device_ip_fini After: amdgpu_device_ip_fini amdgpu_fence_driver_sw_fini This updated order ensures that all entities in the IPs are cleaned up first, followed by proper cleanup of the schedulers. Additional Investigation: During debugging, another issue was identified in the amdgpu_vce_sw_fini function. The vce.vcpu_bo buffer must be freed only as the final step in the cleanup process to prevent any premature access during earlier cleanup stages. v2: Using Christian suggestion call drm_sched_entity_destroy before drm_sched_fini. Cc: Christian König Cc: Alex Deucher Signed-off-by: Vitaly Prosyak Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 70e6599a9e78384d22c3feb95da46514e5e5ee41 Author: Lijo Lazar Date: Mon Nov 11 20:11:38 2024 +0530 drm/amdkfd: Use the correct wptr size commit cdc6705f98ea3f854a60ba8c9b19228e197ae384 upstream. Write pointer could be 32-bit or 64-bit. Use the correct size during initialization. Signed-off-by: Lijo Lazar Acked-by: Alex Deucher Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d50b5a7ac7f56cb816dab2879f05ebe9962daa3e Author: Steffen Dirkwinkel Date: Mon Oct 28 14:42:17 2024 +0100 drm: xlnx: zynqmp_dpsub: fix hotplug detection commit 71ba1c9b1c717831920c3d432404ee5a707e04b4 upstream. drm_kms_helper_poll_init needs to be called after zynqmp_dpsub_kms_init. zynqmp_dpsub_kms_init creates the connector and without it we don't enable hotplug detection. Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Cc: stable@vger.kernel.org Signed-off-by: Steffen Dirkwinkel Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20241028134218.54727-1-lists@steffen.cc Signed-off-by: Greg Kroah-Hartman commit 65bea1cb02303cf36e8d98fa5d681b3315e607b2 Author: Lucas Stach Date: Fri Oct 25 17:14:46 2024 +0200 drm/etnaviv: flush shader L1 cache after user commandstream commit 4f8dbadef085ab447a01a8d4806a3f629fea05ed upstream. The shader L1 cache is a writeback cache for shader loads/stores and thus must be flushed before any BOs backing the shader buffers are potentially freed. Cc: stable@vger.kernel.org Reviewed-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit a3d970f106bbbf28914f6b77ac463b39e1338449 Author: Javier Carrasco Date: Fri Oct 11 21:21:51 2024 +0200 drm/mediatek: Fix child node refcount handling in early exit commit f708e8b4cfd16e5c8cd8d7fcfcb2fb2c6ed93af3 upstream. Early exits (goto, break, return) from for_each_child_of_node() required an explicit call to of_node_put(), which was not introduced with the break if cnt == MAX_CRTC. Add the missing of_node_put() before the break. Cc: stable@vger.kernel.org Fixes: d761b9450e31 ("drm/mediatek: Add cnt checking for coverity issue") Signed-off-by: Javier Carrasco Reviewed-by: CK Hu Reviewed-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20241011-mtk_drm_drv_memleak-v1-1-2b40c74c8d75@gmail.com/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Greg Kroah-Hartman commit 8ab73ac97c0fa528f66eeccd9bb53eb6eb7d20dc Author: Ma Ke Date: Fri Sep 13 17:04:12 2024 +0800 drm/sti: avoid potential dereference of error pointers commit 831214f77037de02afc287eae93ce97f218d8c04 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes") Signed-off-by: Ma Ke Link: https://patchwork.freedesktop.org/patch/msgid/20240913090412.2022848-1-make24@iscas.ac.cn Signed-off-by: Alain Volmat Signed-off-by: Greg Kroah-Hartman commit 997b64c3f4c1827c5cfda8ae7f5d13f78d28b541 Author: Ma Ke Date: Mon Sep 9 14:33:59 2024 +0800 drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check commit e965e771b069421c233d674c3c8cd8c7f7245f42 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes") Signed-off-by: Ma Ke Acked-by: Alain Volmat Link: https://patchwork.freedesktop.org/patch/msgid/20240909063359.1197065-1-make24@iscas.ac.cn Signed-off-by: Alain Volmat Signed-off-by: Greg Kroah-Hartman commit 82a5312f874fb18f045d9658e9bd290e3b0621c0 Author: Ma Ke Date: Fri Sep 13 17:09:26 2024 +0800 drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check commit c1ab40a1fdfee732c7e6ff2fb8253760293e47e8 upstream. The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f9ae1 ("drm/sti: implement atomic_check for the planes") Signed-off-by: Ma Ke Link: https://patchwork.freedesktop.org/patch/msgid/20240913090926.2023716-1-make24@iscas.ac.cn Signed-off-by: Alain Volmat Signed-off-by: Greg Kroah-Hartman commit ac48ddf6b0232863674d38d4d0edecb40a1bda78 Author: Vivek Kasireddy Date: Sun Jun 23 23:36:13 2024 -0700 udmabuf: use vmf_insert_pfn and VM_PFNMAP for handling mmap commit 7d79cd784470395539bda91bf0b3505ff5b2ab6d upstream. Add VM_PFNMAP to vm_flags in the mmap handler to ensure that the mappings would be managed without using struct page. And, in the vm_fault handler, use vmf_insert_pfn to share the page's pfn to userspace instead of directly sharing the page (via struct page *). Link: https://lkml.kernel.org/r/20240624063952.1572359-6-vivek.kasireddy@intel.com Signed-off-by: Vivek Kasireddy Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Acked-by: Dave Airlie Acked-by: Gerd Hoffmann Cc: Daniel Vetter Cc: Hugh Dickins Cc: Peter Xu Cc: Jason Gunthorpe Cc: Dongwon Kim Cc: Junxiao Chang Cc: Arnd Bergmann Cc: Christoph Hellwig Cc: Christoph Hellwig Cc: Matthew Wilcox (Oracle) Cc: Mike Kravetz Cc: Oscar Salvador Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit cfaf83501a0cbb104499c5b0892ee5ebde4e967f Author: Jarkko Sakkinen Date: Thu Oct 31 02:16:09 2024 +0200 tpm: Lock TPM chip in tpm_pm_suspend() first commit 9265fed6db601ee2ec47577815387458ef4f047a upstream. Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved. Cc: stable@vger.kernel.org # v6.4+ Fixes: 99d464506255 ("tpm: Prevent hwrng from activating during resume") Reported-by: Mike Seo Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219383 Reviewed-by: Jerry Snitselaar Tested-by: Mike Seo Signed-off-by: Jarkko Sakkinen [ Don't call tpm2_end_auth_session() for this function does not exist in 6.6.y.] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 135b4819f6fba87fd5a2693023133e78ac73f1d3 Author: Josef Bacik Date: Tue May 7 14:12:10 2024 -0400 btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() commit a580fb2c3479d993556e1c31b237c9e5be4944a3 upstream. We handle errors here properly, ENOMEM isn't fatal, return the error. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Keerthana K Signed-off-by: Greg Kroah-Hartman commit c062bba16246032a167f55b084125f20df95624f Author: Nathan Chancellor Date: Wed Oct 9 12:26:09 2024 -0700 powerpc: Adjust adding stack protector flags to KBUILD_CLAGS for clang commit bee08a9e6ab03caf14481d97b35a258400ffab8f upstream. After fixing the HAVE_STACKPROTECTER checks for clang's in-progress per-task stack protector support [1], the build fails during prepare0 because '-mstack-protector-guard-offset' has not been added to KBUILD_CFLAGS yet but the other '-mstack-protector-guard' flags have. clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default make[4]: *** [scripts/Makefile.build:229: scripts/mod/empty.o] Error 1 make[4]: *** [scripts/Makefile.build:102: scripts/mod/devicetable-offsets.s] Error 1 Mirror other architectures and add all '-mstack-protector-guard' flags to KBUILD_CFLAGS atomically during stack_protector_prepare, which resolves the issue and allows clang's implementation to fully work with the kernel. Cc: stable@vger.kernel.org # 6.1+ Link: https://github.com/llvm/llvm-project/pull/110928 [1] Reviewed-by: Keith Packard Tested-by: Keith Packard Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-2-12fb86b31857@kernel.org Signed-off-by: Greg Kroah-Hartman commit 0760e47fa63241ff895edba1f0646e8b1f821d84 Author: Nathan Chancellor Date: Wed Oct 9 12:26:08 2024 -0700 powerpc: Fix stack protector Kconfig test for clang commit 46e1879deea22eed31e9425d58635895fc0e8040 upstream. Clang's in-progress per-task stack protector support [1] does not work with the current Kconfig checks because '-mstack-protector-guard-offset' is not provided, unlike all other architecture Kconfig checks. $ fd Kconfig -x rg -l mstack-protector-guard-offset ./arch/arm/Kconfig ./arch/riscv/Kconfig ./arch/arm64/Kconfig This produces an error from clang, which is interpreted as the flags not being supported at all when they really are. $ clang --target=powerpc64-linux-gnu \ -mstack-protector-guard=tls \ -mstack-protector-guard-reg=r13 \ -c -o /dev/null -x c /dev/null clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default This argument will always be provided by the build system, so mirror other architectures and use '-mstack-protector-guard-offset=0' for testing support, which fixes the issue for clang and does not regress support with GCC. Even with the first problem addressed, the 32-bit test continues to fail because Kbuild uses the powerpc64le-linux-gnu target for clang and nothing flips the target to 32-bit, resulting in an error about an invalid register valid: $ clang --target=powerpc64le-linux-gnu \ -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 \ -mstack-protector-guard-offset=0 \ -x c -c -o /dev/null /dev/null clang: error: invalid value 'r2' in 'mstack-protector-guard-reg=', expected one of: r13 While GCC allows arbitrary registers, the implementation of '-mstack-protector-guard=tls' in LLVM shares the same code path as the user space thread local storage implementation, which uses a fixed register (2 for 32-bit and 13 for 62-bit), so the command line parsing enforces this limitation. Use the Kconfig macro '$(m32-flag)', which expands to '-m32' when supported, in the stack protector support cc-option call to properly switch the target to a 32-bit one, which matches what happens in Kbuild. While the 64-bit macro does not strictly need it, add the equivalent 64-bit option for symmetry. Cc: stable@vger.kernel.org # 6.1+ Link: https://github.com/llvm/llvm-project/pull/110928 [1] Reviewed-by: Keith Packard Tested-by: Keith Packard Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-1-12fb86b31857@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1bdff8a19cd6f7ef76eba3e6739d0f1702d49f06 Author: Zicheng Qu Date: Thu Oct 31 01:46:26 2024 +0000 iio: gts: fix infinite loop for gain_to_scaletables() commit 7452f8a0814bb73f739ee0dab60f099f3361b151 upstream. In iio_gts_build_avail_time_table(), it is checked that gts->num_itime is non-zero, but gts->num_itime is not checked in gain_to_scaletables(). The variable time_idx is initialized as gts->num_itime - 1. This implies that time_idx might initially be set to -1 (0 - 1 = -1). Consequently, using while (time_idx--) could lead to an infinite loop. 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/20241031014626.2313077-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e5cac32721997cb8bcb208a29f4598b3faf46338 Author: Nuno Sa Date: Tue Oct 29 13:46:37 2024 +0000 iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer commit 3a4187ec454e19903fd15f6e1825a4b84e59a4cd upstream. The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode(). Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928") Cc: stable@vger.kernel.org Signed-off-by: Nuno Sa Signed-off-by: Zicheng Qu Link: https://patch.msgid.link/20241029134637.2261336-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 98e1f03de842d0e8cd6c1171f40ce7ba998290bd Author: Zicheng Qu Date: Sat Nov 2 09:25:25 2024 +0000 iio: Fix fwnode_handle in __fwnode_iio_channel_get_by_name() commit 3993ca4add248f0f853f54f9273a7de850639f33 upstream. In the fwnode_iio_channel_get_by_name(), iterating over parent nodes to acquire IIO channels via fwnode_for_each_parent_node(). The variable chan was mistakenly attempted on the original node instead of the current parent node. This patch corrects the logic to ensure that __fwnode_iio_channel_get_by_name() is called with the correct parent node. Cc: stable@vger.kernel.org # v6.6+ Fixes: 1e64b9c5f9a0 ("iio: inkern: move to fwnode properties") Signed-off-by: Zicheng Qu Link: https://patch.msgid.link/20241102092525.2389952-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8e5e63d6ca95d234b70d5f3980f0efab1023af6e Author: Matti Vaittinen Date: Wed Oct 30 15:16:11 2024 +0200 iio: accel: kx022a: Fix raw read format commit b7d2bc99b3bdc03fff9b416dd830632346d83530 upstream. The KX022A provides the accelerometer data in two subsequent registers. The registers are laid out so that the value obtained via bulk-read of these registers can be interpreted as signed 16-bit little endian value. The read value is converted to cpu_endianes and stored into 32bit integer. The le16_to_cpu() casts value to unsigned 16-bit value, and when this is assigned to 32-bit integer the resulting value will always be positive. This has not been a problem to users (at least not all users) of the sysfs interface, who know the data format based on the scan info and who have converted the read value back to 16-bit signed value. This isn't compliant with the ABI however. This, however, will be a problem for those who use the in-kernel interfaces, especially the iio_read_channel_processed_scale(). The iio_read_channel_processed_scale() performs multiplications to the returned (always positive) raw value, which will cause strange results when the data from the sensor has been negative. Fix the read_raw format by casting the result of the le_to_cpu() to signed 16-bit value before assigning it to the integer. This will make the negative readings to be correctly reported as negative. This fix will be visible to users by changing values returned via sysfs to appear in correct (negative) format. Reported-by: Kalle Niemi Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer") Signed-off-by: Matti Vaittinen Tested-by: Kalle Niemi Cc: Link: https://patch.msgid.link/ZyIxm_zamZfIGrnB@mva-rohm Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 37dfc81266d3a32294524bfadd3396614f8633ee Author: Yang Erkun Date: Tue Nov 5 19:03:14 2024 +0800 nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur commit 98100e88dd8865999dc6379a3356cd799795fe7b upstream. The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server. NFS CLIENT thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_task While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered. NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive ======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() ----------------------------------------------------------------------- Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 slab_err+0xb0/0xf0 __kmem_cache_shutdown+0x15c/0x310 kmem_cache_destroy+0x66/0x160 nfsd_file_cache_shutdown+0xac/0x210 [nfsd] nfsd_destroy_serv+0x251/0x2a0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1ae/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Disabling lock debugging due to kernel taint Object 0xff11000110e2ac38 @offset=3128 Allocated in nfsd_file_do_acquire+0x20f/0xa30 [nfsd] age=1635 cpu=3 pid=800 nfsd_file_do_acquire+0x20f/0xa30 [nfsd] nfsd_file_acquire_opened+0x5f/0x90 [nfsd] nfs4_get_vfs_file+0x4c9/0x570 [nfsd] nfsd4_process_open2+0x713/0x1070 [nfsd] nfsd4_open+0x74b/0x8b0 [nfsd] nfsd4_proc_compound+0x70b/0xc20 [nfsd] nfsd_dispatch+0x1b4/0x3a0 [nfsd] svc_process_common+0x5b8/0xc50 [sunrpc] svc_process+0x2ab/0x3b0 [sunrpc] svc_handle_xprt+0x681/0xa20 [sunrpc] nfsd+0x183/0x220 [nfsd] kthread+0x199/0x1e0 ret_from_fork+0x31/0x60 ret_from_fork_asm+0x1a/0x30 Add nfs4_openowner_unhashed to help found unhashed nfs4_openowner, and break nfsd4_open process to fix this problem. Cc: stable@vger.kernel.org # v5.4+ Reviewed-by: Jeff Layton Signed-off-by: Yang Erkun Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 1cecfdbc6bfc89c516d286884c7f29267b95de2b Author: Yang Erkun Date: Mon Oct 21 22:23:41 2024 +0800 nfsd: make sure exp active before svc_export_show commit be8f982c369c965faffa198b46060f8853e0f1f0 upstream. The function `e_show` was called with protection from RCU. This only ensures that `exp` will not be freed. Therefore, the reference count for `exp` can drop to zero, which will trigger a refcount use-after-free warning when `exp_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `exp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 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: e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: bf18f163e89c ("NFSD: Using exp_get for export getting") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Yang Erkun Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 2eb355346c5a2d767dfb21b3d1c4ea2d56cedb63 Author: Damien Le Moal Date: Thu Oct 17 10:58:36 2024 +0900 PCI: rockchip-ep: Fix address translation unit programming commit 64f093c4d99d797b68b407a9d8767aadc3e3ea7a upstream. The Rockchip PCIe endpoint controller handles PCIe transfers addresses by masking the lower bits of the programmed PCI address and using the same number of lower bits masked from the CPU address space used for the mapping. For a PCI mapping of bytes starting from , the number of bits masked is the number of address bits changing in the address range [pci_addr..pci_addr + size - 1]. However, rockchip_pcie_prog_ep_ob_atu() calculates num_pass_bits only using the size of the mapping, resulting in an incorrect number of mask bits depending on the value of the PCI address to map. Fix this by introducing the helper function rockchip_pcie_ep_ob_atu_num_bits() to correctly calculate the number of mask bits to use to program the address translation unit. The number of mask bits is calculated depending on both the PCI address and size of the mapping, and clamped between 8 and 20 using the macros ROCKCHIP_PCIE_AT_MIN_NUM_BITS and ROCKCHIP_PCIE_AT_MAX_NUM_BITS. As defined in the Rockchip RK3399 TRM V1.3 Part2, Sections 17.5.5.1.1 and 17.6.8.2.1, this clamping is necessary because: 1) The lower 8 bits of the PCI address to be mapped by the outbound region are ignored. So a minimum of 8 address bits are needed and imply that the PCI address must be aligned to 256. 2) The outbound memory regions are 1MB in size. So while we can specify up to 63-bits for the PCI address (num_bits filed uses bits 0 to 5 of the outbound address region 0 register), we must limit the number of valid address bits to 20 to match the memory window maximum size (1 << 20 = 1MB). Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe controller") Link: https://lore.kernel.org/r/20241017015849.190271-2-dlemoal@kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8b404b08be92abc33c50f78813470740fc5adca4 Author: Andrea della Porta Date: Fri Nov 8 10:42:56 2024 +0100 PCI: of_property: Assign PCI instead of CPU bus address to dynamic PCI nodes commit 5e316d34b53039346e252d0019e2f4167af2c0ef upstream. When populating "ranges" property for a PCI bridge or endpoint, of_pci_prop_ranges() incorrectly uses the CPU address of the resource. In such PCI nodes, the window should instead be in PCI address space. Call pci_bus_address() on the resource in order to obtain the PCI bus address. [Previous discussion at: https://lore.kernel.org/all/8b4fa91380fc4754ea80f47330c613e4f6b6592c.1724159867.git.andrea.porta@suse.com/] Link: https://lore.kernel.org/r/20241108094256.28933-1-andrea.porta@suse.com Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Tested-by: Herve Codina Signed-off-by: Andrea della Porta Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 6f433923d3b641b9e45d380c3c49b0db9e4fb1a2 Author: Yuan Can Date: Wed Nov 6 09:03:12 2024 +0800 dm thin: Add missing destroy_work_on_stack() commit e74fa2447bf9ed03d085b6d91f0256cc1b53f1a8 upstream. This commit add missed destroy_work_on_stack() operations for pw->worker in pool_work_wait(). Fixes: e7a3e871d895 ("dm thin: cleanup noflush_work to use a proper completion") Cc: stable@vger.kernel.org Signed-off-by: Yuan Can Signed-off-by: Mikulas Patocka Signed-off-by: Greg Kroah-Hartman commit fad9d2a966009f9eabac528685191628e75f1db1 Author: Ssuhung Yeh Date: Thu Oct 31 18:25:59 2024 +0800 dm: Fix typo in error message commit 2deb70d3e66d538404d9e71bff236e6d260da66e upstream. Remove the redundant "i" at the beginning of the error message. This "i" came from commit 1c1318866928 ("dm: prefer '"%s...", __func__'"), the "i" is accidentally left. Signed-off-by: Ssuhung Yeh Signed-off-by: Mikulas Patocka Fixes: 1c1318866928 ("dm: prefer '"%s...", __func__'") Cc: stable@vger.kernel.org # v6.3+ Signed-off-by: Greg Kroah-Hartman commit c5f4540ae66ed39fb7eafbc1b22bfdafa3e830de Author: Oleksandr Tymoshenko Date: Wed Oct 30 00:28:55 2024 +0000 ovl: properly handle large files in ovl_security_fileattr commit 3b6b99ef15ea37635604992ede9ebcccef38a239 upstream. dentry_open in ovl_security_fileattr fails for any file larger than 2GB if open method of the underlying filesystem calls generic_file_open (e.g. fusefs). The issue can be reproduce using the following script: (passthrough_ll is an example app from libfuse). $ D=/opt/test/mnt $ mkdir -p ${D}/{source,base,top/uppr,top/work,ovlfs} $ dd if=/dev/zero of=${D}/source/zero.bin bs=1G count=2 $ passthrough_ll -o source=${D}/source ${D}/base $ mount -t overlay overlay \ -olowerdir=${D}/base,upperdir=${D}/top/uppr,workdir=${D}/top/work \ ${D}/ovlfs $ chmod 0777 ${D}/mnt/ovlfs/zero.bin Running this script results in "Value too large for defined data type" error message from chmod. Signed-off-by: Oleksandr Tymoshenko Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit 4a44bcb73a0ba4b4f46b6e89a7755aaaaeb041b1 Author: Javier Carrasco Date: Fri Sep 27 01:20:52 2024 +0200 leds: flash: mt6360: Fix device_for_each_child_node() refcounting in error paths commit 73b03b27736e440e3009fe1319cbc82d2cd1290c upstream. The device_for_each_child_node() macro requires explicit calls to fwnode_handle_put() upon early exits to avoid memory leaks, and in this case the error paths are handled after jumping to 'out_flash_realease', which misses that required call to to decrement the refcount of the child node. A more elegant and robust solution is using the scoped variant of the loop, which automatically handles such early exits. Fix the child node refcounting in the error paths by using device_for_each_child_node_scoped(). Cc: stable@vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-1-95c0614b38c8@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 5294e8abd46cc1acbd03b00ce97e3034f67c08bc Author: Srinivas Pandruvada Date: Thu Nov 14 12:02:13 2024 -0800 thermal: int3400: Fix reading of current_uuid for active policy commit 7082503622986537f57bdb5ef23e69e70cfad881 upstream. When the current_uuid attribute is set to the active policy UUID, reading back the same attribute is returning "INVALID" instead of the active policy UUID on some platforms before Ice Lake. In platforms before Ice Lake, firmware provides a list of supported thermal policies. In this case, user space can select any of the supported thermal policies via a write to attribute "current_uuid". In commit c7ff29763989 ("thermal: int340x: Update OS policy capability handshake")', the OS policy handshake was updated to support Ice Lake and later platforms and it treated priv->current_uuid_index=0 as invalid. However, priv->current_uuid_index=0 is for the active policy, only priv->current_uuid_index=-1 is invalid. Fix this issue by updating the priv->current_uuid_index check. Fixes: c7ff29763989 ("thermal: int340x: Update OS policy capability handshake") Signed-off-by: Srinivas Pandruvada Cc: 5.18+ # 5.18+ Link: https://patch.msgid.link/20241114200213.422303-1-srinivas.pandruvada@linux.intel.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6868deee4a6bb8d324e883e2f540aaa33499a0f9 Author: Jiri Olsa Date: Fri Nov 22 00:11:18 2024 +0100 fs/proc/kcore.c: Clear ret value in read_kcore_iter after successful iov_iter_zero commit 088f294609d8f8816dc316681aef2eb61982e0da upstream. If iov_iter_zero succeeds after failed copy_from_kernel_nofault, we need to reset the ret value to zero otherwise it will be returned as final return value of read_kcore_iter. This fixes objdump -d dump over /proc/kcore for me. Cc: stable@vger.kernel.org Cc: Alexander Gordeev Fixes: 3d5854d75e31 ("fs/proc/kcore.c: allow translation of physical memory addresses") Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20241121231118.3212000-1-jolsa@kernel.org Acked-by: Alexander Gordeev Signed-off-by: Christian Brauner Signed-off-by: Greg Kroah-Hartman commit b50b631d8fceb9221e3b1dde51efc35e9cd52a94 Author: Zijun Hu Date: Thu Nov 7 08:53:09 2024 +0800 PCI: endpoint: Clear secondary (not primary) EPC in pci_epc_remove_epf() commit 688d2eb4c6fcfdcdaed0592f9df9196573ff5ce2 upstream. In addition to a primary endpoint controller, an endpoint function may be associated with a secondary endpoint controller, epf->sec_epc, to provide NTB (non-transparent bridge) functionality. Previously, pci_epc_remove_epf() incorrectly cleared epf->epc instead of epf->sec_epc when removing from the secondary endpoint controller. Extend the epc->list_lock coverage and clear either epf->epc or epf->sec_epc as indicated. Link: https://lore.kernel.org/r/20241107-epc_rfc-v2-2-da5b6a99a66f@quicinc.com Fixes: 63840ff53223 ("PCI: endpoint: Add support to associate secondary EPC with EPF") Signed-off-by: Zijun Hu Reviewed-by: Manivannan Sadhasivam [mani: reworded subject and description] Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2bf49d724c9e4d0a68790f5b00a6beb4ab657734 Author: Kishon Vijay Abraham I Date: Fri May 24 16:27:14 2024 +0530 PCI: keystone: Add link up check to ks_pcie_other_map_bus() commit 9e9ec8d8692a6f64d81ef67d4fb6255af6be684b upstream. K2G forwards the error triggered by a link-down state (e.g., no connected endpoint device) on the system bus for PCI configuration transactions; these errors are reported as an SError at system level, which is fatal and hangs the system. So, apply fix similar to how it was done in the DesignWare Core driver commit 15b23906347c ("PCI: dwc: Add link up check in dw_child_pcie_ops.map_bus()"). Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") Link: https://lore.kernel.org/r/20240524105714.191642-3-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Siddharth Vadapalli [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 344134ac9190f29b0f0b8da7aea727876876015f Author: Kishon Vijay Abraham I Date: Fri May 24 16:27:13 2024 +0530 PCI: keystone: Set mode as Root Complex for "ti,keystone-pcie" compatible commit 5a938ed9481b0c06cb97aec45e722a80568256fd upstream. commit 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") introduced configuring "enum dw_pcie_device_mode" as part of device data ("struct ks_pcie_of_data"). However it failed to set the mode for "ti,keystone-pcie" compatible. Since the mode defaults to "DW_PCIE_UNKNOWN_TYPE", the following error message is displayed for the v3.65a controller: "INVALID device type 0" Despite the driver probing successfully, the controller may not be functional in the Root Complex mode of operation. So, set the mode as Root Complex for "ti,keystone-pcie" compatible to fix this. Fixes: 23284ad677a9 ("PCI: keystone: Add support for PCIe EP in AM654x Platforms") Link: https://lore.kernel.org/r/20240524105714.191642-2-s-vadapalli@ti.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Siddharth Vadapalli [kwilczynski: commit log, added tag for stable releases] Signed-off-by: Krzysztof Wilczyński Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ce30d11b39e8d637fed4704a5b43e9d556990475 Author: Frank Li Date: Tue Oct 1 12:26:08 2024 -0400 i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() commit 3082990592f7c6d7510a9133afa46e31bbe26533 upstream. if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr". Cc: stable@kernel.org Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit 0a0dc4834f664eb36ba76fdb8b0ca719dfe1b18f Author: Jinjie Ruan Date: Mon Sep 30 17:19:13 2024 +0800 i3c: master: svc: Fix pm_runtime_set_suspended() with runtime pm enabled commit 18599e93e4e814ce146186026c6abf83c14d5798 upstream. It is not valid to call pm_runtime_set_suspended() for devices with runtime PM enabled because it returns -EAGAIN if it is enabled already and working. So, call pm_runtime_disable() before to fix it. Cc: stable@vger.kernel.org # v5.17 Fixes: 05be23ef78f7 ("i3c: master: svc: add runtime pm support") Reviewed-by: Frank Li Reviewed-by: Miquel Raynal Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/r/20240930091913.2545510-1-ruanjinjie@huawei.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit cdcc26d714c96e9de75c549f05d770b3ddaf2d21 Author: Peter Griffin Date: Thu Oct 31 15:00:31 2024 +0000 scsi: ufs: exynos: Fix hibern8 notify callbacks commit ceef938bbf8b93ba3a218b4adc244cde94b582aa upstream. v1 of the patch which introduced the ufshcd_vops_hibern8_notify() callback used a bool instead of an enum. In v2 this was updated to an enum based on the review feedback in [1]. ufs-exynos hibernate calls have always been broken upstream as it follows the v1 bool implementation. Link: https://patchwork.kernel.org/project/linux-scsi/patch/001f01d23994$719997c0$54ccc740$@samsung.com/ [1] Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20241031150033.3440894-13-peter.griffin@linaro.org Cc: stable@vger.kernel.org Reviewed-by: Tudor Ambarus Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6caff31c3d189bfd73dedb801b4d793bc2b66547 Author: Alexandru Ardelean Date: Tue Nov 5 16:54:05 2024 +0200 util_macros.h: fix/rework find_closest() macros commit bc73b4186736341ab5cd2c199da82db6e1134e13 upstream. A bug was found in the find_closest() (find_closest_descending() is also affected after some testing), where for certain values with small progressions, the rounding (done by averaging 2 values) causes an incorrect index to be returned. The rounding issues occur for progressions of 1, 2 and 3. It goes away when the progression/interval between two values is 4 or larger. It's particularly bad for progressions of 1. For example if there's an array of 'a = { 1, 2, 3 }', using 'find_closest(2, a ...)' would return 0 (the index of '1'), rather than returning 1 (the index of '2'). This means that for exact values (with a progression of 1), find_closest() will misbehave and return the index of the value smaller than the one we're searching for. For progressions of 2 and 3, the exact values are obtained correctly; but values aren't approximated correctly (as one would expect). Starting with progressions of 4, all seems to be good (one gets what one would expect). While one could argue that 'find_closest()' should not be used for arrays with progressions of 1 (i.e. '{1, 2, 3, ...}', the macro should still behave correctly. The bug was found while testing the 'drivers/iio/adc/ad7606.c', specifically the oversampling feature. For reference, the oversampling values are listed as: static const unsigned int ad7606_oversampling_avail[7] = { 1, 2, 4, 8, 16, 32, 64, }; When doing: 1. $ echo 1 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio 1 # this is fine 2. $ echo 2 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio 1 # this is wrong; 2 should be returned here 3. $ echo 3 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio 2 # this is fine 4. $ echo 4 > /sys/bus/iio/devices/iio\:device0/oversampling_ratio $ cat /sys/bus/iio/devices/iio\:device0/oversampling_ratio 4 # this is fine And from here-on, the values are as correct (one gets what one would expect.) While writing a kunit test for this bug, a peculiar issue was found for the array in the 'drivers/hwmon/ina2xx.c' & 'drivers/iio/adc/ina2xx-adc.c' drivers. While running the kunit test (for 'ina226_avg_tab' from these drivers): * idx = find_closest([-1 to 2], ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab)); This returns idx == 0, so value. * idx = find_closest(3, ina226_avg_tab, ARRAY_SIZE(ina226_avg_tab)); This returns idx == 0, value 1; and now one could argue whether 3 is closer to 4 or to 1. This quirk only appears for value '3' in this array, but it seems to be a another rounding issue. * And from 4 onwards the 'find_closest'() works fine (one gets what one would expect). This change reworks the find_closest() macros to also check the difference between the left and right elements when 'x'. If the distance to the right is smaller (than the distance to the left), the index is incremented by 1. This also makes redundant the need for using the DIV_ROUND_CLOSEST() macro. In order to accommodate for any mix of negative + positive values, the internal variables '__fc_x', '__fc_mid_x', '__fc_left' & '__fc_right' are forced to 'long' type. This also addresses any potential bugs/issues with 'x' being of an unsigned type. In those situations any comparison between signed & unsigned would be promoted to a comparison between 2 unsigned numbers; this is especially annoying when '__fc_left' & '__fc_right' underflow. The find_closest_descending() macro was also reworked and duplicated from the find_closest(), and it is being iterated in reverse. The main reason for this is to get the same indices as 'find_closest()' (but in reverse). The comparison for '__fc_right < __fc_left' favors going the array in ascending order. For example for array '{ 1024, 512, 256, 128, 64, 16, 4, 1 }' and x = 3, we get: __fc_mid_x = 2 __fc_left = -1 __fc_right = -2 Then '__fc_right < __fc_left' evaluates to true and '__fc_i++' becomes 7 which is not quite incorrect, but 3 is closer to 4 than to 1. This change has been validated with the kunit from the next patch. Link: https://lkml.kernel.org/r/20241105145406.554365-1-aardelean@baylibre.com Fixes: 95d119528b0b ("util_macros.h: add find_closest() macro") Signed-off-by: Alexandru Ardelean Cc: Bartosz Golaszewski Cc: Greg Kroah-Hartman Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 308e0cc36dc409718db0bf55e57c9867367183c4 Author: Patrick Donnelly Date: Sat Oct 12 20:54:11 2024 -0400 ceph: extract entity name from device id commit 955710afcb3bb63e21e186451ed5eba85fa14d0b upstream. Previously, the "name" in the new device syntax "@." was ignored because (presumably) tests were done using mount.ceph which also passed the entity name using "-o name=foo". If mounting is done without the mount.ceph helper, the new device id syntax fails to set the name properly. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/68516 Signed-off-by: Patrick Donnelly Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 33a213c04faff6c3a7fe77e947db81bc7270fe32 Author: yuan.gao Date: Fri Oct 18 14:44:35 2024 +0800 mm/slub: Avoid list corruption when removing a slab from the full list commit dbc16915279a548a204154368da23d402c141c81 upstream. Boot with slub_debug=UFPZ. If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list. When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected). So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation. Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine. [ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.414158] ? do_error_trap+0x6a/0x90 [ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.415915] ? exc_invalid_op+0x4c/0x60 [ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.417675] ? asm_exc_invalid_op+0x16/0x20 [ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.420410] free_to_partial_list+0x515/0x5e0 [ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] [ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs] [ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs] [ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs] [ 4277.428567] xfs_inactive+0x22d/0x290 [xfs] [ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.430479] process_one_work+0x171/0x340 [ 4277.431227] worker_thread+0x277/0x390 [ 4277.431962] ? __pfx_worker_thread+0x10/0x10 [ 4277.432752] kthread+0xf0/0x120 [ 4277.433382] ? __pfx_kthread+0x10/0x10 [ 4277.434134] ret_from_fork+0x2d/0x50 [ 4277.434837] ? __pfx_kthread+0x10/0x10 [ 4277.435566] ret_from_fork_asm+0x1b/0x30 [ 4277.436280] Fixes: 643b113849d8 ("slub: enable tracking of full slabs") Suggested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Suggested-by: Vlastimil Babka Cc: Signed-off-by: yuan.gao Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Acked-by: Christoph Lameter Signed-off-by: Vlastimil Babka Signed-off-by: Greg Kroah-Hartman commit 2c932d5c7aac987b2c74e47fff94a9fd10ce2fc5 Author: Linus Walleij Date: Wed Oct 23 13:05:34 2024 +0100 ARM: 9431/1: mm: Pair atomic_set_release() with _read_acquire() commit 93ee385254d53849c01dd8ab9bc9d02790ee7f0e upstream. The code for syncing vmalloc memory PGD pointers is using atomic_read() in pair with atomic_set_release() but the proper pairing is atomic_read_acquire() paired with atomic_set_release(). This is done to clearly instruct the compiler to not reorder the memcpy() or similar calls inside the section so that we do not observe changes to init_mm. memcpy() calls should be identified by the compiler as having unpredictable side effects, but let's try to be on the safe side. Cc: stable@vger.kernel.org Fixes: d31e23aff011 ("ARM: mm: make vmalloc_seq handling SMP safe") Suggested-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit ef21187c0672a2b2cbec44f33bab9ec47d5c277c Author: Linus Walleij Date: Wed Oct 23 13:04:44 2024 +0100 ARM: 9430/1: entry: Do a dummy read from VMAP shadow commit 44e9a3bb76e5f2eecd374c8176b2c5163c8bb2e2 upstream. When switching task, in addition to a dummy read from the new VMAP stack, also do a dummy read from the VMAP stack's corresponding KASAN shadow memory to sync things up in the new MM context. Cc: stable@vger.kernel.org Fixes: a1c510d0adc6 ("ARM: implement support for vmap'ed stacks") Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/ Reported-by: Clement LE GOFFIC Suggested-by: Ard Biesheuvel Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 1af22528fee8072b7adc007b8ca49cc4ea62689e Author: Vasily Gorbik Date: Tue Nov 19 14:54:07 2024 +0100 s390/entry: Mark IRQ entries to fix stack depot warnings commit 45c9f2b856a075a34873d00788d2e8a250c1effd upstream. The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing. IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies. Cc: stable@vger.kernel.org # 5.15+ Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 1359fd9eae29490c542e17c107cb41cfb8463138 Author: Linus Walleij Date: Wed Oct 23 13:03:14 2024 +0100 ARM: 9429/1: ioremap: Sync PGDs for VMALLOC shadow commit d6e6a74d4cea853b5321eeabb69c611148eedefe upstream. When sync:ing the VMALLOC area to other CPUs, make sure to also sync the KASAN shadow memory for the VMALLOC area, so that we don't get stale entries for the shadow memory in the top level PGD. Since we are now copying PGDs in two instances, create a helper function named memcpy_pgd() to do the actual copying, and create a helper to map the addresses of VMALLOC_START and VMALLOC_END into the corresponding shadow memory. Co-developed-by: Melon Liu Cc: stable@vger.kernel.org Fixes: 565cbaad83d8 ("ARM: 9202/1: kasan: support CONFIG_KASAN_VMALLOC") Link: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db6d@foss.st.com/ Reported-by: Clement LE GOFFIC Suggested-by: Mark Rutland Suggested-by: Russell King (Oracle) Acked-by: Mark Rutland Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 7e3a8ea3d1ada7f707de5d9d504774b4191eab66 Author: Zicheng Qu Date: Mon Oct 28 14:20:27 2024 +0000 ad7780: fix division by zero in ad7780_write_raw() commit c174b53e95adf2eece2afc56cd9798374919f99a upstream. In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info's write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero. Fixes: 9085daa4abcc ("staging: iio: ad7780: add gain & filter gpio support") Cc: stable@vger.kernel.org Signed-off-by: Zicheng Qu Link: https://patch.msgid.link/20241028142027.1032332-1-quzicheng@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8bca39b958f16bfb8a2eaae88c21cae193fed476 Author: Gabor Juhos Date: Tue Oct 22 11:45:56 2024 +0200 clk: qcom: gcc-qcs404: fix initial rate of GPLL3 commit 36d202241d234fa4ac50743510d098ad52bd193a upstream. The comment before the config of the GPLL3 PLL says that the PLL should run at 930 MHz. In contrary to this, calculating the frequency from the current configuration values by using 19.2 MHz as input frequency defined in 'qcs404.dtsi', it gives 921.6 MHz: $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x0 $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l 921600000.00000000000000000000 Set 'alpha_hi' in the configuration to a value used in downstream kernels [1][2] in order to get the correct output rate: $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x70 $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l 930000000.00000000000000000000 The change is based on static code analysis, compile tested only. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/kernel.lnx.5.4.r56-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L335 [2} https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r49-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L127 Cc: stable@vger.kernel.org Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404") Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/r/20241022-fix-gcc-qcs404-gpll3-v1-1-c4d30d634d19@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 6aa39a78128a2291aa0dc9fb174817c0c0106e53 Author: Michal Vokáč Date: Thu Oct 17 17:08:12 2024 +0200 leds: lp55xx: Remove redundant test for invalid channel number commit 09b1ef9813a0742674f7efe26104403ca94a1b4a upstream. Since commit 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") there are two subsequent tests if the chan_nr (reg property) is in valid range. One in the lp55xx_init_led() function and one in the lp55xx_parse_common_child() function that was added with the mentioned commit. There are two issues with that. First is in the lp55xx_parse_common_child() function where the reg property is tested right after it is read from the device tree. Test for the upper range is not correct though. Valid reg values are 0 to (max_channel - 1) so it should be >=. Second issue is that in case the parsed value is out of the range the probe just fails and no error message is shown as the code never reaches the second test that prints and error message. Remove the test form lp55xx_parse_common_child() function completely and keep the one in lp55xx_init_led() function to deal with it. Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx") Cc: stable@vger.kernel.org Signed-off-by: Michal Vokáč Link: https://lore.kernel.org/r/20241017150812.3563629-1-michal.vokac@ysoft.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 3723d1c056d04408acfe13403596b9c5832d364f Author: Mostafa Saleh Date: Thu Oct 24 16:25:15 2024 +0000 iommu/io-pgtable-arm: Fix stage-2 map/unmap for concatenated tables commit d71fa842d33c48ac2809ae11d2379b5a788792cb upstream. ARM_LPAE_LVL_IDX() takes into account concatenated PGDs and can return an index spanning multiple page-table pages given a sufficiently large input address. However, when the resulting index is used to calculate the number of remaining entries in the page, the possibility of concatenation is ignored and we end up computing a negative upper bound: max_entries = ARM_LPAE_PTES_PER_TABLE(data) - map_idx_start; On the map path, this results in a negative 'mapped' value being returned but on the unmap path we can leak child tables if they are skipped in __arm_lpae_free_pgtable(). Introduce an arm_lpae_max_entries() helper to convert a table index into the remaining number of entries within a single page-table page. Cc: Signed-off-by: Mostafa Saleh Link: https://lore.kernel.org/r/20241024162516.2005652-2-smostafa@google.com [will: Tweaked comment and commit message] Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9a8b989d8958f1771d79c351df9f082184e3c46f Author: Sergey Senozhatsky Date: Tue Oct 29 00:36:14 2024 +0900 zram: clear IDLE flag after recompression commit f85219096648b251a81e9fe24a1974590cfc417d upstream. Patch series "zram: IDLE flag handling fixes", v2. zram can wrongly preserve ZRAM_IDLE flag on its entries which can result in premature post-processing (writeback and recompression) of such entries. This patch (of 2) Recompression should clear ZRAM_IDLE flag on the entries it has accessed, because otherwise some entries, specifically those for which recompression has failed, become immediate candidate entries for another post-processing (e.g. writeback). Consider the following case: - recompression marks entries IDLE every 4 hours and attempts to recompress them - some entries are incompressible, so we keep them intact and hence preserve IDLE flag - writeback marks entries IDLE every 8 hours and writebacks IDLE entries, however we have IDLE entries left from recompression, so writeback prematurely writebacks those entries. The bug was reported by Shin Kawamura. Link: https://lkml.kernel.org/r/20241028153629.1479791-1-senozhatsky@chromium.org Link: https://lkml.kernel.org/r/20241028153629.1479791-2-senozhatsky@chromium.org Fixes: 84b33bf78889 ("zram: introduce recompress sysfs knob") Signed-off-by: Sergey Senozhatsky Reported-by: Shin Kawamura Acked-by: Brian Geffon Cc: Minchan Kim Signed-off-by: Andrew Morton Cc: Signed-off-by: Greg Kroah-Hartman commit f8cca70b0e5741b4014cfd11e4346b271267f784 Author: MengEn Sun Date: Fri Nov 1 12:06:38 2024 +0800 vmstat: call fold_vm_zone_numa_events() before show per zone NUMA event commit 2ea80b039b9af0b71c00378523b71c254fb99c23 upstream. Since 5.14-rc1, NUMA events will only be folded from per-CPU statistics to per zone and global statistics when the user actually needs it. Currently, the kernel has performs the fold operation when reading /proc/vmstat, but does not perform the fold operation in /proc/zoneinfo. This can lead to inaccuracies in the following statistics in zoneinfo: - numa_hit - numa_miss - numa_foreign - numa_interleave - numa_local - numa_other Therefore, before printing per-zone vm_numa_event when reading /proc/zoneinfo, we should also perform the fold operation. Link: https://lkml.kernel.org/r/1730433998-10461-1-git-send-email-mengensun@tencent.com Fixes: f19298b9516c ("mm/vmstat: convert NUMA statistics to basic NUMA counters") Signed-off-by: MengEn Sun Reviewed-by: JinLiang Zheng Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 8a92dc4df89c50bdb26667419ea70e0abbce456e Author: guoweikang Date: Wed Nov 20 13:27:49 2024 +0800 ftrace: Fix regression with module command in stack_trace_filter commit 45af52e7d3b8560f21d139b3759735eead8b1653 upstream. When executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Link: https://lore.kernel.org/20241120052750.275463-1-guoweikang.kernel@gmail.com Fixes: 04ec7bb642b77 ("tracing: Have the trace_array hold the list of registered func probes"); Signed-off-by: guoweikang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 6e290ee989dd4b353f10ef89d30a29708c51c765 Author: Wei Yang Date: Thu Oct 31 23:16:26 2024 +0000 maple_tree: refine mas_store_root() on storing NULL commit 0ea120b278ad7f7cfeeb606e150ad04b192df60b upstream. Currently, when storing NULL on mas_store_root(), the behavior could be improved. Storing NULLs over the entire tree may result in a node being used to store a single range. Further stores of NULL may cause the node and tree to be corrupt and cause incorrect behaviour. Fixing the store to the root null fixes the issue by ensuring that a range of 0 - ULONG_MAX results in an empty tree. Users of the tree may experience incorrect values returned if the tree was expanded to store values, then overwritten by all NULLS, then continued to store NULLs over the empty area. For example possible cases are: * store NULL at any range result a new node * store NULL at range [m, n] where m > 0 to a single entry tree result a new node with range [m, n] set to NULL * store NULL at range [m, n] where m > 0 to an empty tree result consecutive NULL slot * it allows for multiple NULL entries by expanding root to store NULLs to an empty tree This patch tries to improve in: * memory efficient by setting to empty tree instead of using a node * remove the possibility of consecutive NULL slot which will prohibit extended null in later operation Link: https://lkml.kernel.org/r/20241031231627.14316-5-richard.weiyang@gmail.com Fixes: 54a611b60590 ("Maple Tree: add new data structure") Signed-off-by: Wei Yang Reviewed-by: Liam R. Howlett Cc: Liam R. Howlett Cc: Sidhartha Kumar Cc: Lorenzo Stoakes Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 065bf5dd21639f80e68450de16bda829784dbb8c Author: Vasiliy Kovalev Date: Tue Nov 19 18:58:17 2024 +0300 ovl: Filter invalid inodes with missing lookup function commit c8b359dddb418c60df1a69beea01d1b3322bfe83 upstream. Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. Reported-by: syzbot+a8c9d476508bd14a90e5@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=a8c9d476508bd14a90e5 Suggested-by: Miklos Szeredi Link: https://lore.kernel.org/linux-unionfs/CAJfpegvx-oS9XGuwpJx=Xe28_jzWx5eRo1y900_ZzWY+=gGzUg@mail.gmail.com/ Signed-off-by: Vasiliy Kovalev Cc: Signed-off-by: Amir Goldstein Signed-off-by: Greg Kroah-Hartman commit b11813bc2f4eee92695075148c9ba996f54feeba Author: Thadeu Lima de Souza Cascardo Date: Fri Sep 13 15:06:01 2024 -0300 media: uvcvideo: Require entities to have a non-zero unique ID commit 3dd075fe8ebbc6fcbf998f81a75b8c4b159a6195 upstream. Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dynamic_id+0x1b/0x70 [ 21.057811] ? find_held_lock+0x33/0xa0 [ 21.058047] ? usb_match_dynamic_id+0x55/0x70 [ 21.058330] ? lock_release+0x124/0x260 [ 21.058657] ? usb_match_one_id_intf+0xa2/0x100 [ 21.058997] usb_probe_interface+0x1ba/0x330 [ 21.059399] really_probe+0x1ba/0x4c0 [ 21.059662] __driver_probe_device+0xb2/0x180 [ 21.059944] driver_probe_device+0x5a/0x100 [ 21.060170] __device_attach_driver+0xe9/0x160 [ 21.060427] ? __pfx___device_attach_driver+0x10/0x10 [ 21.060872] bus_for_each_drv+0xa9/0x100 [ 21.061312] __device_attach+0xed/0x190 [ 21.061812] device_initial_probe+0xe/0x20 [ 21.062229] bus_probe_device+0x4d/0xd0 [ 21.062590] device_add+0x308/0x590 [ 21.062912] usb_set_configuration+0x7b6/0xaf0 [ 21.063403] usb_generic_driver_probe+0x36/0x80 [ 21.063714] usb_probe_device+0x7b/0x130 [ 21.063936] really_probe+0x1ba/0x4c0 [ 21.064111] __driver_probe_device+0xb2/0x180 [ 21.064577] driver_probe_device+0x5a/0x100 [ 21.065019] __device_attach_driver+0xe9/0x160 [ 21.065403] ? __pfx___device_attach_driver+0x10/0x10 [ 21.065820] bus_for_each_drv+0xa9/0x100 [ 21.066094] __device_attach+0xed/0x190 [ 21.066535] device_initial_probe+0xe/0x20 [ 21.066992] bus_probe_device+0x4d/0xd0 [ 21.067250] device_add+0x308/0x590 [ 21.067501] usb_new_device+0x347/0x610 [ 21.067817] hub_event+0x156b/0x1e30 [ 21.068060] ? process_scheduled_works+0x48b/0xaf0 [ 21.068337] process_scheduled_works+0x5a3/0xaf0 [ 21.068668] worker_thread+0x3cf/0x560 [ 21.068932] ? kthread+0x109/0x1b0 [ 21.069133] kthread+0x197/0x1b0 [ 21.069343] ? __pfx_worker_thread+0x10/0x10 [ 21.069598] ? __pfx_kthread+0x10/0x10 [ 21.069908] ret_from_fork+0x32/0x40 [ 21.070169] ? __pfx_kthread+0x10/0x10 [ 21.070424] ret_from_fork_asm+0x1a/0x30 [ 21.070737] Cc: stable@vger.kernel.org Reported-by: syzbot+0584f746fde3d52b4675@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0584f746fde3d52b4675 Reported-by: syzbot+dd320d114deb3f5bb79b@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=dd320d114deb3f5bb79b Fixes: a3fbc2e6bb05 ("media: mc-entity.c: use WARN_ON, validate link pads") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Ricardo Ribalda Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20240913180601.1400596-2-cascardo@igalia.com Signed-off-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit f83f6a6e126376da4a14c3c0cfad9574522ad37e Author: Ricardo Ribalda Date: Thu Sep 26 05:59:06 2024 +0000 media: uvcvideo: Stop stream during unregister commit c9ec6f1736363b2b2bb4e266997389740f628441 upstream. uvc_unregister_video() can be called asynchronously from uvc_disconnect(). If the device is still streaming when that happens, a plethora of race conditions can occur. Make sure that the device has stopped streaming before exiting this function. If the user still holds handles to the driver's file descriptors, any ioctl will return -ENODEV from the v4l2 core. This change makes uvc more consistent with the rest of the v4l2 drivers using the vb2_fop_* and vb2_ioctl_* helpers. This driver (and many other usb drivers) always had this problem, but it wasn't possible to easily fix this until the vb2_video_unregister_device() helper was added. So the Fixes tag points to the creation of that helper. Reviewed-by: Hans Verkuil Suggested-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Reviewed-by: Mauro Carvalho Chehab Fixes: f729ef5796d8 ("media: videobuf2-v4l2.c: add vb2_video_unregister_device helper function") Cc: stable@vger.kernel.org # 5.10.x [hverkuil: add note regarding Fixes version] Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 6712a28a4f923ffdf51cff267ad05a634ee1babc Author: Gaosheng Cui Date: Wed Oct 9 16:28:02 2024 +0800 media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal() commit 0f514068fbc5d4d189c817adc7c4e32cffdc2e47 upstream. The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegro_alloc_buffer fails. Fixes: f20387dfd065 ("media: allegro: add Allegro DVT video IP core driver") Cc: Signed-off-by: Gaosheng Cui Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 2dbb2307e19dc38e6c5cde1825bbeb998d1a9509 Author: Jinjie Ruan Date: Mon Oct 28 16:02:56 2024 +0800 media: gspca: ov534-ov772x: Fix off-by-one error in set_frame_rate() commit d2842dec577900031826dc44e9bf0c66416d7173 upstream. In set_frame_rate(), select a rate in rate_0 or rate_1 by checking sd->frame_rate >= r->fps in a loop, but the loop condition terminates when the index reaches zero, which fails to check the last elememt in rate_0 or rate_1. Check for >= 0 so that the last one in rate_0 or rate_1 is also checked. Fixes: 189d92af707e ("V4L/DVB (13422): gspca - ov534: ov772x changes from Richard Kaswy.") Cc: stable@vger.kernel.org Signed-off-by: Jinjie Ruan Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 047178d650bc60cfd9a793584685ed751c400f42 Author: Jinjie Ruan Date: Fri Nov 1 17:40:50 2024 +0800 media: venus: Fix pm_runtime_set_suspended() with runtime pm enabled commit 2a20869f7d798aa2b69e45b863eaf1b1ecf98278 upstream. It is not valid to call pm_runtime_set_suspended() for devices with runtime PM enabled because it returns -EAGAIN if it is enabled already and working. So, call pm_runtime_disable() before to fix it. Cc: stable@vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Jinjie Ruan Reviewed-by: Bryan O'Donoghue Acked-by: Stanimir Varbanov Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 3806bec2d4700c71ee0630b58b21e4f0f7993bfe Author: Jinjie Ruan Date: Fri Nov 1 17:40:49 2024 +0800 media: amphion: Fix pm_runtime_set_suspended() with runtime pm enabled commit 316e74500d1c6589cba28cebe2864a0bceeb2396 upstream. It is not valid to call pm_runtime_set_suspended() for devices with runtime PM enabled because it returns -EAGAIN if it is enabled already and working. So, call pm_runtime_disable() before to fix it. Cc: stable@vger.kernel.org Fixes: b50a64fc54af ("media: amphion: add amphion vpu device driver") Signed-off-by: Jinjie Ruan Reviewed-by: Bryan O'Donoghue Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit d173aee5709bd0994d216d60589ec67f8b11376a Author: Ard Biesheuvel Date: Sun Oct 13 15:19:04 2024 +0200 efi/libstub: Free correct pointer on failure commit 06d39d79cbd5a91a33707951ebf2512d0e759847 upstream. cmdline_ptr is an out parameter, which is not allocated by the function itself, and likely points into the caller's stack. cmdline refers to the pool allocation that should be freed when cleaning up after a failure, so pass this instead to free_pool(). Fixes: 42c8ea3dca09 ("efi: libstub: Factor out EFI stub entrypoint ...") Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 5262cbf40264a22ea96b0123a963c654a30f1f15 Author: Joe Hattori Date: Mon Nov 4 19:01:19 2024 +0900 media: platform: exynos4-is: Fix an OF node reference leak in fimc_md_is_isp_available commit 8964eb23408243ae0016d1f8473c76f64ff25d20 upstream. In fimc_md_is_isp_available(), of_get_child_by_name() is called to check if FIMC-IS is available. Current code does not decrement the refcount of the returned device node, which causes an OF node reference leak. Fix it by calling of_node_put() at the end of the variable scope. Signed-off-by: Joe Hattori Fixes: e781bbe3fecf ("[media] exynos4-is: Add fimc-is subdevs registration") Cc: stable@vger.kernel.org Reviewed-by: Krzysztof Kozlowski Signed-off-by: Hans Verkuil [hverkuil: added CC to stable] Signed-off-by: Greg Kroah-Hartman commit a2ed3b780f34e4a6403064208bc2c99d1ed85026 Author: Li Zetao Date: Thu Oct 10 23:41:13 2024 +0800 media: ts2020: fix null-ptr-deref in ts2020_probe() commit 4a058b34b52ed3feb1f3ff6fd26aefeeeed20cba upstream. KASAN reported a null-ptr-deref issue when executing the following command: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed. Solve this problem by adding checks to platform data. Fixes: dc245a5f9b51 ("[media] ts2020: implement I2C client bindings") Cc: Signed-off-by: Li Zetao Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 9ca2c2ad6ffa287e5d2f89ee358dedc547820f84 Author: Benjamin Gaignard Date: Tue Sep 10 14:10:09 2024 +0000 media: verisilicon: av1: Fix reference video buffer pointer assignment commit 672f24ed6ebcd986688c6674a6d994a265fefc25 upstream. Always get new destination buffer for reference frame because nothing garantees the one set previously is still valid or unused. Fixes this chromium test suite: https://chromium.googlesource.com/chromium/src/media/+/refs/heads/main/test/data/test-25fps.av1.ivf Fixes: 727a400686a2 ("media: verisilicon: Add Rockchip AV1 decoder") Cc: Signed-off-by: Benjamin Gaignard Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil [hverkuil: fix typo and add link to chromium test suite] Signed-off-by: Greg Kroah-Hartman commit b7a830bbc25da0f641e3ef2bac3b1766b2777a8b Author: Ming Qian Date: Fri Sep 13 15:22:54 2024 +0900 media: imx-jpeg: Ensure power suppliers be suspended before detach them commit fd0af4cd35da0eb550ef682b71cda70a4e36f6b9 upstream. The power suppliers are always requested to suspend asynchronously, dev_pm_domain_detach() requires the caller to ensure proper synchronization of this function with power management callbacks. otherwise the detach may led to kernel panic, like below: [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 1457.116777] Mem abort info: [ 1457.119589] ESR = 0x0000000096000004 [ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits [ 1457.128692] SET = 0, FnV = 0 [ 1457.131764] EA = 0, S1PTW = 0 [ 1457.134920] FSC = 0x04: level 0 translation fault [ 1457.139812] Data abort info: [ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000 [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000 [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec] [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66 [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT) [ 1457.199236] Workqueue: pm pm_runtime_work [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290 [ 1457.214886] lr : __rpm_callback+0x48/0x1d8 [ 1457.218968] sp : ffff80008250bc50 [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000 [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240 [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008 [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674 [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002 [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0 [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000 [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000 [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000 [ 1457.293510] Call trace: [ 1457.295946] genpd_runtime_suspend+0x20/0x290 [ 1457.300296] __rpm_callback+0x48/0x1d8 [ 1457.304038] rpm_callback+0x6c/0x78 [ 1457.307515] rpm_suspend+0x10c/0x570 [ 1457.311077] pm_runtime_work+0xc4/0xc8 [ 1457.314813] process_one_work+0x138/0x248 [ 1457.318816] worker_thread+0x320/0x438 [ 1457.322552] kthread+0x110/0x114 [ 1457.325767] ret_from_fork+0x10/0x20 Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: Signed-off-by: Ming Qian Reviewed-by: TaoJiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit b59ab89bc83f7bff67f78c6caf484a84a6dd30f7 Author: Alexander Shiyan Date: Wed Oct 9 09:05:44 2024 +0300 media: i2c: tc358743: Fix crash in the probe error path when using polling commit 869f38ae07f7df829da4951c3d1f7a2be09c2e9a upstream. If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __run_timers+0x244/0x268 lr : __run_timers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace:  __run_timers+0x244/0x268  timer_expire_remote+0x50/0x68  tmigr_handle_remote+0x388/0x39c  run_timer_softirq+0x38/0x44  handle_softirqs+0x138/0x298  __do_softirq+0x14/0x20  ____do_softirq+0x10/0x1c  call_on_irq_stack+0x24/0x4c  do_softirq_own_stack+0x1c/0x2c  irq_exit_rcu+0x9c/0xcc  el1_interrupt+0x48/0xc0  el1h_64_irq_handler+0x18/0x24  el1h_64_irq+0x7c/0x80  default_idle_call+0x34/0x68  do_idle+0x23c/0x294  cpu_startup_entry+0x38/0x3c  secondary_start_kernel+0x128/0x160  __secondary_switched+0xb8/0xbc ---[ end trace 0000000000000000 ]--- Fixes: 4e66a52a2e4c ("[media] tc358743: Add support for platforms without IRQ line") Signed-off-by: Alexander Shiyan Cc: stable@vger.kernel.org Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 76ef98f9131e511d59877b4a712ea1da7993655f Author: Francesco Dolcini Date: Thu Oct 24 15:06:51 2024 +0200 arm64: dts: freescale: imx8mp-verdin: Fix SD regulator startup delay commit 6c5789c9d2c06968532243daa235f6ff809ad71e upstream. The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 55aebcbcfc0a0be7bcc79b1e9027ea8f8ccca733 Author: Jinjie Ruan Date: Fri Nov 1 17:40:48 2024 +0800 media: i2c: dw9768: Fix pm_runtime_set_suspended() with runtime pm enabled commit d6594d50761728d09f23238cf9c368bab6260ef3 upstream. It is not valid to call pm_runtime_set_suspended() and pm_runtime_set_active() for devices with runtime PM enabled because it returns -EAGAIN if it is enabled already and working. So, adjust the order to fix it. Cc: stable@vger.kernel.org Fixes: 5f9a089b6de3 ("dw9768: Enable low-power probe on ACPI") Suggested-by: Sakari Ailus Signed-off-by: Jinjie Ruan Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 0ba08c21c6a92e6512e73644555120427c9a49d4 Author: Guoqing Jiang Date: Thu Sep 12 10:48:01 2024 +0800 media: mtk-jpeg: Fix null-ptr-deref during unload module commit 17af2b39daf12870cac61ffc360e62bc35798afb upstream. The workqueue should be destroyed in mtk_jpeg_core.c since commit 09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise the below calltrace can be easily triggered. [ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023 [ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] ... [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17 ... [ 677.882838] pc : destroy_workqueue+0x3c/0x770 [ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.884314] sp : ffff80008ad974f0 [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070 [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690 [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000 [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0 [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10 [ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d [ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90 [ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001 [ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000 [ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118 [ 677.893977] Call trace: [ 677.894297] destroy_workqueue+0x3c/0x770 [ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw] [ 677.895677] devm_action_release+0x50/0x90 [ 677.896211] release_nodes+0xe8/0x170 [ 677.896688] devres_release_all+0xf8/0x178 [ 677.897219] device_unbind_cleanup+0x24/0x170 [ 677.897785] device_release_driver_internal+0x35c/0x480 [ 677.898461] device_release_driver+0x20/0x38 ... [ 677.912665] ---[ end trace 0000000000000000 ]--- Fixes: 09aea13ecf6f ("media: mtk-jpeg: refactor some variables") Cc: Signed-off-by: Guoqing Jiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 68efeff2f7fccdfedc55f92e92be32997127d16e Author: Ming Qian Date: Fri Sep 13 15:21:44 2024 +0900 media: imx-jpeg: Set video drvdata before register video device commit d2b7ecc26bd5406d5ba927be1748aa99c568696c upstream. The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Cc: Signed-off-by: Ming Qian Reviewed-by: TaoJiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 988cc10ddbdee0369fe1f193d389da38ad760492 Author: Ming Qian Date: Fri Sep 13 15:21:45 2024 +0900 media: amphion: Set video drvdata before register video device commit 8cbb1a7bd5973b57898b26eb804fe44af440bb63 upstream. The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops. Fixes: 3cd084519c6f ("media: amphion: add vpu v4l2 m2m support") Cc: Signed-off-by: Ming Qian Reviewed-by: TaoJiang Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman commit 71a15258f3c92eb1c4ae98bbfca9459f4723d5d3 Author: Francesco Dolcini Date: Thu Oct 24 15:06:28 2024 +0200 arm64: dts: ti: k3-am62-verdin: Fix SD regulator startup delay commit 2213ca51998fef61d3df4ca156054cdcc37c42b8 upstream. The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 316b80246b16 ("arm64: dts: ti: add verdin am62") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Link: https://lore.kernel.org/r/20241024130628.49650-1-francesco@dolcini.it Signed-off-by: Vignesh Raghavendra Signed-off-by: Greg Kroah-Hartman commit 7477b16f8031a0ec96a6c90cff45dfa221d79cd8 Author: Francesco Dolcini Date: Thu Oct 24 15:06:50 2024 +0200 arm64: dts: freescale: imx8mm-verdin: Fix SD regulator startup delay commit 0ca7699c376743b633b6419a42888dba386d5351 upstream. The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 14635785805f002ad9f0204ace9e86ba201d1906 Author: Dragan Simic Date: Thu Sep 19 21:15:26 2024 +0200 arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer commit 2496b2aaacf137250f4ca449f465e2cadaabb0e8 upstream. The way InvenSense MPU-6050 accelerometer is mounted on the user-facing side of the Pine64 PinePhone mainboard, which makes it rotated 90 degrees counter- clockwise, [1] requires the accelerometer's x- and y-axis to be swapped, and the direction of the accelerometer's y-axis to be inverted. Rectify this by adding a mount-matrix to the accelerometer definition in the Pine64 PinePhone dtsi file. [1] https://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20placement%20v1.1%2020191031.pdf Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone") Cc: stable@vger.kernel.org Suggested-by: Ondrej Jirman Suggested-by: Andrey Skvortsov Signed-off-by: Dragan Simic Reviewed-by: Andrey Skvortsov Link: https://patch.msgid.link/129f0c754d071cca1db5d207d9d4a7bd9831dff7.1726773282.git.dsimic@manjaro.org [wens@csie.org: Replaced Helped-by with Suggested-by] Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 7897f1f8b785371e423f80a87f57298bcb1da0a5 Author: Yuan Can Date: Tue Nov 5 21:01:05 2024 +0800 md/md-bitmap: Add missing destroy_work_on_stack() commit 6012169e8aae9c0eda38bbedcd7a1540a81220ae upstream. This commit add missed destroy_work_on_stack() operations for unplug_work.work in bitmap_unplug_async(). Fixes: a022325ab970 ("md/md-bitmap: add a new helper to unplug bitmap asynchrously") Cc: stable@vger.kernel.org Signed-off-by: Yuan Can Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20241105130105.127336-1-yuancan@huawei.com Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 4275ac2741941c9c7c2293619fdbacb9f70ba85b Author: Filipe Manana Date: Fri Nov 15 11:29:21 2024 +0000 btrfs: ref-verify: fix use-after-free after invalid ref action [ Upstream commit 7c4e39f9d2af4abaf82ca0e315d1fd340456620f ] At btrfs_ref_tree_mod() after we successfully inserted the new ref entry (local variable 'ref') into the respective block entry's rbtree (local variable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF, we error out and free the ref entry without removing it from the block entry's rbtree. Then in the error path of btrfs_ref_tree_mod() we call btrfs_free_ref_cache(), which iterates over all block entries and then calls free_block_entry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn't remove it from the rbtree before freeing it in the error path at btrfs_ref_tree_mod(). Fix this by removing the new ref entry from the rbtree before freeing it. Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 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 BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 ================================================================== BUG: KASAN: slab-use-after-free in rb_first+0x69/0x70 lib/rbtree.c:473 Read of size 8 at addr ffff888042d1af38 by task syz.0.0/5329 CPU: 0 UID: 0 PID: 5329 Comm: syz.0.0 Not tainted 6.12.0-rc7-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rb_first+0x69/0x70 lib/rbtree.c:473 free_block_entry+0x78/0x230 fs/btrfs/ref-verify.c:248 btrfs_free_ref_cache+0xa3/0x100 fs/btrfs/ref-verify.c:917 btrfs_ref_tree_mod+0x139f/0x15e0 fs/btrfs/ref-verify.c:898 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/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:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f996df7e719 RSP: 002b:00007f996ede7038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f996e135f80 RCX: 00007f996df7e719 RDX: 0000000020000180 RSI: 00000000c4009420 RDI: 0000000000000004 RBP: 00007f996dff139e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f996e135f80 R15: 00007fff79f32e68 Allocated by task 5329: 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:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:257 [inline] __kmalloc_cache_noprof+0x19c/0x2c0 mm/slub.c:4295 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] btrfs_ref_tree_mod+0x264/0x15e0 fs/btrfs/ref-verify.c:701 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/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:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5329: 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 mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_hook mm/slub.c:2342 [inline] slab_free mm/slub.c:4579 [inline] kfree+0x1a0/0x440 mm/slub.c:4727 btrfs_ref_tree_mod+0x136c/0x15e0 btrfs_free_extent+0x33c/0x380 fs/btrfs/extent-tree.c:3544 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/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:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ffff888042d1af00 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 56 bytes inside of freed 64-byte region [ffff888042d1af00, ffff888042d1af40) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x42d1a anon flags: 0x4fff00000000000(node=1|zone=1|lastcpupid=0x7ff) page_type: f5(slab) raw: 04fff00000000000 ffff88801ac418c0 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000200020 00000001f5000000 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52c40(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 5055, tgid 5055 (dhcpcd-run-hook), ts 40377240074, free_ts 40376848335 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1541 prep_new_page mm/page_alloc.c:1549 [inline] get_page_from_freelist+0x3649/0x3790 mm/page_alloc.c:3459 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4735 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 alloc_slab_page+0x6a/0x140 mm/slub.c:2412 allocate_slab+0x5a/0x2f0 mm/slub.c:2578 new_slab mm/slub.c:2631 [inline] ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3818 __slab_alloc+0x58/0xa0 mm/slub.c:3908 __slab_alloc_node mm/slub.c:3961 [inline] slab_alloc_node mm/slub.c:4122 [inline] __do_kmalloc_node mm/slub.c:4263 [inline] __kmalloc_noprof+0x25a/0x400 mm/slub.c:4276 kmalloc_noprof include/linux/slab.h:882 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] tomoyo_encode2 security/tomoyo/realpath.c:45 [inline] tomoyo_encode+0x26f/0x540 security/tomoyo/realpath.c:80 tomoyo_realpath_from_path+0x59e/0x5e0 security/tomoyo/realpath.c:283 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_check_open_permission+0x255/0x500 security/tomoyo/file.c:771 security_file_open+0x777/0x990 security/security.c:3109 do_dentry_open+0x369/0x1460 fs/open.c:945 vfs_open+0x3e/0x330 fs/open.c:1088 do_open fs/namei.c:3774 [inline] path_openat+0x2c84/0x3590 fs/namei.c:3933 page last free pid 5055 tgid 5055 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1112 [inline] free_unref_page+0xcfb/0xf20 mm/page_alloc.c:2642 free_pipe_info+0x300/0x390 fs/pipe.c:860 put_pipe_info fs/pipe.c:719 [inline] pipe_release+0x245/0x320 fs/pipe.c:742 __fput+0x23f/0x880 fs/file_table.c:431 __do_sys_close fs/open.c:1567 [inline] __se_sys_close fs/open.c:1552 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1552 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 Memory state around the buggy address: ffff888042d1ae00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff888042d1ae80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc >ffff888042d1af00: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ffff888042d1af80: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ffff888042d1b000: 00 00 00 00 00 fc fc 00 00 00 00 00 fc fc 00 00 Reported-by: syzbot+7325f164162e200000c1@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/673723eb.050a0220.1324f8.00a8.GAE@google.com/T/#u Fixes: fd708b81d972 ("Btrfs: add a extent ref verify tool") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 757171d1369b3b47f36932d40a05a0715496dcab Author: Lizhi Xu Date: Fri Oct 25 12:55:53 2024 +0800 btrfs: add a sanity check for btrfs root in btrfs_search_slot() [ Upstream commit 3ed51857a50f530ac7a1482e069dfbd1298558d4 ] Syzbot reports a null-ptr-deref in btrfs_search_slot(). The reproducer is using rescue=ibadroots, and the extent tree root is corrupted thus the extent tree is NULL. When scrub tries to search the extent tree to gather the needed extent info, btrfs_search_slot() doesn't check if the target root is NULL or not, resulting the null-ptr-deref. Add sanity check for btrfs root before using it in btrfs_search_slot(). Reported-by: syzbot+3030e17bd57a73d39bd7@syzkaller.appspotmail.com Fixes: 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots") Link: https://syzkaller.appspot.com/bug?extid=3030e17bd57a73d39bd7 CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Qu Wenruo Tested-by: syzbot+3030e17bd57a73d39bd7@syzkaller.appspotmail.com Signed-off-by: Lizhi Xu Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 99f3cd5a866df54ee4f325af4ec44e72edfa3f98 Author: Filipe Manana Date: Fri Nov 15 15:46:13 2024 +0000 btrfs: don't loop for nowait writes when checking for cross references [ Upstream commit ed67f2a913a4f0fc505db29805c41dd07d3cb356 ] When checking for delayed refs when verifying if there are cross references for a data extent, we stop if the path has nowait set and we can't try lock the delayed ref head's mutex, returning -EAGAIN with the goal of making a write fallback to a blocking context. However we ignore the -EAGAIN at btrfs_cross_ref_exist() when check_delayed_ref() returns it, and keep looping instead of immediately returning the -EAGAIN to the caller. Fix this by not looping if we get -EAGAIN and we have a nowait path. Fixes: 26ce91144631 ("btrfs: make can_nocow_extent nowait compatible") CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit bcacb52a985f1b6d280f698a470b873dfe52728a Author: Ojaswin Mujoo Date: Thu Nov 21 18:08:54 2024 +0530 quota: flush quota_release_work upon quota writeback [ Upstream commit ac6f420291b3fee1113f21d612fa88b628afab5b ] One of the paths quota writeback is called from is: freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots() Since we currently don't always flush the quota_release_work queue in this path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0 Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE); Which ultimately results in generic/390 failing due to dmesg noise. This was detected on powerpc machine 15 cores. To avoid this, make sure to flush the workqueue during dquot_writeback_dquots() so we dont have any pending workitems after freeze. Reported-by: Disha Goel CC: stable@vger.kernel.org Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") Reviewed-by: Baokun Li Signed-off-by: Ojaswin Mujoo Signed-off-by: Jan Kara Link: https://patch.msgid.link/20241121123855.645335-2-ojaswin@linux.ibm.com Signed-off-by: Sasha Levin commit a2110964d5368b79af4bd3748c3774566a332019 Author: Long Li Date: Wed Nov 13 17:17:15 2024 +0800 xfs: remove unknown compat feature check in superblock write validation [ Upstream commit 652f03db897ba24f9c4b269e254ccc6cc01ff1b7 ] Compat features are new features that older kernels can safely ignore, allowing read-write mounts without issues. The current sb write validation implementation returns -EFSCORRUPTED for unknown compat features, preventing filesystem write operations and contradicting the feature's definition. Additionally, if the mounted image is unclean, the log recovery may need to write to the superblock. Returning an error for unknown compat features during sb write validation can cause mount failures. Although XFS currently does not use compat feature flags, this issue affects current kernels' ability to mount images that may use compat feature flags in the future. Since superblock read validation already warns about unknown compat features, it's unnecessary to repeat this warning during write validation. Therefore, the relevant code in write validation is being removed. Fixes: 9e037cb7972f ("xfs: check for unknown v5 feature bits in superblock write verifier") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Long Li Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin commit b8b84dcdf3ab1d414304819f824b10efba64132c 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 906cdbdd3b018ff69cc830173bce277a847d4fdc 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 0ca87e5063757132a044d35baba40a7d4bb25394 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 931be6b73830bc3d358fe8e896221a22f882fdf7 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 3811172e8c98ceebd12fe526ca6cb37a1263c964 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 065902117a5b07153f3d4fa5cc812331d380a5fe 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 5fab8abc2c276e3c05abcf34049cc94e3bd1a416 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 880a661e67648a3ffe85405e8de5f50650a3c0b2 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 fe44c5477284b762d95b029f813fae24d38f1df5 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 625e2357c8fcfae6e66dcc667dc656fe390bab15 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 0dd7a8b948fd8721ba5a7252888c22bc6cad3063 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 eda52d5ae82d6a308fd7ca05cba529cf752607a9 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 ab8c357dbf879ab91703b0ec292176664d5d6d4b Author: Masahiro Yamada Date: Sun Jul 7 01:05:06 2024 +0900 init/modpost: conditionally check section mismatch to __meminit* [ Upstream commit 73db3abdca58c8a014ec4c88cf5ef925cbf63669 ] This reverts commit eb8f689046b8 ("Use separate sections for __dev/ _cpu/__mem code/data"). Check section mismatch to __meminit* only when CONFIG_MEMORY_HOTPLUG=n. With this change, the linker script and modpost become simpler, and we can get rid of the __ref annotations from the memory hotplug code. [sfr@canb.auug.org.au: remove MEM_KEEP from arch/powerpc/kernel/vmlinux.lds.S] Link: https://lkml.kernel.org/r/20240710093213.2aefb25f@canb.auug.org.au Link: https://lkml.kernel.org/r/20240706160511.2331061-2-masahiroy@kernel.org Signed-off-by: Masahiro Yamada Signed-off-by: Stephen Rothwell Reviewed-by: Wei Yang Cc: Stephen Rothwell Signed-off-by: Andrew Morton Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit 52197a7c14df5597fefae3aeae590761679a6b6d Author: Masahiro Yamada Date: Mon Oct 23 02:06:13 2023 +0900 modpost: squash ALL_{INIT,EXIT}_TEXT_SECTIONS to ALL_TEXT_SECTIONS [ Upstream commit 34fcf231dcf94d7dea29c070228c4b93849f4850 ] ALL_INIT_TEXT_SECTIONS and ALL_EXIT_TEXT_SECTIONS are only used in the macro definition of ALL_TEXT_SECTIONS. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit 17f4332ae695dfdeb0c67b870bce113391f69c85 Author: Masahiro Yamada Date: Mon Oct 23 02:06:11 2023 +0900 modpost: use ALL_INIT_SECTIONS for the section check from DATA_SECTIONS [ Upstream commit e578e4e3110635b20786e442baa3aeff9bb65f95 ] ALL_INIT_SECTIONS is defined as follows: #define ALL_INIT_SECTIONS INIT_SECTIONS, ALL_XXXINIT_SECTIONS Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit db081efa9b8017b683230702a83e4b644a739a4d Author: Masahiro Yamada Date: Mon Oct 23 02:06:10 2023 +0900 modpost: disallow the combination of EXPORT_SYMBOL and __meminit* [ Upstream commit a3df1526da480c089c20868b7f4d486b9f266001 ] Theoretically, we could export conditionally-discarded code sections, such as .meminit*, if all the users can become modular under a certain condition. However, that would be difficult to control and such a tricky case has never occurred. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit a169a023e064be3f6662aeac4c623ea08e5b6b56 Author: Masahiro Yamada Date: Mon Oct 23 02:06:09 2023 +0900 modpost: remove EXIT_SECTIONS macro [ Upstream commit 48cd8df7afd1eef22cf7b125697a6d7c3d168c5c ] ALL_EXIT_SECTIONS and EXIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit 2462732f35f1f2c34fe1aca2749e36707f76c4b6 Author: Masahiro Yamada Date: Mon Oct 23 02:06:08 2023 +0900 modpost: remove MEM_INIT_SECTIONS macro [ Upstream commit 473a45bb35f080e31cb4fe45e905bfe3bd407fdf ] ALL_XXXINIT_SECTIONS and MEM_INIT_SECTIONS are the same. Remove the latter. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit 95da0b40fa8c4e15dafc5efe38d50c86ff822e5b Author: Masahiro Yamada Date: Mon Oct 23 02:06:06 2023 +0900 modpost: disallow *driver to reference .meminit* sections [ Upstream commit 50cccec15c48814765895891ca0d95d989b6a419 ] Drivers must not reference .meminit* sections, which are discarded when CONFIG_MEMORY_HOTPLUG=n. The reason for whitelisting "*driver" in the section mismatch check was to allow drivers to reference symbols annotated as __devinit or __devexit that existed in the past. Those annotations were removed by the following commits: - 54b956b90360 ("Remove __dev* markings from init.h") - 92e9e6d1f984 ("modpost.c: Stop checking __dev* section mismatches") Remove the stale whitelist. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit db5647420fb2ea756fae82c018871265ee0ba7a1 Author: Masahiro Yamada Date: Mon Oct 23 02:06:04 2023 +0900 modpost: remove ALL_EXIT_DATA_SECTIONS macro [ Upstream commit 3ada34b0f6559b2388f1983366614fbe8027b6fd ] This is unused. Signed-off-by: Masahiro Yamada Stable-dep-of: bb43a59944f4 ("Rename .data.unlikely to .data..unlikely") Signed-off-by: Sasha Levin commit 4151b8e1fca8c27d95af55203d0140f2218a7fc5 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 24891e0ebca53a09c41a7271d2ad85ef1fff8049 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 430afd3edabf942a908570e5a41414bb455f15f8 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 e061482601b4fbbbfac449d827fde7fb13debb4c 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 03a0e2520350fbd294a35634a4f4eee5ed0380ff 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 9890e6f2ec9264a5088993fdbc3ca0abc78d3a59 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 2bb3ee1bf237557daea1d58007d2e1d4a6502ccf 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 e978643c4c9c0aa69dcdcfd1644832d35ae63160 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 5da567d3f737a46faec49a343bd87b0a02583340 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 1e20e4ff3a75de214f5c593dba5eb1c913e94b5b 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 f0679539fad91bf9b7923bbe9afb0c717ef4f1e6 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 85b9f3e63e79a827e98b2cd2523a89776836a4e6 Author: Thomas Song Date: Tue Jun 25 08:26:05 2024 -0400 nvme-multipath: implement "queue-depth" iopolicy [ Upstream commit f227345f0a70f011647ae7ae12778bf258ff71f2 ] The round-robin path selector is inefficient in cases where there is a difference in latency between paths. In the presence of one or more high latency paths the round-robin selector continues to use the high latency path equally. This results in a bias towards the highest latency path and can cause a significant decrease in overall performance as IOs pile on the highest latency path. This problem is acute with NVMe-oF controllers. The queue-depth path selector sends I/O down the path with the lowest number of requests in its request queue. Paths with lower latency will clear requests more quickly and have less requests queued compared to higher latency paths. The goal of this path selector is to make more use of lower latency paths which will bring down overall IO latency and increase throughput and performance. Signed-off-by: Thomas Song [emilne: commandeered patch developed by Thomas Song @ Pure Storage] Co-developed-by: Ewan D. Milne Signed-off-by: Ewan D. Milne Co-developed-by: John Meneghini Signed-off-by: John Meneghini Link: https://lore.kernel.org/linux-nvme/20240509202929.831680-1-jmeneghi@redhat.com/ Tested-by: Marco Patalano Tested-by: Jyoti Rani Tested-by: John Meneghini Reviewed-by: Randy Jennings Reviewed-by: Hannes Reinecke Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Christoph Hellwig 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 a7071e2bd0fc5bb00d81b06ae1962c793e8d9655 Author: John Meneghini Date: Tue Jun 25 08:26:04 2024 -0400 nvme-multipath: prepare for "queue-depth" iopolicy [ Upstream commit 3d7c2fd2ea704812867f9586270a2516377482a3 ] This patch prepares for the introduction of a new iopolicy by breaking up the nvme_find_path() code path into sub-routines. Signed-off-by: John Meneghini Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni 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 18db8ae7abb556555856e46f0e9e96cc0e484582 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 011c3320e1fc44310530e39c4bce0584f564b834 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 01d3a2293d7e4edfff96618c15727db7e51f11b6 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 612824dd0c9465ef365ace38b056c663d110956d 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 074b310f059127ba884d10660feb2562cb8c3975 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 7e66d36871d19c3d68ab5c9fc3ce2453adccdc3c 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 dd4b1cbcc916fad5d10c2662b62def9f05e453d4 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 a990130f67706155f4df1fae327d67fb097fa53c 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 96fd3dfb1d14d3c366759957e78c672e09939e7f 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 229a30ed42bb87bcb044c5523fabd9e4f0e75648 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 e7b5a40b9b3878698f5c550e6413dd19113acda8 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 d3ca120303a73116ef5e8feba550d122d46898de 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 a875c023155ea92b75d6323977003e64d92ae7fc 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 acfaf37888e0f0732fb6a50ff093dce6d99994d0 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 dde654cad08fdaac370febb161ec41eb58e9d2a2 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 10209665b5bf199f8065b2e7d2b2dc6cdf227117 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 27d6e7eff07f8cce8e83b162d8f21a07458c860d 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 f7f33bb2dbafdbdd2b2c29550fe9c585d234140f 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 9e68fcffc764551e64f6ab28bd75d67a7f58f18f 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 1534f6f69393aac773465d80d31801b554352627 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 bb6bf24fe03bd77f126eea4745a4e0098ef62543 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 5906ee3693674d734177df13a519a21bb03f730d 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 73934e535cffbda1490fa97d82690a0f9aa73e94 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 791f833053578b9fd24252ebb7162a61bc3f805b 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 31fabf70d58388d5475e48ca8a6b7d2847b36678 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 921d90907eb978763e21b9e4ddd4b0ae6629e110 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 83cb4fb72d643f5130729f7e004b96c842a34866 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 edf5b298eb3650265e2f5cba873ab21b64fe8266 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 0e37c70bff7c8e2659d49d1d1bed8749444314fc 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 76e3de272587e701f1a4acd06c7cd856efaf2535 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 c917f415c18a01f620e4214f91842e5ff1503838 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 bc200027ee92fba84f1826494735ed675f3aa911 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 0357abf951c419bce9ea5c08ce16231bd927e82e 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 e9bf513718d0796bf4095b45871b3d4f7e79ee94 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 305c75f402e8d6e79e50c965f21bc1177d4d3bf0 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 378ce4e08ca2b1ac7bbf1d57b68643ca4226c5f8 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 c68dab1665325d00620d671a182a7edb1a538c97 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 68a69ed52a8ba5bcc0735b87f55aba4f7f75a5e0 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 e95080fba190ae5dea15b817b6a9afae70ac214c 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 679b1874eba71495aa1a32e3c7583bd4737145ef 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 fe0d9800ead6b0af3aa267fff435f698e50986bd 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 ad654c5bfe3e30a25d6e7524e7b1a93000677c9e 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 80f25003af2269af9d58fb2face5439d95368e4f 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 1681131bfa2322e08aba0236b315dcbdabcce41a 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 09faf32c682ea4a547200b8b9e04d8b3c8e84b55 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 8204dd589c4f25a7618eece5da3f0871e02af8ae 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 ad253966ee98667193be603039534db03a60e067 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 63ff22d706bb8bb9af0bb962fb81175eda062709 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 11af469040199e250f1cca25215caeb4a8748ba0 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 cdbd5a1dcdc2c27ac076f91b03b9add3fefa1a82 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 2d194d951895df214e066d08146e77cb6e02c1d4 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 5e1feafa7347593f85e11c0fdd9b5bfffb373fb4 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 de70a7e1f3d662563e5ba77336b351c5320c22d7 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 46f8e25926817272ec8d5bfbd003569bdeb9a8c8 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 a96f9eb7add30ba0fafcfe7b7aca090978196800 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 9665bbefab87d92840df3ae96a90f4e1bbe8efe8 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 185f065f458b79df8d52e8fbe5a4595f73c1b74f 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 4ca70a0630b08d2692c04756de1a3760435b9e3b 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 13dc02cae4e32715a72fccb3a38629ea4e5c77fd 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 66f0fbc8ba18d69d707d22b7f766b610a957c23b 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 856023ef032d824309abd5c747241dffa33aae8c 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 5691e457251bd868be7fa09b7271d97cb8b80042 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 d2543d75f81dc35c14902c29c7ebc7a841a4db43 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 671bf7530c08d6aff4a5706ac2175e565d50a4b4 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 32ffdd003f6f02e4ab91ee10586da83cc1fa889e 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 69c83ff5299c378d04b2085222af5e6d41832fef 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 81da9c0854545c3188ca2a09afe7cb65f9c012b5 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 8f3551f67991652c83469c7dd51d7b9b187b265f 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 223b546c6222d42147eff034433002ca5e2e7e09 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 ebefd0c746a21143561e803c73a7c16daa2b006a 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 ae0ef0d756d2c06f896f4aa2e22d7053768b4c26 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 5540869a3f75d75bff313b338570dcb10e0955e1 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: Jan Hendrik Farr Signed-off-by: Greg Kroah-Hartman commit 19714c9e8885b6580d0e226b07a98dd011b7f5ae 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 0d53178a3d8b916fefbb7a5f2ec33d30f968493e 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 7451f7297e74f2ece05fc89a2411c2b4756165bb 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 6a4645bc3b14e027cea1e8f5d0df02efa7fc23b3 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 ee68555b979e6add431ed7cb0f965b36cc309ebb 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 85cfe884668d7d81cae2f852cedd64c6d080118b 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 958275235d404c425f4991576585672127b09e6d 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 2a9b68f2dc6812bd1b8880b5c00e60203d6f61f6 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 9b07fb464eb69a752406e78e62ab3a60bfa7b00d 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 1b8868b818ecbbf70d883b18354c3c0b45466c35 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 e5d5c04aac71bf1476dc44b56f2206a4c2facca8 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 7484289822c5e705273c0a8c7fe611cea2a42583 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 2a4ec241dbe7390f2e35f4db36d1a050737ba5c2 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 dd2f9861f27571d47998d71e7516bf7216db0b52 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 718f1712e155389fa332972e99d74abf65f888e6 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 130abaa1da82fff6901e084e9fd841430d4c994e 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 26cd7f91f27f97fb64cf22ae80f96e4ff46cefb2 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 10c95568e7ac054e0488f1ebfc1814a338d6cdc6 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 d79f765b2eb8808d1c771f08e1a6000c06bf9f3e 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 046fb04cbce929ca52dbb0a16b5578f7c218facb 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 e68ca7dafecb96cf9606e38cb6b956369ad37464 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 a7fc8dce17e6fe0a846e5cb8ba1e38284f639ae7 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 30a2d503367bd61fc9b13bb1cb99558d95328a2d 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 9353cdf28d4c5c0ff19c5df7fbf81ea774de43a4 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 2bd7c60866410e4ddba4e8e735960b1c4eaa5063 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 786a552739bb4b16e342ad6c6161076617f27ddc 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 095694f58fe2f93f7520e5084241ad956ae2b4a2 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 bdae089f4b951f4d509d3f1566394ba8eaf0a851 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 acf693decaa39eb01448c00dcdf2f1beede9f4b0 Author: Chen-Yu Tsai Date: Mon Dec 2 16:15:50 2024 +0800 arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled [ Upstream commit 09d385679487c58f0859c1ad4f404ba3df2f8830 ] USB 3.0 on xhci1 is not used, as the controller shares the same PHY as pcie1. The latter is enabled to support the M.2 PCIe WLAN card on this design. Mark USB 3.0 as disabled on this controller using the "mediatek,u3p-dis-msk" property. Reported-by: Nícolas F. R. A. Prado #KernelCI Closes: https://lore.kernel.org/all/9fce9838-ef87-4d1b-b3df-63e1ddb0ec51@notapiano/ Fixes: b6267a396e1c ("arm64: dts: mediatek: cherry: Enable T-PHYs and USB XHCI controllers") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240731034411.371178-2-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit 387a4dc33bb73ae123dac7ca1f40140558e1ac79 Author: Chen-Yu Tsai Date: Mon Dec 2 16:15:49 2024 +0800 Revert "arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled" This reverts commit 090386dbedbc2f099c44a0136eb8eb8713930072. The hunk was applied to the wrong device node when the commit was backported to the 6.6 stable branch. Revert it to re-do the backport correctly. Reported-by: Koichiro Den Closes: https://lore.kernel.org/stable/6itvivhxbjlpky5hn6x2hmc3kzz4regcvmsk226t6ippjad7yk@26xug5lrdqdw/ Fixes: 090386dbedbc ("arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled") Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman commit b8f8b81dabe52b413fe9e062e8a852c48dd0680d 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 22d907bcd283d69d5e60497fc0d51969545c583b Author: Filipe Manana Date: Fri Jun 14 14:50:47 2024 +0100 btrfs: do not BUG_ON() when freeing tree block after error commit bb3868033a4cccff7be57e9145f2117cbdc91c11 upstream. When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block(). So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection. Reported-by: syzbot+a306f914b4d01b3958fe@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-btrfs/000000000000fcba1e05e998263c@google.com/ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba [ Resolve minor conflicts ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit b98777309756ebe15cc9ad4e8ab64bbfaf878a3f Author: Daejun Park Date: Thu Jul 4 10:01:21 2024 +0900 f2fs: fix null reference error when checking end of zone commit c82bc1ab2a8a5e73d9728e80c4c2ed87e8921a38 upstream. This patch fixes a potentially null pointer being accessed by is_end_zone_blkaddr() that checks the last block of a zone when f2fs is mounted as a single device. Fixes: e067dc3c6b9c ("f2fs: maintain six open zones for zoned devices") Signed-off-by: Daejun Park Reviewed-by: Chao Yu Reviewed-by: Daeho Jeong Signed-off-by: Jaegeuk Kim [ Resolve minor conflicts ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 475d99e611d53d4187a367683e9899d4802c67a0 Author: Kan Liang Date: Mon Jul 8 12:33:34 2024 -0700 perf/x86/intel: Hide Topdown metrics events if the feature is not enumerated commit 556a7c039a52c21da33eaae9269984a1ef59189b upstream. The below error is observed on Ice Lake VM. $ perf stat Error: The sys_perf_event_open() syscall returned with 22 (Invalid argument) for event (slots). /bin/dmesg | grep -i perf may provide additional information. In a virtualization env, the Topdown metrics and the slots event haven't been supported yet. The guest CPUID doesn't enumerate them. However, the current kernel unconditionally exposes the slots event and the Topdown metrics events to sysfs, which misleads the perf tool and triggers the error. Hide the perf-metrics topdown events and the slots event if the perf-metrics feature is not enumerated. The big core of a hybrid platform can also supports the perf-metrics feature. Fix the hybrid platform as well. Closes: https://lore.kernel.org/lkml/CAM9d7cj8z+ryyzUHR+P1Dcpot2jjW+Qcc4CPQpfafTXN=LEU0Q@mail.gmail.com/ Reported-by: Dongli Zhang Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Dongli Zhang Link: https://lkml.kernel.org/r/20240708193336.1192217-2-kan.liang@linux.intel.com Signed-off-by: Hagar Hemdan Signed-off-by: Greg Kroah-Hartman commit e4f3bb7d53b99d1d4d83bdd8bc807325e1012fb5 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 cd1e565a5b7fa60c349ca8a16db1e61715fe8230 Author: Hersen Wu Date: Mon Apr 22 12:27:34 2024 -0400 drm/amd/display: Add NULL pointer check for kzalloc commit 8e65a1b7118acf6af96449e1e66b7adbc9396912 upstream. [Why & How] Check return pointer of kzalloc before using it. Reviewed-by: Alex Hung Acked-by: Wayne Lin Signed-off-by: Hersen Wu Signed-off-by: Alex Deucher [ Resolve minor conflicts ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit d247af7c5dbf143ad6be8179bb1550e76d6af57e Author: Alex Hung Date: Thu Jun 20 20:23:41 2024 -0600 drm/amd/display: Check phantom_stream before it is used commit 3718a619a8c0a53152e76bb6769b6c414e1e83f4 upstream. dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity. Reviewed-by: Rodrigo Siqueira Signed-off-by: Jerry Zuo Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin [Xiangyu: BP to fix CVE: CVE-2024-49897, modified the source path] Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit 8c854138b593efbbd8fa46a25f3288c121c1d1a1 Author: Srinivasan Shanmugam Date: Wed Jul 31 13:09:28 2024 +0530 drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func commit 62ed6f0f198da04e884062264df308277628004f upstream. This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048. Cc: Tom Chung Cc: Rodrigo Siqueira Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Cc: Harry Wentland Cc: Hamza Mahfooz Signed-off-by: Srinivasan Shanmugam Reviewed-by: Tom Chung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit ebef6616219ff04abdeb39450625f85419787ee3 Author: Rodrigo Siqueira Date: Tue Jul 30 20:02:45 2024 -0600 drm/amd/display: Check null pointer before try to access it commit 1b686053c06ffb9f4524b288110cf2a831ff7a25 upstream. [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it. Reviewed-by: Alex Hung Signed-off-by: Rodrigo Siqueira Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher [Xiangyu: BP to fix CVE: CVE-2024-49906, modified the source path] Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit ec1be3c527b4a5fc85bcc1b0be7cec08bf60c796 Author: Srinivasan Shanmugam Date: Mon Jul 22 16:44:40 2024 +0530 drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw commit c395fd47d1565bd67671f45cca281b3acc2c31ef upstream. This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782) Cc: Tom Chung Cc: Rodrigo Siqueira Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Cc: Harry Wentland Cc: Hamza Mahfooz Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin [Xiangyu: BP to fix CVE: CVE-2024-49915, modified the source path] Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit 205e3b96cc9aa9211fd2c849a16245cf236b2d36 Author: Srinivasan Shanmugam Date: Mon Jul 22 16:21:19 2024 +0530 drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw commit cba7fec864172dadd953daefdd26e01742b71a6a upstream. This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628) Cc: Tom Chung Cc: Rodrigo Siqueira Cc: Roman Li Cc: Alex Hung Cc: Aurabindo Pillai Cc: Harry Wentland Cc: Hamza Mahfooz Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin [Xiangyu: BP to fix CVE: CVE-2024-49917, modified the source path] Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit f14fc623dd23fc0e1352bddc37d5b66a85dea8c0 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 ecb4aaa658da760fb83afd79cc5fd4360aa60635 Author: Kent Overstreet Date: Thu Jun 20 09:45:09 2024 -0400 closures: Change BUG_ON() to WARN_ON() commit 339b84ab6b1d66900c27bd999271cb2ae40ce812 upstream. If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s Signed-off-by: Kent Overstreet [ Resolve minor conflicts to fix CVE-2024-42252 ] Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 3347581bf9edc0f839b444ca365f9a3bd4803c6e 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 74cb86e1006c5437b1d90084d22018da30fddc77 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 804b96f8d0a02fa10b92f28b2e042f9128ed3ffc 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 7cd9f0a33e738cd58876f1bc8d6c1aa5bc4fc8c1 Author: lei lu Date: Mon Jun 3 17:46:08 2024 +0800 xfs: add bounds checking to xlog_recover_process_data commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream. There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header. Signed-off-by: lei lu Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Chandan Babu R Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit 6b42ded89ba80fadce626e97ee5e60b5e79d1832 Author: Puranjay Mohan Date: Thu Aug 29 13:32:17 2024 +0000 nvme: fix metadata handling in nvme-passthrough commit 7c2fd76048e95dd267055b5f5e0a48e6e7c81fd9 upstream. On an NVMe namespace that does not support metadata, it is possible to send an IO command with metadata through io-passthru. This allows issues like [1] to trigger in the completion code path. nvme_map_user_request() doesn't check if the namespace supports metadata before sending it forward. It also allows admin commands with metadata to be processed as it ignores metadata when bdev == NULL and may report success. Reject an IO command with metadata when the NVMe namespace doesn't support it and reject an admin command if it has metadata. [1] https://lore.kernel.org/all/mb61pcylvnym8.fsf@amazon.com/ Suggested-by: Christoph Hellwig Signed-off-by: Puranjay Mohan Reviewed-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Reviewed-by: Anuj Gupta Signed-off-by: Keith Busch [ Minor changes to make it work on 6.6 ] Signed-off-by: Hagar Hemdan Signed-off-by: Greg Kroah-Hartman commit 232a138bd843d48cb2368f604646d990db7640f3 Author: Justin Tee Date: Fri Jul 26 16:15:07 2024 -0700 scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths commit 2be1d4f11944cd6283cb97268b3e17c4424945ca upstream. When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20240726231512.92867-4-justintee8345@gmail.com Signed-off-by: Martin K. Petersen [Xiangyu: BP to fix CVE: CVE-2024-49891, no test_bit() conflict resolution] Signed-off-by: Xiangyu Chen Signed-off-by: Greg Kroah-Hartman commit d00df6700ad10974a7e20646956f4ff22cdbe0ec Author: Jason-JH.Lin Date: Thu Jul 18 22:17:04 2024 +0800 mailbox: mtk-cmdq: Move devm_mbox_controller_register() after devm_pm_runtime_enable() commit a8bd68e4329f9a0ad1b878733e0f80be6a971649 upstream. When mtk-cmdq unbinds, a WARN_ON message with condition pm_runtime_get_sync() < 0 occurs. According to the call tracei below: cmdq_mbox_shutdown mbox_free_channel mbox_controller_unregister __devm_mbox_controller_unregister ... The root cause can be deduced to be calling pm_runtime_get_sync() after calling pm_runtime_disable() as observed below: 1. CMDQ driver uses devm_mbox_controller_register() in cmdq_probe() to bind the cmdq device to the mbox_controller, so devm_mbox_controller_unregister() will automatically unregister the device bound to the mailbox controller when the device-managed resource is removed. That means devm_mbox_controller_unregister() and cmdq_mbox_shoutdown() will be called after cmdq_remove(). 2. CMDQ driver also uses devm_pm_runtime_enable() in cmdq_probe() after devm_mbox_controller_register(), so that devm_pm_runtime_disable() will be called after cmdq_remove(), but before devm_mbox_controller_unregister(). To fix this problem, cmdq_probe() needs to move devm_mbox_controller_register() after devm_pm_runtime_enable() to make devm_pm_runtime_disable() be called after devm_mbox_controller_unregister(). Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver") Signed-off-by: Jason-JH.Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jassi Brar Signed-off-by: Bin Lan Signed-off-by: Greg Kroah-Hartman commit a90cb059969bd47624fdfbea90b05b757b4045e9 Author: Xiuhong Wang 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 Signed-off-by: Zhiguo Niu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Cc: Daniel Rosenberg Signed-off-by: Greg Kroah-Hartman commit d7f0c4c95652a67122c3f0f2f30d669741f3a140 Author: Andreas Gruenbacher Date: Fri Apr 12 21:58:15 2024 +0200 gfs2: Remove and replace gfs2_glock_queue_work [ Upstream commit 1e86044402c45b70a9b31beeaefb5cc732a7470c ] There are no more callers of gfs2_glock_queue_work() left, so remove that helper. With that, we can now rename __gfs2_glock_queue_work() back to gfs2_glock_queue_work() to get rid of some unnecessary clutter. Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 6e92dd3ac2468363bfe1813880d27f86fa1fccb5 Author: Andreas Gruenbacher Date: Tue Apr 9 07:11:48 2024 +0200 gfs2: Don't set GLF_LOCK in gfs2_dispose_glock_lru [ Upstream commit 927cfc90d27cb7732a62464f95fd9aa7edfa9b70 ] In gfs2_dispose_glock_lru(), we want to skip glocks which are in the process of transitioning state (as indicated by the set GLF_LOCK flag), but we we don't need to set that flag for requesting a state transition. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 1e86044402c4 ("gfs2: Remove and replace gfs2_glock_queue_work") Signed-off-by: Sasha Levin commit 22185892fc222696e2fbfc83cb40e5cebc65994b 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 2c9a5607ecbab4b41e8b24eec5c1f6ff2a3b8a8f 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 020002c76147ecfdafe95c44abd3240e216b6316 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 756f30dc27ae8c5ee4b87cd66e026cfe5421725f 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 5e3a0f772d97a6d50163ad7694beec823c802d54 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 28f6a86a2f6613967e947dd116b20d3e8d97e23c 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 95070c084e201dbdfa7b9d9241621ff099e1cb25 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 789a72498d32f88d24371c10985aceb46397056c 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 4a92e10302422ce181a20797d552fba6b09e3b1a 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 5f7d46164af2f01bd8cb075eda17dd8d180eda42 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 ed4c8fc2e71d80b46159eb45a362aef191b0aa4b 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 ce833757ba75612fd925d2db4628ee10b1813e31 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 acfc4350dc2a421ced6a05b89dece445b5c50a37 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 67970b0cc76ba59825aebc0f0f15a4a5daae6f06 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 7051f66d81580e69b9b5db204d1480d5a2bf2188 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 8353a251accfb2fb5f71955ecdbf4a2fca90cacf 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 8e0e47f038bce2e788a21b1c3dd163429173ecb8 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 bba7909b511b93d04c4bbc4777cc775ac7a362a3 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 65ed89cad1f57034c256b016e89e8c0a4ec7c65b 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 265f1f22fddd5d36b2c8f38cb2420b541abe7557 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 9a62ca28d3f820aaf416b8efe05c1305048dba6a 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 5703fb1d85f653e35b327b14de4db7da239e4fd9 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 95f7a972194ad20696c36523b54c19a3567e0697 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 65e3a909bdaba705746edd04061c9df2599f9c09 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 85c37802d94f21d3a83d39f2aa2ceb2b1c038e8d 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 c48cfa53fe9659038b6c56467c9908f0e91024f2 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 fd7259c1bacc85e29b5ed7f245064d1bc81b774d 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 41535cb143428f172a6f148519a23012937ac175 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 fed89cfab1893d0cfd53cb5be766e02c5ff581f2 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 0bbba28d4b8cf7efe33e59f10a0e8c6138eee9f1 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 f002f21c1227a6056ae70e79df3e449a97ca16d4 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 92ada6df6ce71a3f7db3c8bee488c11d36554ef2 Author: Sai Krishna Date: Sun Mar 31 18:18:19 2024 +0530 octeontx2-pf: Reset MAC stats during probe [ Upstream commit 4c6ce450a8bb4bdf71959fd226414b079f0f0e02 ] Reset CGX/RPM MAC HW statistics at the time of driver probe() Signed-off-by: Hariprasad Kelam Signed-off-by: Sai Krishna Signed-off-by: David S. Miller Stable-dep-of: 07cd1eb166a3 ("octeontx2-af: RPM: fix stale RSFEC counters") Signed-off-by: Sasha Levin commit 3eda3da855daeb3519ac9fdc65418f2b8c533558 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 6030d66ac03a01d431b109fb096c58c6b5d78367 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 7501912e5a9f98a9810cd6cf6e019167beb52606 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 93ccc94dd713136bdac7cd915b41162dbec7010c 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 6aa2ede634ad7571df3d898c6693b45e33098e28 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 836deb96383ed9c1a411f172954d74b3f74ec6ac 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 42251c2d1ef1cb0822638bebb87ad9120c759673 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 f2a30e6fcd5abb9067d1059323574d18f27514e7 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 e3bb76fe22888bf101ae6a28510afbea8a5254b9 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 d0f06266562b92729ce3ad3c642f93397fbe29b1 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 bca2c418a597b13219c47f7b6c6194ded917e056 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 a422ebec863d99d5607fb41bb7af3347fcb436d3 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 3ea084dfc5a881fa77b94afb131e2c732bfff32a 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 8637f400b253b2e874af99d0f26709f6f7030245 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 7f395c87a8fe28dd0d8f1c8e3780c33b010b208b 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 348d7d07ef3bb4db5d824ee7878536c5edd8b462 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 0c8d50501bc13cacecc19caaddc10db372592a39 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 a639cea4de2975ac03b9ede78a364e408167760d 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 7ea2a3d4014275450a0e87c359e2ebb5da54a859 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 06f2fcf49854ad05a09d09e0dbee6544fff04695 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 1f7b85e5ffd814a111ff38c3e619c7bb8ffafd02 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 c2d6226bef9631d17bf6d0c2743cd973c46d9413 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 6c5ddc2b68f2500e957e77af87db96cd2667e247 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 40be5b4c0c1560d270c27e8cb10425fbb4a73d02 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 1dfc79bfc544ff66ab6a4401f3c45f996e2576b4 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 1c9a99c89e45b22eb556fd2f3f729f2683f247d5 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 bd8524148dd8c123334b066faa90590ba2ef8e6f 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 0284175435353ce9863a872a5034d25864fe2f01 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 eb51733ae5fc73d95bd857d5da26f9f65b202a79 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 242ee2b0ad9b23f47084904fce3f9f228068a1f9 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 2ffc58ec837e06963f283c8f27ff6dbca5ac69ed 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 ab897ca4d7bb30996fd4e8c44fdbd5fb1102a603 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 c437af60c4f1c73ed267a27aa4150759dbe5fc74 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 2f465476ff8b147857fbc0aa56925b33f38dde50 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 fad7be2395123cc9a36cbeb02fd7f13f4980eb9a 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 e3b4b95c2b8bc7cd29cbf744b70bca21694b8889 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 f38ab496c7c45ce594f092ab74a03d7644821d66 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 838dd342962cef4c320632a5af48d3c31f2f9877 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 022c3fc12850acdefaf5c4cf5badd8eff88c76c7 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 c178bcaccbfd3e55e8ba518477e9f2bc9bfe08af 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 ad8cf4a18d9945bc03536a568f03524c28cea04d 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 16784362b4bd40519f8ea8d8b2f8449d1b5e04e3 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 794fa8792d4eacac191f1cbcc2e81b7369e4662a 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 e466b89987d8de772791acb1eb0ebc392fe7042e 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 9621a3d5a4e0687705c1f61d015ca248db5ee00d 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 bea0c0e4013bd62b66200219e16a02095f63a4fd 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 0a289ca90225cea3ab59da30668ce8d8f95b7804 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 762de2993b773d0b66c53a6d25fe5eadd7227932 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 4231df767001b1ae9bdb567a93c30b0031963454 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 5261d258e31818036873af47b9a573fd8c594a15 Author: Matt Ranostay Date: Tue Nov 28 11:14:01 2023 +0530 PCI: j721e: Add PCIe 4x lane selection support [ Upstream commit 4490f559f75514d5a6f0e729e85235a7be6216bf ] Add support for setting of two-bit field that allows selection of 4x lane PCIe which was previously limited to only 2x lanes. Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-5-s-vadapalli@ti.com Signed-off-by: Matt Ranostay Signed-off-by: Achal Verma Signed-off-by: Siddharth Vadapalli Signed-off-by: Krzysztof Wilczyński Reviewed-by: Vignesh Raghavendra Reviewed-by: Roger Quadros Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit 7c3bf691097c7b583cbba59c659b3f00de1f72ad Author: Matt Ranostay Date: Tue Nov 28 11:14:00 2023 +0530 PCI: j721e: Add per platform maximum lane settings [ Upstream commit 3ac7f14084f54bff9c31573d1ed59d047a34fe03 ] Various platforms have different maximum amount of lanes that can be selected. Add max_lanes to struct j721e_pcie to allow for detection of this which is needed to calculate the needed bitmask size for the possible lane count. Link: https://lore.kernel.org/linux-pci/20231128054402.2155183-4-s-vadapalli@ti.com Signed-off-by: Matt Ranostay Signed-off-by: Achal Verma Signed-off-by: Siddharth Vadapalli Signed-off-by: Krzysztof Wilczyński Reviewed-by: Ravi Gunasekaran Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit 47203d68f52a4242abf694cafbf09c2199dec6be Author: Yoshihiro Shimoda Date: Wed Oct 18 17:56:17 2023 +0900 PCI: Add T_PVPERL macro [ Upstream commit 164f66be0c2523e65df41b755c41b7c9ff58035a ] According to the PCIe CEM r5.0, sec 2.9.2, Power stable to PERST# inactive interval is 100 ms as minimum. Add a macro so that the PCIe controller drivers can make use of it. Link: https://lore.kernel.org/linux-pci/20231018085631.1121289-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Yoshihiro Shimoda Signed-off-by: Krzysztof Wilczyński Reviewed-by: Manivannan Sadhasivam Reviewed-by: Serge Semin Stable-dep-of: 22a9120479a4 ("PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds") Signed-off-by: Sasha Levin commit ed16873faf6af40d6de83676d89723d85ff4aaaa 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 ecf4e6782b01fd578b565b3dd2be7bb0ac91082e 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 67f4c664601166dd7be4eb639f78ae28001653f3 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 f3d586b7ab628c9e1eca3123f5d53b4ae8711646 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 aac3361f6d22e6a85dcbd68ade16631bcb2d70dc 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 b6b896c2fd44accaec7612678316f8b1812121d8 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 f974480cf39935e15eeadd5f9143c798c4dfb314 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 b7c4121a4390ef840b03e214ce8b692888ac1404 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 cbc853c490c986156462b382f604fe489f3c4c72 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 2c6f6c3843df3c02dc314e728b490701028156af 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 f1b8bfe8d2f2fdf905d37c174d5bc1cd2b6910c5 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 6b0ed65c94c238f1885112d436a66e8984cd495e 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 9ac8d66362305642588c974b44a82d87c04d440e 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 0c4753453964cc5a416ec4a561ae9664e1bbc032 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 380bc5a698b907fc4dd54ba7f58fe090f17e5c54 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 035c6b7a13aca5b8c6ed604f40e8101a498ab8d2 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 8e098baf6bc3f3a6aefc383509aba07e202f7ee0 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 e30cab288c8d9bb505a15d0da74f5ffaca268992 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 8264963475caca5a9b27253f524f1cff89864d61 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 4389447f1b2a417fdfc5514702b9ce82ae95ac28 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 39822f7f496332a678da6204420309fae1750795 Author: Andreas Gruenbacher Date: Fri Mar 15 16:45:39 2024 +0100 gfs2: Replace gfs2_glock_queue_put with gfs2_glock_put_async [ Upstream commit ee2be7d7c7f32783f60ee5fe59b91548a4571f10 ] Function gfs2_glock_queue_put() puts a glock reference by enqueuing glock work instead of putting the reference directly. This ensures that the operation won't sleep, but it is costly and really only necessary when putting the final glock reference. Replace it with a new gfs2_glock_put_async() function that only queues glock work when putting the last glock reference. Signed-off-by: Andreas Gruenbacher Stable-dep-of: 7c6f714d8847 ("gfs2: Fix unlinked inode cleanup") Signed-off-by: Sasha Levin commit 67696fef78cf1217675c1e949576e82c8006dba4 Author: Andreas Gruenbacher Date: Fri Mar 15 16:56:09 2024 +0100 gfs2: Get rid of gfs2_glock_queue_put in signal_our_withdraw [ Upstream commit f80d882edcf242d0256d9e51b09d5fb7a3a0d3b4 ] In function signal_our_withdraw(), we are calling gfs2_glock_queue_put() in a context in which we are actually allowed to sleep, so replace that with a simple call to gfs2_glock_put(). Signed-off-by: Andreas Gruenbacher Stable-dep-of: 7c6f714d8847 ("gfs2: Fix unlinked inode cleanup") Signed-off-by: Sasha Levin commit 300b21886232096dbe613a578f7bad15c1f3e253 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 39e5f390c2c9d56bff7e5138c33e0e39c59147ff 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 ebe0f8dc243e46edc3645f7e286737277eea65f3 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 f65f4ad87797dff5809733b8229acc576347f156 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 0dffdb2e70f136b6c15a37c7c4a14ca125afffe5 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 118aa7cacaa5e0ae210f24b94d089c65131cc518 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 abdf848ce528938d6a113cf7069f5768d9501d29 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 fbb13732c6ffa9d58cedafabcd5ce8fd7ef8ae5a 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 f85a1d06afbcc57ac44176db8f9d7a934979952c 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 72ea9a7e9e260aa39f9d1c9254cf92adfb05c4f5 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 921fcf2971a1e8d3b904ba2c2905b96f4ec3d4ad 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 b6334d2356fc0922ed01457960f74923058a353a Author: Jianbo Liu Date: Mon Jun 3 13:26:39 2024 +0300 IB/mlx5: Allocate resources just before first QP/SRQ is created [ Upstream commit 5895e70f2e6e8dc67b551ca554d6fcde0a7f0467 ] Previously, all IB dev resources are initialized on driver load. As they are not always used, move the initialization to the time when they are needed. To be more specific, move PD (p0) and CQ (c0) initialization to the time when the first SRQ is created. and move SRQs（s0 and s1) initialization to the time first QP is created. To avoid concurrent creations, two new mutexes are also added. Signed-off-by: Jianbo Liu Link: https://lore.kernel.org/r/98c3e53a8cc0bdfeb6dec6e5bb8b037d78ab00d8.1717409369.git.leon@kernel.org Signed-off-by: Leon Romanovsky Stable-dep-of: ede132a5cf55 ("RDMA/mlx5: Move events notifier registration to be after device registration") Signed-off-by: Sasha Levin commit 3dd9df8e5f34c6fc4217a7498c1fb3c352d4afc2 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 1dd2d5630f0c639e4f9f7c2c53af5d60a2bcc4a7 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 277ecc3d9797e81f114dc9635b1ad601549c91bd 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 d2f3414036be86f015814506626faba34645daf2 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 e7d134bd28ee9eab12e299323d207dbbfe3d5ae3 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 a6faea503ba4345c267b4a414827881cfa8c461e 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 8e0de82ed18ba0e71f817adbd81317fd1032ca5a 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 ae5427f88f1978662150c7bae7356c46a34d834e 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 4989d1ccf6f1c5691d5b8d87a0aed8e1ffe17b3c 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 6b0d7d6e6883d0ec70cd7b5a02c47c003d5defe7 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 451d57b22b4a68890ba1ee1a57f4d4069f35083e 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 837197f49c7199aa914ea5ff69d306a36d17ab1f 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 44cb69dbec7818ebc712ff8e080335ae43031377 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 d4e39b6f96fea9d3167a3c3a305daf584e867b4f 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 d0f6d80dbc79ed3d110e525f1b7a173ed5091601 Author: Kai Huang Date: Tue Aug 15 23:01:59 2023 +1200 x86/tdx: Pass TDCALL/SEAMCALL input/output registers via a structure [ Upstream commit 57a420bb8186d1d0178b857e5dd5026093641654 ] Currently, the TDX_MODULE_CALL asm macro, which handles both TDCALL and SEAMCALL, takes one parameter for each input register and an optional 'struct tdx_module_output' (a collection of output registers) as output. This is different from the TDX_HYPERCALL macro which uses a single 'struct tdx_hypercall_args' to carry all input/output registers. The newer TDX versions introduce more TDCALLs/SEAMCALLs which use more input/output registers. Also, the TDH.VP.ENTER (which isn't covered by the current TDX_MODULE_CALL macro) basically can use all registers that the TDX_HYPERCALL does. The current TDX_MODULE_CALL macro isn't extendible to cover those cases. Similar to the TDX_HYPERCALL macro, simplify the TDX_MODULE_CALL macro to use a single structure 'struct tdx_module_args' to carry all the input/output registers. Currently, R10/R11 are only used as output register but not as input by any TDCALL/SEAMCALL. Change to also use R10/R11 as input register to make input/output registers symmetric. Currently, the TDX_MODULE_CALL macro depends on the caller to pass a non-NULL 'struct tdx_module_output' to get additional output registers. Similar to the TDX_HYPERCALL macro, change the TDX_MODULE_CALL macro to take a new 'ret' macro argument to indicate whether to save the output registers to the 'struct tdx_module_args'. Also introduce a new __tdcall_ret() for that purpose, similar to the __tdx_hypercall_ret(). Note the tdcall(), which is a wrapper of __tdcall(), is called by three callers: tdx_parse_tdinfo(), tdx_get_ve_info() and tdx_early_init(). The former two need the additional output but the last one doesn't. For simplicity, make tdcall() always call __tdcall_ret() to avoid another "_ret()" wrapper. The last caller tdx_early_init() isn't performance critical anyway. Suggested-by: Peter Zijlstra Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/483616c1762d85eb3a3c3035a7de061cfacf2f14.1692096753.git.kai.huang%40intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit a79a114f60f16eab4709467d1b844a222a6a098b Author: Kai Huang Date: Tue Aug 15 23:01:58 2023 +1200 x86/tdx: Rename __tdx_module_call() to __tdcall() [ Upstream commit 5efb96289e581c187af1bc288ce5d26ed6181749 ] __tdx_module_call() is only used by the TDX guest to issue TDCALL to the TDX module. Rename it to __tdcall() to match its behaviour, e.g., it cannot be used to make host-side SEAMCALL. Also rename tdx_module_call() which is a wrapper of __tdx_module_call() to tdcall(). No functional change intended. Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Reviewed-by: Kuppuswamy Sathyanarayanan Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/785d20d99fbcd0db8262c94da6423375422d8c75.1692096753.git.kai.huang%40intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit 40d3b219aeb7a16abaabb6deacb7a508264684e8 Author: Kai Huang Date: Tue Aug 15 23:01:57 2023 +1200 x86/tdx: Make macros of TDCALLs consistent with the spec [ Upstream commit f0024dbfc48d8814d915eb5bd5253496b9b8a6df ] The TDX spec names all TDCALLs with prefix "TDG". Currently, the kernel doesn't follow such convention for the macros of those TDCALLs but uses prefix "TDX_" for all of them. Although it's arguable whether the TDX spec names those TDCALLs properly, it's better for the kernel to follow the spec when naming those macros. Change all macros of TDCALLs to make them consistent with the spec. As a bonus, they get distinguished easily from the host-side SEAMCALLs, which all have prefix "TDH". No functional change intended. Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Reviewed-by: Kuppuswamy Sathyanarayanan Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/516dccd0bd8fb9a0b6af30d25bb2d971aa03d598.1692096753.git.kai.huang%40intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit 2765142c05a6d2b03bbb088885e0f285e97d3b8f Author: Kai Huang Date: Tue Aug 15 23:01:56 2023 +1200 x86/tdx: Skip saving output regs when SEAMCALL fails with VMFailInvalid [ Upstream commit 03a423d40cb30e0e1cb77a801acb56ddb0bf6f5e ] If SEAMCALL fails with VMFailInvalid, the SEAM software (e.g., the TDX module) won't have chance to set any output register. Skip saving the output registers to the structure in this case. Also, as '.Lno_output_struct' is the very last symbol before RET, rename it to '.Lout' to make it short. Opportunistically make the asm directives unindented. Suggested-by: Peter Zijlstra Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Reviewed-by: Kirill A. Shutemov Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/all/704088f5b4d72c7e24084f7f15bd1ac5005b7213.1692096753.git.kai.huang%40intel.com Stable-dep-of: f65aa0ad79fc ("x86/tdx: Dynamically disable SEPT violations from causing #VEs") Signed-off-by: Sasha Levin commit c72a9456fdc829c9b47726106d37ec107bf3d801 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 10a6fc486ac40a410f0fb84cc15161238eccd20a 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 7c1832287b21ff68c4e3625e63cc7619edf5908b 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 ac3c9fb621de1db40addedd3ae67add10a315134 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 c28409f851abd93b37969cac7498828ad533afd9 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 d069227df10d26ee484dacab35599102cfa47ee0 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 ed25712291553cfb438a938e2d2c242712977d6b 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 ec3eb00526bf8e420ae12be523f527aed9cac11a 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 f6a2560e149e1fa447321b556c5617784f985892 Author: Dan Carpenter <dan.carpenter@linaro.org> Date: Tue Jun 11 16:43:29 2024 +0300 checkpatch: check for missing Fixes tags [ Upstream commit d5d6281ae8e0c929c3ff188652f5b12c680fe8bf ] This check looks for common words that probably indicate a patch is a fix. For now the regex is: (?:(?:BUG: K.|UB)SAN: |Call Trace:|stable\@|syzkaller)/) Why are stable patches encouraged to have a fixes tag? Some people mark their stable patches as "# 5.10" etc. This is useful but a Fixes tag is still a good idea. For example, the Fixes tag helps in review. It helps people to not cherry-pick buggy patches without also cherry-picking the fix. Also if a bug affects the 5.7 kernel some people will round it up to 5.10+ because 5.7 is not supported on kernel.org. It's possible the Bad Binder bug was caused by this sort of gap where companies outside of kernel.org are supporting different kernels from kernel.org. Should it be counted as a Fix when a patch just silences harmless WARN_ON() stack trace. Yes. Definitely. Is silencing compiler warnings a fix? It seems unfair to the original authors, but we use -Werror now, and warnings break the build so let's just add Fixes tags. I tell people that silencing static checker warnings is not a fix but the rules on this vary by subsystem. Is fixing a minor LTP issue (Linux Test Project) a fix? Probably? It's hard to know what to do if the LTP test has technically always been broken. One clear false positive from this check is when someone updated their debug output and included before and after Call Traces. Or when crashes are introduced deliberately for testing. In those cases, you should just ignore checkpatch. Link: https://lkml.kernel.org/r/ZmhUgZBKeF_8ixA6@moroto Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dwaipayan Ray <dwaipayanray1@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: 2f07b6523849 ("checkpatch: always parse orig_commit in fixes tag") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 0ac9a7fbe907c146e21cc45b266d52231281b45a 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 c801250a77147508c603a8655e1f7dccd55ac4ef 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 0bfed74e80cc9e30a84486053b942c5bf438210c 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 e334c2fd518c0a1d62509db58daa3338831811b8 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 b92706bd0eb068226e7ce4d73360011d77b4f0a6 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 db62437bf2da016fc9cdeebc4eb605a6b673f540 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 791bf61903573f76bd78aec3fb91e6c51c400768 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 cd2f9bc877115b91eba8409a2acb7ec7de27617a 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 e435f311c55d271ddb83b5c6ffdbed5ab5286876 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 a9b251599bd3b06016851b344af4748e296fb570 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 4f2d22278e93e8bc07260117bba04ac8e6cc0401 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 f37cc04fe893f54667b5ae4b7dc222ed07a1c4a6 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 31978d5c5aef034d96fc53b4a9cb3c6e11dbb94d 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 b4ba31e5aaffbda9b22d9a35c40b16dc39e475a6 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 8e20ac838be89a3bc420a312d4460342e5c57f45 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 44470c5eb88b8b41a067138d7b3e283200d90e66 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 f05ef81db63889f6f14eb77fd140dac6cedb6f7f 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 e07570a8f2cfc51260c6266cb8e1bd4777a610d6 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 a246daa26b717e755ccc9061f47f7cd1c0b358dd 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 8a06435959cc182840198f6c07c8b2d1ce8a034e 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 9ea8d8bf9b625e8ad3be6b0432aecdc549914121 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 f1290871c8aaeb13029390a2b6e5c05733a1be6f 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 95b9fb67e4937d5a83c7c2cf71e095a743965b86 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 29664ae6c4731fc09835e6a657cee5aad5be239b Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Date: Sun Oct 8 22:01:33 2023 +0200 mtd: hyperbus: rpc-if: Convert to platform remove callback returning void [ Upstream commit baaa90c1c923ff2412fae0162eb66d036fd3be6b ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/linux-mtd/20231008200143.196369-11-u.kleine-koenig@pengutronix.de Stable-dep-of: 7d189579a287 ("mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE") Signed-off-by: Sasha Levin <sashal@kernel.org> commit c5c1d1ef70834013fc3bd12b6a0f4664c6d75a74 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 92f7cc84c3dbbfb71a453d5de21e00f1b31a49b0 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 783df31532f9a78d07f86b8282da3a4267fbb7ed 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 d4cc78bd6a25accb7ae2ac9fc445d1e1deda4a62 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 1b734ad0e33648c3988c6a37c2ac16c2d63eda06 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 e1ef62e8d262e3f27446d26742208c1c81e9ee18 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 d80635d7ebefdbbb8eb398a2663183bb91b7f9e8 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 7c8ac49aa18ad823c541d8b5d826a5b3c43ef19e 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 a7083f0ce5f8f7ec812fe662fbb973c10bfc97e0 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 40163b26c3de00fb7493bfd6a11069c2e5902e9d 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 8b12c4e29ac2c98e6c13f4e0dd133eeac8dffc78 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 840295a8ff9e6fcd0edd5937c8c30e70310fa400 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 3d02397ca30b25b778f3a7cb823f25b854a84380 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 e2f15cb48ab7cd36b2b888238f60d27047db7616 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 c4b6c1781f6cc4e2283120ac8d873864b8056f21 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 da2bc8a0c8f3ac66fdf980fc59936f851a083561 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 aeafba58c43260894bda743065b3f698185459be 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 4802caac250b0d0bb33b7a9c5694f8e73b8185a0 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 f466641debcbea8bdf78d1b63a6270aadf9301bf 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 de5a44f351ca7efd9add9851b218f5353e2224b7 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 b754e831a94f82f2593af806741392903f359168 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 4507a8b9b30344c5ddd8219945f446d47e966a6d 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 2938dd2648522336133c151dd67bb9bf01cbd390 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 e07605d855c4104d981653146a330ea48f6266ed 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 440f6a15700e234fdc3ef27245c4c501c894b7de 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 89bf1b665ba9290d1ba6ea00baea3be45ccb4f83 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 38e3d796f65438d58791e6e75181948a63299beb 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 d1fb89f0024d01ae4fd052ffcef115969c17d190 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 43e25adc80269f917d2a195f0d59f74cdd182955 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 70530a2f8120ff26895f2cf6cfa7f300d5164497 Author: Eric Dumazet <edumazet@google.com> Date: Tue Jun 4 11:16:03 2024 +0000 net: use unrcu_pointer() helper [ Upstream commit b4cb4a1391dcdc640c4ade003aaf0ee19cc8d509 ] Toke mentioned unrcu_pointer() existence, allowing to remove some of the ugly casts we have when using xchg() for rcu protected pointers. Also make inet_rcv_compat const. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Toke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/r/20240604111603.45871-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal") Signed-off-by: Sasha Levin <sashal@kernel.org> commit bba7266d9dc4728a3c023f6730360f6a86faad34 Author: Eric Dumazet <edumazet@google.com> Date: Mon Jan 22 11:26:01 2024 +0000 sock_diag: allow concurrent operation in sock_diag_rcv_msg() [ Upstream commit 86e8921df05c6e9423ab74ab8d41022775d8b83a ] TCPDIAG_GETSOCK and DCCPDIAG_GETSOCK diag are serialized on sock_diag_table_mutex. This is to make sure inet_diag module is not unloaded while diag was ongoing. It is time to get rid of this mutex and use RCU protection, allowing full parallelism. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 161d4fc07133d0f4628c0529a274826797a02a79 Author: Eric Dumazet <edumazet@google.com> Date: Mon Jan 22 11:26:00 2024 +0000 sock_diag: allow concurrent operations [ Upstream commit 1d55a6974756cf3979efd2cc68bcece611a44053 ] sock_diag_broadcast_destroy_work() and __sock_diag_cmd() are currently using sock_diag_table_mutex to protect against concurrent sock_diag_handlers[] changes. This makes inet_diag dump serialized, thus less scalable than legacy /proc files. It is time to switch to full RCU protection. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 37103a9d7f128f5c876d87aedd43baa8ebe6cc9b Author: Eric Dumazet <edumazet@google.com> Date: Mon Jan 22 11:25:59 2024 +0000 sock_diag: add module pointer to "struct sock_diag_handler" [ Upstream commit 114b4bb1cc19239b272d52ebbe156053483fe2f8 ] Following patch is going to use RCU instead of sock_diag_table_mutex acquisition. This patch is a preparation, no change of behavior yet. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Stable-dep-of: eb02688c5c45 ("ipv6: release nexthop on device removal") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 5ef3e03228e16c11f79cb4e1d16edd3f4c8bf0f2 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 98c7ea7d11f2588e8197db042e0291e4ac8f8346 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 a53ad8ab116d5bfb2bbcbb080f73355717d358be 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 9df2dddc083a8b371ddcad07aa7860b3a410c3db 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 862b395de02df3ace2aa7a4105d9eed541a33ffd 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 a1820f63dd1e2ea8b3b9846cd32d1750ac461e6b 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 c8803b286d9d600c98bf1340f6b1de2f08345108 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 c88ae0a77c21a54277e8dfb79206ade23e6e4941 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 c65cff783752f70dd20386d258b81dd5f40c2b7a 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 5199d4a4e018607fe9b1da42d624cc7b4800935d Author: Pablo Neira Ayuso <pablo@netfilter.org> Date: Tue Mar 5 09:35:48 2024 +0100 netfilter: nf_tables: skip transaction if update object is not implemented [ Upstream commit 84b1a0c0140a9a92ea108576c0002210f224ce59 ] Turn update into noop as a follow up for: 9fedd894b4e1 ("netfilter: nf_tables: fix unexpected EOPNOTSUPP error") instead of adding a transaction object which is simply discarded at a later stage of the commit protocol. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Stable-dep-of: cddc04275f95 ("netfilter: nf_tables: must hold rcu read lock while iterating object type list") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 981af60dd6a24ec5486c70a23b6d3ea59e9ca720 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 cd38d9cdf4bb91f361b61af4b8570ead680b03a7 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 6ee1c9849cc483cbada6f93fd1537388ffddcf06 Author: Phil Sutter <phil@nwl.cc> Date: Thu Oct 19 16:03:35 2023 +0200 netfilter: nf_tables: Introduce nf_tables_getrule_single() [ Upstream commit 1578c32877191815f631af32ba5dfc1f1b20c1b4 ] Outsource the reply skb preparation for non-dump getrule requests into a distinct function. Prep work for rule reset locking. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Stable-dep-of: 9adbb4198bf6 ("netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 1d0f811ec145558beff3fab5aae74ff58b4af393 Author: Phil Sutter <phil@nwl.cc> Date: Thu Oct 19 16:03:34 2023 +0200 netfilter: nf_tables: Open-code audit log call in nf_tables_getrule() [ Upstream commit 8877393029e764036892d39614900987cbd21ca6 ] The table lookup will be dropped from that function, so remove that dependency from audit logging code. Using whatever is in nla[NFTA_RULE_TABLE] is sufficient as long as the previous rule info filling succeded. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Stable-dep-of: 9adbb4198bf6 ("netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion") Signed-off-by: Sasha Levin <sashal@kernel.org> commit cf7b5e0bc1991e1295f0294157ba4f6810b0641e 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 23c3f60082acfff5e8f6a8ed6d2fcd8f198ce34e 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 41f0b320b6ea355871c4f563c57b3baebc65009d 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 b32f915fc659b07fe19d19e70f2c9ecdb5267f3d 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 1c079dace922b3901fabf82ed4f13b726ffcbc7e 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 a17b9afe58c474657449cf87e238b1788200576b 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 237f2dbfa00576bb1aa8dc2dce403c64e53270e6 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 ba0599332acc0e9110df9f0d26d703560df41d9d 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 6b1c1297bcd541309306860d44e50e90b03557cf 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 a3d37915f1338d6a7e1e7406893ce7e184f01963 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 1021cc87206a6e57e35d09fd394d368dbbf5a412 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 d6a559c5642df91b2b68dde0f3b4a2fd92bd62d6 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 c6120d95c729b1e312fb9afdcb80a7d8f3be026f 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 b955ceba2c1efe3a5688e6dd9d7bdd63148cf9b6 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 b99db02209ca4c2e2f53b82049ea3cbc82b54895 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 3ccbc7a518868eff1d5a198b9e454e182b651e00 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 c5a6c5af434671aea739a5a41c849819144f02c9 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 c4eae7bac880edd88aaed6a8ec2997fa85e259c7 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 c0f64fd73b60aee85f88c270c9d714ead27a7b7a 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 52c63a6a27d3178fab533fcfb4baa2ed5b8608a3 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 bfbd0b09aff003468ec41092a8ed0343cea9e2c7 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 29fa82adec3c49eba377bde740b35c61abddeedb 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 b9ebac16315e1798d31b1d1eeb311b6c57b8603d 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 0e5bcf5136f1d44127e369d622a6bd8238feb6f8 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 c4698ef8c42e02782604bf4f8a489dbf6b0c1365 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 557e07a7a487dbca27e2ce06ac49309320f61835 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 26f54adde8392dffa2fd6433510f44cbe98fb5ab 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 5981e6e1b50d8bb583c376b787fa4d51357af29d 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 80afbcbdaf48202ab6a6a78af224558f005ba940 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 ef38a689f4e009992c037edf73427d94e8329313 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 452eb0e1589db3187690e4f955e5ba11df02d0d3 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 36c79b9ff20a4999677c39226316b63fda999d7d 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 a8ec6447d76d70d1e00d6af6549480a2af68d11c 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 fff56eb08053ad0b5ca659859171edc233c23419 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 a340f911530103c192b8bdf7372134e536563f6f Author: Haiyue Wang <haiyue.wang@intel.com> Date: Wed Sep 6 13:57:02 2023 -0600 ice: Support FCS/CRC strip disable for VF [ Upstream commit 730cb741815c71d9dd8d1bc7d0b7d9a0acc615a8 ] To support CRC strip enable/disable functionality, VF needs the explicit request VIRTCHNL_VF_OFFLOAD_CRC offload. Then according to crc_disable flag of Rx queue configuration information to set up the queue context. Signed-off-by: Haiyue Wang <haiyue.wang@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Stable-dep-of: a884c304e18a ("ice: consistently use q_idx in ice_vc_cfg_qs_msg()") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 2edb61b5d3f00221e16961f305ee89278d2ebadc Author: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Date: Wed Sep 6 13:57:01 2023 -0600 virtchnl: Add CRC stripping capability [ Upstream commit 89de9921dfa77e43b985bde99a6031ab66511020 ] Some VFs may want to disable CRC stripping on incoming packets so create an offload for that. The VF already sends information about configuring its RX queues so use that structure to indicate that the CRC stripping should be enabled or not. Signed-off-by: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Ahmed Zaki <ahmed.zaki@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Stable-dep-of: a884c304e18a ("ice: consistently use q_idx in ice_vc_cfg_qs_msg()") Signed-off-by: Sasha Levin <sashal@kernel.org> commit fb5d7f68e676a84b25ec2fc8c974de79d2a393f9 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 e05f60981951752cc849845136f9886fc43e2201 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 44a21d9fbc2d85f64cba552cfd4d0f8403434fa7 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 d900a20e33d7f533716e8c2129fea54f031b697f 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 65f9fe75cad180348a717c8d6e8d4d9b0b7ea11b 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 c2a04ba6f93d0020f1aa7843770fe04b937cb54c 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 3340acafcce6561ee066889207316a2c02ce063a 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 537f327629be8e38460166da88c1d4f624dec906 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 53507b7c6363a50738de8fc69c1f08128ee6c552 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 d73da0dd2853887b7aab71f0d572fd3314dafafe 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 8325a50983c1726da203df09d0fc7e260da1d82c 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 9ef3985a9e02b3eb2bf8a75269f95b5d51e789ab 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 56541262079df1929333f09848ba4682bf76f40e 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 fda29dff5581103a96de20b952015f8e3875b772 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 b509546bfa1f07509481beaa85181ce1f1932c37 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 521d4b3f1dc1c62b0193c94049521ca211d79a18 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 dbdca51b054f6e8a3207df74d36ac83be3644a88 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 088e10e7439013333876d6a3dc1965108a503282 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 4da37fba2a6b2792cbb2f5887b51b547df3e07c3 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 b6551479daf2bfa80bfd5d9016b02a810e508bfb 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 9728b508b01a5eeeac79ceb676364c674dd951ac 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 52c1716f65a558174e381360bd88f18dae4be85c 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 8182b5ca19c6f173b6498d1c6d3e4b034b76bbde 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 c7d474974954d9af7e0092021223d58f2de128df 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 40c77e93cfdda320f47fc1a00a76ce466d20e976 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 2ee46de426cc9555e507afd0dc390a98e8947332 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 6c8938e41b82a59d5a44220e3d7fd36d96822bc4 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 b03e713a400aeb5f969bab4daf47a7402d0df814 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 599929021528f353ab1e4f0ab0d43342adf4d50a 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 8066badaf7463194473fb4be19dbe50b11969aa0 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 025067eeb945aa17c7dd483a63960125b7efb577 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 667b0527a3e7a5b0e2384e12ef1a1e3df2a9ff2c 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 99ca7bddcade2fe0d4841433607e7f0bc19ba4eb 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 feb6e4412537eecfce6393571be72a00420de775 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Dec 15 17:04:52 2023 +0200 selftests/resctrl: Refactor fill_buf functions [ Upstream commit 24be05591fb7a2a3edd639092c045298dd57aeea ] There are unnecessary nested calls in fill_buf.c: - run_fill_buf() calls fill_cache() - alloc_buffer() calls malloc_and_init_memory() Simplify the code flow and remove those unnecessary call levels by moving the called code inside the calling function and remove the duplicated error print. Resolve the difference in run_fill_buf() and fill_cache() parameter name into 'buf_size' which is more descriptive than 'span'. Also, while moving the allocation related code, rename 'p' into 'buf' to be consistent in naming the variables. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Stable-dep-of: caf02626b2bf ("selftests/resctrl: Fix memory overflow due to unhandled wraparound") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 315f9a1e1748f5b74d72658ecf052fce569d1f36 Author: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Date: Fri Dec 15 17:04:51 2023 +0200 selftests/resctrl: Split fill_buf to allow tests finer-grained control [ Upstream commit f8f669699977db503569465b64dc5220ab21bb41 ] MBM, MBA and CMT test cases call run_fill_buf() that in turn calls fill_cache() to alloc and loop indefinitely around the buffer. This binds buffer allocation and running the benchmark into a single bundle so that a selftest cannot allocate a buffer once and reuse it. CAT test doesn't want to loop around the buffer continuously and after rewrite it needs the ability to allocate the buffer separately. Split buffer allocation out of fill_cache() into alloc_buffer(). This change is part of preparation for the new CAT test that allocates a buffer and does multiple passes over the same buffer (but not in an infinite loop). Co-developed-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Stable-dep-of: caf02626b2bf ("selftests/resctrl: Fix memory overflow due to unhandled wraparound") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 367a0a92b968c4a02f375799ee2821dbb5d254ae 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 1e1acb879e3c1ce6f5dab4595508ab5241c8ad3f 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 7db9c3c15fb58f7975bb6fa545c6d921f0c6a42f 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 dbcba9b1108ab3ac2797b36043ff4e9fb02f020a 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 a67ebf6dcc4ac6811757c5ba4a16ef62f33b1bd8 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 3dea2312ab45915d8178f8a63f8a85392131592b 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 2c8cfd1671007087fab97502d4d33c9ef33091cc 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 48e518e705e74ee9d04c9d7077698e440dac6c4b 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 872bfc20abea144c144d006ff16bafdf39d8197d 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 1103d3b5a5025aba1ea1fcee287c8858b175bec4 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 be0a96cfa9c06cee30af45a583a1c18a8d15f47a Author: Stephen Boyd <sboyd@kernel.org> Date: Fri Feb 16 17:05:53 2024 -0800 x86/of: Unconditionally call unflatten_and_copy_device_tree() [ Upstream commit 40f18dbbb42c56019b889b5b1fdce3da89e354da ] Call this function unconditionally so that we can populate an empty DTB on platforms that don't boot with a firmware provided or builtin DTB. There's no harm in calling unflatten_device_tree() unconditionally here. If there isn't a non-NULL 'initial_boot_params' pointer then unflatten_device_tree() returns early. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: x86@kernel.org Cc: H. Peter Anvin <hpa@zytor.com> Tested-by: Saurabh Sengar <ssengar@linux.microsoft.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20240217010557.2381548-5-sboyd@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Stable-dep-of: b2473a359763 ("of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify") Signed-off-by: Sasha Levin <sashal@kernel.org> commit ccf190dba6409ec67644d76df0ff7c5871f1a775 Author: Stephen Boyd <sboyd@kernel.org> Date: Fri Feb 16 17:05:52 2024 -0800 um: Unconditionally call unflatten_device_tree() [ Upstream commit 221a819aa3ca5bbbc91ce425b3e8d9463b121d09 ] Call this function unconditionally so that we can populate an empty DTB on platforms that don't boot with a command line provided DTB. There's no harm in calling unflatten_device_tree() unconditionally. If there isn't a valid initial_boot_params dtb then unflatten_device_tree() returns early. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: linux-um@lists.infradead.org Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20240217010557.2381548-4-sboyd@kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Stable-dep-of: b2473a359763 ("of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 66b991a52ae6b337d92b43a365a0ff404ad2572d 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 a21e7623d7827facda8245b93fdd73e9bfa77c53 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 cae00563f173831e8c296aadb5fab8729d60f3a1 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 ccdac40ce4d2857444edf6dfe47ed639c97dcf14 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 4981b8a2d9fafa0d8060c83ffb19cd55c6798046 Author: Thomas Richard <thomas.richard@bootlin.com> Date: Tue Nov 28 16:35:01 2023 +0100 arm64: dts: ti: k3-j7200: use ti,j7200-padconf compatible [ Upstream commit 4eb42afed5d488c4707be5362e8e0f0771f5218e ] For suspend to ram on j7200, use ti,j7200-padconf compatible to save and restore pinctrl contexts. Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20231128-j7200-pinctrl-s2r-v1-3-704e7dc24460@bootlin.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Stable-dep-of: b7af8b4acb3e ("arm64: dts: ti: k3-j7200: Fix register map for main domain pmx") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9810ceccd99b1cd67ad00eb5905bd6b25c4f3474 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 0d9cee68a3f104dc385538045b61b411e1e120bd 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 15cbeb8ae3c07acfff8cd836c0cfb3ca19825ae6 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 8e965120d8458b829b5534a665b554c034c699bb 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 8b833a02b4548b2a0fdcbdc02c24de12343bccf6 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 0f627e99cca6e4bbc6f97113884aca8764340e60 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 52c3eb1c8ce8c1555fe923e4dda91c27deb8bf05 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 9e67b054198f220b528238ecc6fd812d2baca112 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 92031d66015271e8e224d67cbabb925a63dd635b 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 2ef8dc16041b12c8798a562e81601c30a5120712 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 78a8e85b5314d3c24fb31f4d2c8cf733f455416d 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 699e5e70ad34acd086e224187684560874320406 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 3164cc7cf77acd7df6a56ac0246544b64d516635 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 f8549e3f03c1824b367eb8c9c43ddc2be99939c8 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 ae0ad16260180476bcf6c575a1beeab6a135c357 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 b18f8d9e282717de81a5d5ba5a12bf5a013e5791 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 91884250825f7ea7a90ad376375af30c4e720444 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 4e12b09f57c2abcd61226dd748671960d430c704 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 653847d80fa9cec75a59e409a0992fa07cb8b8eb 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 c24e019ca12d9ec814af04b30a64dd7173fb20fe 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 bfd19f48c45cfd95499a37f3f40a4644a9f6c249 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 b7394c6fba3a9697dcd23b8a6397ccc702fdd2e7 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 0a3ba7c09ac88b0e9135dab1f8483d1e49e916b7 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 1dcb74ebda5ca89dd283365117d34f596fe720ef 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 882d7afaa4b82c20a7be7a3a039532a80ebacd23 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 d3a5e7ffbd417a99ea0d1af86b03389a9d725ae6 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 ecbc50474769971c2d7268d1ac8e72eb22d78bd7 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 3ba257d80ffa0b4773712b404f4be6a25db330e5 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 45eec49fa2fa232ecdeecbbe759ba51d0818ddad 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 5b12a7e70b0bf39114b16ed6887fc0f5c227739a 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 01b61f5cef36e0e27e8f1f15b348a0b2f4de07ca 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 7723bfe6f90326ebc139d25f779b369bfff9c8e0 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 8d91bdca2f97fa7a195b7a5f7552ffb6d259dda5 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 cc08c2c8e98e84756530f3aa1c1d5c1439a6e305 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 1b78ac7eb6c7a8136f8a7b23c302c17a79e57517 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 5cecc57865067f8ddfd22df922f0ab338ef83ead 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 a40520a7a5e6b743a74649fa9725c3c2c9fe48ab 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 ae5253313e0ea5f00c06176074592b7f493c8546 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 5a0329563e25d79fdf257abaf97bf2035eb1486c 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 1fa9635a5f679f1a28e5bf95ea8362419801f15b 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 685c10269c41d23d7a2b85d3fd6b6345390c8746 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 4ffcf7893f4bed58c90477d7be03ed8805b82201 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 714788c6a697a9f31f73ac858b2bc0ecac1b578d Author: Patrick Rudolph <patrick.rudolph@9elements.com> Date: Tue Jan 30 20:59:03 2024 +0530 hwmon: (pmbus_core) Allow to hook PMBUS_SMBALERT_MASK [ Upstream commit 9c6df63a66c1fdf99d6e1ad278d140080c724120 ] Use _pmbus_write_word_data to allow intercepting writes to PMBUS_SMBALERT_MASK in the custom chip specific code. This is required for MP2971/MP2973 which doesn't follow the PMBUS specification for PMBUS_SMBALERT_MASK. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Naresh Solanki <naresh.solanki@9elements.com> Link: https://lore.kernel.org/r/20240130152903.3651341-1-naresh.solanki@9elements.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Stable-dep-of: 509c3a362675 ("hwmon: (pmbus/core) clear faults after setting smbalert mask") Signed-off-by: Sasha Levin <sashal@kernel.org> commit 967a0e61910825d1fad009d836a6cb41f7402395 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 f5fed8a850d08136f424ac378279162508dde4e0 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 605150b4c903396cfefc2943dad821483e91909a 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 830cabb61113d92a425dd3038ccedbdfb3c8d079 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 6a975fbab1d21b9e663d366d5b7da061d53ea5cd 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 4b3c113af8d612601f16e434a62f8e3747bfc24d 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 db74e48b49ad6ff988cd8a59cc905b569c19c1df 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 5edae7a9a35606017ee6e05911c290acee9fee5a 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 d9338b781fe9342e9e3c87c998d8260519da8753 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 edf58d4bebc3a2cf2d3ed5e26967f65aa40a813d 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 63a2d940c719fbded9d8fef94b5fb6a4933447f9 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 ac7dfac639709c210ce667485c64c7a03cd3e02c 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 85a57cdc1b25423245909cca9da08f433bde6cc7 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 ac6ebb9edcdb7077e841862c402697c4c48a7c0a 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 bba6cba4dab25516654519a27391eb9c1596f609 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 05c9a7a5344425860202a8f3efea4d8ed2d10edb 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 2a064b788dee46f01dc6a3136fdf7661ff2f9ba0 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 1f8e2f597b918ca5827a5c6d00b819d064264d1c 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 b2c36fa9ac8a7daa8cb1f374ab72ec540c286ed2 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 519899291235673c731f94fbc48198871a3eb2e8 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 77035e4d27e15f87ea55929c8bb8fb1970129e2f 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 cca05950897540bc66c16b1e3b0a5e9c70402f70 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 2266fe580adf5cc928d2ffd68949547f7952eab1 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 fbd359a2ee201f81119fa56eaf86e5b499220fc3 Author: Matthew Wilcox (Oracle) <willy@infradead.org> Date: Sat Apr 20 03:50:05 2024 +0100 ext4: remove calls to to set/clear the folio error flag [ Upstream commit ea4fd933ab4310822e244af28d22ff63785dea0e ] Nobody checks this flag on ext4 folios, stop setting and clearing it. Cc: Theodore Ts'o <tytso@mit.edu> Cc: Andreas Dilger <adilger.kernel@dilger.ca> Cc: linux-ext4@vger.kernel.org Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20240420025029.2166544-11-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 21900e8478126ff6afe3b66679f676e74d1f8830 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 13ebba9e57a6b176bb238d31ad7fb95bbbcc7688 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 fad4262bd40d736953e6fe262db51636ab3aca4f 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 539fabba965e119b98066fc6ba5257b5eaf4eda2 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 ae8c963906edcbbd3fd4ddd1e228790d7304b386 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 01f605a4cd747955c5f796715e770f500736b304 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 b46bc5b02ded648526522e0d5131512cde481714 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 d4e05e9545040f6f24fd30c42d7229ac6bc936ad 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 6395a5f9eb44477d84aa5c97c83a5e56e54671a3 Author: Geert Uytterhoeven <geert@linux-m68k.org> Date: Wed Sep 13 16:08:25 2023 +0200 m68k: mvme16x: Add and use "mvme16x.h" [ Upstream commit dcec33c1fc4ab63983d93ffb0d82b68fc5775b88 ] When building with W=1: arch/m68k/mvme16x/config.c:208:6: warning: no previous prototype for ‘mvme16x_cons_write’ [-Wmissing-prototypes] 208 | void mvme16x_cons_write(struct console *co, const char *str, unsigned count) | ^~~~~~~~~~~~~~~~~~ Fix this by introducing a new header file "mvme16x.h" for holding the prototypes of functions implemented in arch/m68k/mvme16x/. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/6200cc3b26fad215c4524748af04692e38c5ecd2.1694613528.git.geert@linux-m68k.org Stable-dep-of: 077b33b9e283 ("m68k: mvme147: Reinstate early console") Signed-off-by: Sasha Levin <sashal@kernel.org> commit d77659d3ffbac4008b3bd8ce37da8a3c4a1df901 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 cee3bff51a35cab1c5d842d409a7b11caefe2386 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 1a423bbbeaf9e3e20c4686501efd9b661fe834db 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 372042443be4855e6fd3bc274a54a3a37e67005b 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 6c63de9b4d0e700e111a972f8c726725ab7f343c 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 410896624db639500f24f46478b4bfa05c76bf56 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 83d123e27623713dd69eed2569eacf5f1b3c9033 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 f662b4a69e1d6c15db3354de6fc9f923417a5a10 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 aa6e32c654fcbcd384c2259e0fe54f67f442c7e9 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 a1dc0428c05a5a0073d78eeaa3d594ded6ada5c7 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 9820f354867999ddef857e202d74b902d95eb7c2 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 b95a1cd26a2816dbcdc0d2b8e52c8f6ee282e06d 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 0dd9a53bb9b2562c7f73edbca2f399828700b7a6 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 ecc2aeeaa08a355d84d3ca9c3d2512399a194f29 Author: Andrii Nakryiko <andrii@kernel.org> Date: Tue Nov 26 15:37:07 2024 +0800 bpf: support non-r10 register spill/fill to/from stack in precision tracking [ Upstream commit 41f6f64e6999a837048b1bd13a2f8742964eca6b ] Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present. Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/ Acked-by: Eduard Zingerman <eddyz87@gmail.com> Reported-by: Tao Lyu <tao.lyu@epfl.ch> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20231205184248.1502704-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 44b1bfb5bd97973ccb8d1d105a08470fc36812d8 Author: Dmitry Kandybka <d.kandybka@gmail.com> Date: Mon Nov 25 15:04:51 2024 +0100 mptcp: fix possible integer overflow in mptcp_reset_tout_timer commit b169e76ebad22cbd055101ee5aa1a7bed0e66606 upstream. In 'mptcp_reset_tout_timer', promote 'probe_timestamp' to unsigned long to avoid possible integer overflow. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Link: https://patch.msgid.link/20241107103657.1560536-1-d.kandybka@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ Conflict in this version because commit d866ae9aaa43 ("mptcp: add a new sysctl for make after break timeout") is not in this version, and replaced TCP_TIMEWAIT_LEN in the expression. The fix can still be applied the same way: by forcing a cast to unsigned long for the first item. ] Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 68f75e6f08aad66069a629db8d7840919156c761 Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Date: Tue Nov 26 14:55:32 2024 +0800 drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe [ Upstream commit 8e4ed3cf1642df0c4456443d865cff61a9598aa8 ] This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. 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. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877) Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> [Xiangyu: BP to fix CVE: CVE-2024-49914, modified the file path from drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c to drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c and minor conflict resolution] Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 36ff963c133a25ed1166a25c3ba8b357ea010fda Author: Hans de Goede <hdegoede@redhat.com> Date: Mon Nov 25 16:06:25 2024 +0800 platform/x86: x86-android-tablets: Unregister devices in reverse order [ Upstream commit 3de0f2627ef849735f155c1818247f58404dddfe ] Not all subsystems support a device getting removed while there are still consumers of the device with a reference to the device. One example of this is the regulator subsystem. If a regulator gets unregistered while there are still drivers holding a reference a WARN() at drivers/regulator/core.c:5829 triggers, e.g.: WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015 RIP: 0010:regulator_unregister Call Trace: <TASK> regulator_unregister devres_release_group i2c_device_remove device_release_driver_internal bus_remove_device device_del device_unregister x86_android_tablet_remove On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides a 5V boost converter output for powering USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator. On the 830 (8") and 1050 ("10") models this regulator is controlled by a platform_device and x86_android_tablet_remove() removes platform_device-s before i2c_clients so the consumer gets removed first. But on the 1380 (13") model there is a lc824206xa micro-USB switch connected over I2C and the extcon driver for that controls the regulator. The bq24190 i2c-client *must* be registered first, because that creates the regulator with the lc824206xa listed as its consumer. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator. Since in this case both the regulator provider and consumer are I2C devices, the only way to ensure that the consumer is unregistered first is to unregister the I2C devices in reverse order of in which they were created. For consistency and to avoid similar problems in the future change x86_android_tablet_remove() to unregister all device types in reverse order. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240406125058.13624-1-hdegoede@redhat.com [ Resolve minor conflicts ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f7d9a18572fcd7130459b7691bd19ee2a2e951ad Author: Keith Busch <kbusch@kernel.org> Date: Tue Nov 26 15:46:57 2024 +0800 nvme: apple: fix device reference counting [ Upstream commit b9ecbfa45516182cd062fecd286db7907ba84210 ] Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl. Split the allocation side out to make the error handling boundary easier to navigate. The apple driver had been doing this wrong, leaking the controller device memory on a tagset failure. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> [ Resolve minor conflicts ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 3820b0fac7732a653bcc6f6ac20c1d72e697f8f6 Author: Oleg Nesterov <oleg@redhat.com> Date: Mon Nov 25 13:33:07 2024 +0800 fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats [ Upstream commit 7601df8031fd67310af891897ef6cc0df4209305 ] lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. Link: https://lkml.kernel.org/r/20240123153357.GA21857@redhat.com Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Dylan Hatch <dylanbhatch@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> [ Resolve minor conflicts ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c7e65cab54a89f4df54110f0b44c4ade93d1a911 Author: Wayne Lin <wayne.lin@amd.com> Date: Tue Nov 26 09:34:03 2024 +0800 drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute [ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ] [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When commit new state which directly referring to info stored in dc_sink will cause null pointer dereference. [how] Remove redundant checking condition. Relevant condition should already be covered by checking if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. Reviewed-by: Jerry Zuo <jerry.zuo@amd.com> Acked-by: Zaeem Mohamed <zaeem.mohamed@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [ Resolve minor conflicts ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit c3a3b6d9a9383e3c1a4a08878ba5046e68647595 Author: Alex Hung <alex.hung@amd.com> Date: Tue Nov 26 19:23:26 2024 +0800 drm/amd/display: Check null-initialized variables [ Upstream commit 367cd9ceba1933b63bc1d87d967baf6d9fd241d2 ] [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. Reviewed-by: Nevenko Stupar <nevenko.stupar@amd.com> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Jerry Zuo <jerry.zuo@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit e0f6ee75f50476607ca82fc7c3711c795ce09b52 Author: Li Zhijian <lizhijian@fujitsu.com> Date: Mon Nov 25 16:04:01 2024 +0800 fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name [ Upstream commit 7f7b850689ac06a62befe26e1fd1806799e7f152 ] It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable. Signed-off-by: Li Zhijian <lizhijian@fujitsu.com> Link: https://lore.kernel.org/r/20240826055503.1522320-1-lizhijian@fujitsu.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [Xiangyu: Bp to fix CVE: CVE-2024-49934, modified strscpy step due to 6.1/6.6 need pass the max len to strscpy] Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9f35cec5e4b9759b38c663d18eae4eaf30f36527 Author: Alex Hung <alex.hung@amd.com> Date: Tue Nov 26 17:36:04 2024 +0800 drm/amd/display: Initialize denominators' default to 1 [ Upstream commit b995c0a6de6c74656a0c39cd57a0626351b13e3c ] [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Jerry Zuo <jerry.zuo@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [Xiangyu: Bp to fix CVE: CVE-2024-49899 Discard the dml2_core/dml2_core_shared.c due to this file no exists] Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit f38b09ba6a335c511eb27920bb9bb4a1b2c20084 Author: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Date: Tue Nov 26 18:10:51 2024 +0800 drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func [ Upstream commit 28574b08c70e56d34d6f6379326a860b96749051 ] This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma. Cc: Tom Chung <chiahsuan.chung@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Roman Li <roman.li@amd.com> Cc: Alex Hung <alex.hung@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 9d0f1e745e95e2e744041f8a3b95aab20e4994bb Author: Ard Biesheuvel <ardb@kernel.org> Date: Thu Nov 21 10:15:19 2024 -0500 x86/stackprotector: Work around strict Clang TLS symbol requirements [ Upstream commit 577c134d311b9b94598d7a0c86be1f431f823003 ] GCC and Clang both implement stack protector support based on Thread Local Storage (TLS) variables, and this is used in the kernel to implement per-task stack cookies, by copying a task's stack cookie into a per-CPU variable every time it is scheduled in. Both now also implement -mstack-protector-guard-symbol=, which permits the TLS variable to be specified directly. This is useful because it will allow to move away from using a fixed offset of 40 bytes into the per-CPU area on x86_64, which requires a lot of special handling in the per-CPU code and the runtime relocation code. However, while GCC is rather lax in its implementation of this command line option, Clang actually requires that the provided symbol name refers to a TLS variable (i.e., one declared with __thread), although it also permits the variable to be undeclared entirely, in which case it will use an implicit declaration of the right type. The upshot of this is that Clang will emit the correct references to the stack cookie variable in most cases, e.g., 10d: 64 a1 00 00 00 00 mov %fs:0x0,%eax 10f: R_386_32 __stack_chk_guard However, if a non-TLS definition of the symbol in question is visible in the same compilation unit (which amounts to the whole of vmlinux if LTO is enabled), it will drop the per-CPU prefix and emit a load from a bogus address. Work around this by using a symbol name that never occurs in C code, and emit it as an alias in the linker script. Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1854 Link: https://lore.kernel.org/r/20241105155801.1779119-2-brgerst@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org> commit dc5ead0e8fc5ef53b8553394d4aab60c277976b3 Author: Hugo Villeneuve <hvilleneuve@dimonoff.com> Date: Fri Nov 22 14:43:31 2024 +0800 serial: sc16is7xx: fix invalid FIFO access with special register set [ Upstream commit 7d3b793faaab1305994ce568b59d61927235f57b ] When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading. Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register set Fix the problem by claiming the efr_lock mutex when accessing the Special register set. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240723125302.1305372-3-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ Resolve minor conflicts ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit a891938947f4427f98cb1ce54f27223501efe750 Author: Holger Dengler <dengler@linux.ibm.com> Date: Thu Nov 21 16:12:22 2024 +0800 s390/pkey: Wipe copies of clear-key structures on failure [ Upstream commit d65d76a44ffe74c73298ada25b0f578680576073 ] Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key. Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> [ Resolve minor conflicts to fix CVE-2024-42156 ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit d038693e08adf9c162c6377800495e4f5a2df045 Author: Alexander Stein <alexander.stein@ew.tq-group.com> Date: Thu Nov 21 11:27:51 2024 +0800 i2c: lpi2c: Avoid calling clk_get_rate during transfer [ Upstream commit 4268254a39484fc11ba991ae148bacbe75d9cc0a ] Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> [ Resolve minor conflicts to fix CVE-2024-40965 ] Signed-off-by: Bin Lan <bin.lan.cn@windriver.com> Signed-off-by: Sasha Levin <sashal@kernel.org> commit 561063997ae333fab9bbf29a302305af4a16b64d 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 2abc2bd53e4c6ca30a1fd18cf7c29d9d9835d5b6 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 344fb3c52923e93831809d25cde6e3310d2fe668 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 7ed79c551c09067005ac6fcd183d0edec8804ad3 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 65b08af3c4a14980f37e6398bb3e7e5cc7b691b2 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 fe8c40810a110a33f666040b1ea29f927b28241a 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 82d0f099009e4446c87407c41abeae2a4ff0b6ad 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 0058f8ebfdb05156ed832bfdcf6a6b667f719d1b 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 d525fc94249afccd43c985c275cc561a90e44007 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 1423de2c7ba11d2176585ff1ca29fae2b58eceed 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 b07b441b79c2ed0d574f8a99f80c5f6849aa853b 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 769aa742527c9be934dd4fd58225869204f409a2 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 3e8cc9901073caf9a59cbb482c7f6fe78c2fd063 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 bb64195b56cad1f8bc02ceab5a5cbd525ca82841 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 739aac7323f0ac0c7f7176b628c88220aa733100 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 32660e18f5ca3908b0ec8be014bec7085bff4074 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 fd782cb8f9d3aa6369b851a58f4788d6f3efbae6 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 cb5bf93771026b31009fce603f64b1aed7c9295a 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 3bb3fa542835a61124f5096f3884bc7844e146a4 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 7c92e2b55677eecab3036d9ecf55a81c80071e76 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 363473736bb0eb5bfd533d9efbf35aa3323adc8f 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 3e3bc9cf3fdf7ea4b76b5e87cfbf51042607e24e 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 1b15738a7d30ff74bcfd49bc1f97e6ff9e593a5e 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 9dc3380fb5869f177222edb9dc403c34735059ac 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 16009cc182ef17b266b75b084e15e00b1fbd8f8b 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 f083283f914b8fae63cd7414683e4e4d8fb7412a 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 24fa3e9443a44156d93d9651c1d0786874d21fd4 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 675a1803efa15c4daa7d101091af9d9802f477c5 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 9b0f6adf28b497cd505a8697356d7e369295a64b 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 92cab36cf11a3d80cc5c7307bf988e909017dff3 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 6909df783e420dd4535ed202d6b79c065704d33c 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 98130b150916294dd4571fcf1544e40eae85b6b6 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 28f152fc9553580843c9716e96876755b86906e9 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>