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

Linux 6.12.46

2025-09-09T16:58:27Z

Link: https://lore.kernel.org/r/20250907195614.892725141@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Brett Mastbergen Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Harshit Mogalapalli Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()

2025-09-09T16:58:27Z

[ Upstream commit 8eba2187391e5ab49940cd02d6bd45a5617f4daf ] Fixed a flag reuse bug in the mtk_cqdma_tx_status() function. Fixes: 157ae5ffd76a ("dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()") Cc: stable@vger.kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202505270641.MStzJUfU-lkp@intel.com/ Signed-off-by: Qiu-ji Chen Reviewed-by: Eugen Hristev Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20250606090017.5436-1-chenqiuji666@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin

md/raid1: fix data lost for writemostly rdev

2025-09-09T16:58:27Z

[ Upstream commit 93dec51e716db88f32d770dc9ab268964fff320b ] If writemostly is enabled, alloc_behind_master_bio() will allocate a new bio for rdev, with bi_opf set to 0. Later, raid1_write_request() will clone from this bio, hence bi_opf is still 0 for the cloned bio. Submit this cloned bio will end up to be read, causing write data lost. Fix this problem by inheriting bi_opf from original bio for behind_mast_bio. Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") Reported-and-tested-by: Ian Dall Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220507 Link: https://lore.kernel.org/linux-raid/20250903014140.3690499-1-yukuai1@huaweicloud.com Signed-off-by: Yu Kuai Reviewed-by: Li Nan Signed-off-by: Sasha Levin

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

2025-09-09T16:58:26Z

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-09T16:58:26Z

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-09T16:58:26Z

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-09T16:58:26Z

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: Only allow LTO with CMODEL_MEDANY

2025-09-09T16:58:26Z

commit 41f9049cff324b7033e6ed1ded7dfff803cf550a upstream. When building with CONFIG_CMODEL_MEDLOW and CONFIG_LTO_CLANG, there is a series of errors due to some files being unconditionally compiled with '-mcmodel=medany', mismatching with the rest of the kernel built with '-mcmodel=medlow': ld.lld: error: Function Import: link error: linking module flags 'Code Model': IDs have conflicting values: 'i32 3' from vmlinux.a(init.o at 899908), and 'i32 1' from vmlinux.a(net-traces.o at 1014628) Only allow LTO to be performed when CONFIG_CMODEL_MEDANY is enabled to ensure there will be no code model mismatch errors. An alternative solution would be disabling LTO for the files with a different code model than the main kernel like some specialized areas of the kernel do but doing that for individual files is not as sustainable than forbidding the combination altogether. Cc: stable@vger.kernel.org Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506290255.KBVM83vZ-lkp@intel.com/ Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250710-riscv-restrict-lto-to-medany-v1-1-b1dac9871ecf@kernel.org Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

ACPI: RISC-V: Fix FFH_CPPC_CSR error handling

2025-09-09T16:58:26Z

commit 5b3706597b90a7b6c9ae148edd07a43531dcd49e upstream. The cppc_ffh_csr_read() and cppc_ffh_csr_write() returns Linux error code in "data->ret.error" so cpc_read_ffh() and cpc_write_ffh() must not use sbi_err_map_linux_errno() for FFH_CPPC_CSR. Fixes: 30f3ffbee86b ("ACPI: RISC-V: Add CPPC driver") Signed-off-by: Anup Patel Reviewed-by: Andrew Jones Reviewed-by: Troy Mitchell Reviewed-by: Sunil V L Reviewed-by: Nutty Liu Reviewed-by: Atish Patra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250818143600.894385-2-apatel@ventanamicro.com Signed-off-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman

md: prevent incorrect update of resync/recovery offset

2025-09-09T16:58:26Z

[ Upstream commit 7202082b7b7a256d04ec96131c7f859df0a79f64 ] In md_do_sync(), when md_sync_action returns ACTION_FROZEN, subsequent call to md_sync_position() will return MaxSector. This causes 'curr_resync' (and later 'recovery_offset') to be set to MaxSector too, which incorrectly signals that recovery/resync has completed, even though disk data has not actually been updated. To fix this issue, skip updating any offset values when the sync action is FROZEN. The same holds true for IDLE. Fixes: 7d9f107a4e94 ("md: use new helpers in md_do_sync()") Signed-off-by: Li Nan Link: https://lore.kernel.org/linux-raid/20250904073452.3408516-1-linan666@huaweicloud.com Signed-off-by: Yu Kuai Signed-off-by: Sasha Levin