user/sven/linux.git, branch v6.16.6

Linux 6.16.6

2025-09-09T17:02:41Z

Link: https://lore.kernel.org/r/20250907195615.802693401@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-By: Achill Gilgenast = Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Markus Reichelt Tested-by: Justin M. Forbes Tested-by: Dileep Malepu Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Dileep Malepu Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1"

2025-09-09T17:02:41Z

[ Upstream commit d2dc30e0aa252830f908c8e793d3139d51321370 ] This reverts commit d6e020819612a4a06207af858e0978be4d3e3140. The IS_DGFX check was put in place because error capture of buffer objects is expected to be broken on devices with VRAM. Userspace fix[1] to the impacted media driver has been submitted, merged and a new driver release is out as 25.2.3 where the capture flag is dropped on DG1 thus unblocking the usage of media driver on DG1. [1] https://github.com/intel/media-driver/commit/93c07d9b4b96a78bab21f6acd4eb863f4313ea4a Cc: stable@vger.kernel.org # v6.0+ Cc: Ville Syrjälä Cc: Andi Shyti Cc: Matthew Auld Cc: Thomas Hellström Cc: Tvrtko Ursulin Acked-by: Tvrtko Ursulin Reviewed-by: Andi Shyti Link: https://lore.kernel.org/r/20250522064127.24293-1-joonas.lahtinen@linux.intel.com [Joonas: Update message to point out the merged userspace fix] Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin

riscv: Fix sparse warning about different address spaces

2025-09-09T17:02:41Z

commit a03ee11b8f850bd008226c6d392da24163dfb56e upstream. We did not propagate the __user attribute of the pointers in __get_kernel_nofault() and __put_kernel_nofault(), which results in sparse complaining: >> mm/maccess.c:41:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void const [noderef] __user *from @@ got unsigned long long [usertype] * @@ mm/maccess.c:41:17: sparse: expected void const [noderef] __user *from mm/maccess.c:41:17: sparse: got unsigned long long [usertype] * So fix this by correctly casting those pointers. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508161713.RWu30Lv1-lkp@intel.com/ Suggested-by: Al Viro Fixes: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti Reviewed-by: Cyril Bur Link: https://lore.kernel.org/r/20250903-dev-alex-sparse_warnings_v1-v1-2-7e6350beb700@rivosinc.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: Fix sparse warning in __get_user_error()

2025-09-09T17:02:41Z

commit fef7ded169ed7e133612f90a032dc2af1ce19bef upstream. We used to assign 0 to x without an appropriate cast which results in sparse complaining when x is a pointer: >> block/ioctl.c:72:39: sparse: sparse: Using plain integer as NULL pointer So fix this by casting 0 to the correct type of x. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202508062321.gHv4kvuY-lkp@intel.com/ Fixes: f6bff7827a48 ("riscv: uaccess: use 'asm_goto_output' for get_user()") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti Reviewed-by: Clément Léger Reviewed-by: Cyril Bur Link: https://lore.kernel.org/r/20250903-dev-alex-sparse_warnings_v1-v1-1-7e6350beb700@rivosinc.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: kexec: Initialize kexec_buf struct

2025-09-09T17:02:40Z

commit 95c54cd9c769a198118772e196adfaa1f002e365 upstream. The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Signed-off-by: Breno Leitao Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250827-kbuf_all-v1-2-1df9882bb01a@debian.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv, bpf: use lw when reading int cpu in bpf_get_smp_processor_id

2025-09-09T17:02:40Z

commit 8a16586fa7b8a01360890d284896b90c217dca44 upstream. emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()") Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Reviewed-by: Pu Lehui Link: https://lore.kernel.org/r/20250812090256.757273-4-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv, bpf: use lw when reading int cpu in BPF_MOV64_PERCPU_REG

2025-09-09T17:02:40Z

commit ad5348c765914766a98ad26cf7a8c28d51a16bdd upstream. emit_ld is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 19c56d4e5be1 ("riscv, bpf: add internal-only MOV instruction to resolve per-CPU addrs") Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Reviewed-by: Pu Lehui Acked-by: Björn Töpel Tested-by: Björn Töpel # QEMU Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20250812090256.757273-3-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: use lw when reading int cpu in asm_per_cpu

2025-09-09T17:02:40Z

commit f4ea67a722e8c9e1fb8109adebb9fb881ff0793a upstream. REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: be97d0db5f44 ("riscv: VMAP_STACK overflow detection thread-safe") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Signed-off-by: Radim Krčmář Link: https://lore.kernel.org/r/20250725165410.2896641-5-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: use lw when reading int cpu in new_vmalloc_check

2025-09-09T17:02:40Z

commit e108c8a94f3f958c877f6ec7a6052a893ae4aa98 upstream. REG_L is wrong, because thread_info.cpu is 32-bit, not xlen-bit wide. The struct currently has a hole after cpu, so little endian accesses seemed fine. Fixes: 503638e0babf ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti Signed-off-by: Radim Krčmář Link: https://lore.kernel.org/r/20250725165410.2896641-4-rkrcmar@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

riscv: uaccess: fix __put_user_nocheck for unaligned accesses

2025-09-09T17:02:40Z

commit 1046791390af6703a5e24718a16f37974adb11db upstream. The type of the value to write should be determined by the size of the destination, not by the value itself, which may be a constant. This aligns the behavior with x86_64, where __typeof__(*(__gu_ptr)) is used to infer the correct type. This fixes an issue in put_cmsg, which was only writing 4 out of 8 bytes to the cmsg_len field, causing the glibc tst-socket-timestamp test to fail. Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()") Signed-off-by: Aurelien Jarno Reviewed-by: Alexandre Ghiti Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250724220853.1969954-1-aurelien@aurel32.net Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman