kernel/linux.git/arch, branch v6.1.70

x86/alternatives: Sync core before enabling interrupts

2024-01-01T12:39:08+00:00

commit 3ea1704a92967834bf0e64ca1205db4680d04048 upstream. text_poke_early() does: local_irq_save(flags); memcpy(addr, opcode, len); local_irq_restore(flags); sync_core(); That's not really correct because the synchronization should happen before interrupts are re-enabled to ensure that a pending interrupt observes the complete update of the opcodes. It's not entirely clear whether the interrupt entry provides enough serialization already, but moving the sync_core() invocation into interrupt disabled region does no harm and is obviously correct. Fixes: 6fffacb30349 ("x86/alternatives, jumplabel: Use text_poke_early() before mm_init()") Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Acked-by: Peter Zijlstra (Intel) Cc: Link: https://lore.kernel.org/r/ZT6narvE%2BLxX%2B7Be@windriver.com Signed-off-by: Greg Kroah-Hartman

KVM: arm64: vgic: Force vcpu vgic teardown on vcpu destroy

2024-01-01T12:39:08+00:00

commit 02e3858f08faabab9503ae2911cf7c7e27702257 upstream. When failing to create a vcpu because (for example) it has a duplicate vcpu_id, we destroy the vcpu. Amusingly, this leaves the redistributor registered with the KVM_MMIO bus. This is no good, and we should properly clean the mess. Force a teardown of the vgic vcpu interface, including the RD device before returning to the caller. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20231207151201.3028710-4-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman

KVM: arm64: vgic: Add a non-locking primitive for kvm_vgic_vcpu_destroy()

2024-01-01T12:39:08+00:00

commit d26b9cb33c2d1ba68d1f26bb06c40300f16a3799 upstream. As we are going to need to call into kvm_vgic_vcpu_destroy() without prior holding of the slots_lock, introduce __kvm_vgic_vcpu_destroy() as a non-locking primitive of kvm_vgic_vcpu_destroy(). Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20231207151201.3028710-3-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman

KVM: arm64: vgic: Simplify kvm_vgic_destroy()

2024-01-01T12:39:08+00:00

commit 01ad29d224ff73bc4e16e0ef9ece17f28598c4a4 upstream. When destroying a vgic, we have rather cumbersome rules about when slots_lock and config_lock are held, resulting in fun buglets. The first port of call is to simplify kvm_vgic_map_resources() so that there is only one call to kvm_vgic_destroy() instead of two, with the second only holding half of the locks. For that, we kill the non-locking primitive and move the call outside of the locking altogether. This doesn't change anything (we re-acquire the locks and teardown the whole vgic), and simplifies the code significantly. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20231207151201.3028710-2-maz@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman

RISC-V: Fix do_notify_resume / do_work_pending prototype

2024-01-01T12:39:05+00:00

[ Upstream commit 285b6a18daf1358e70a4c842884d9ff2d2fe53e2 ] Commit b0f4c74eadbf ("RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path") renamed the do_notify_resume function to do_work_pending but did not change the prototype in signal.h Do that now, as the original function does not exist anymore. Fixes: b0f4c74eadbf ("RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path") Signed-off-by: Heiko Stuebner Reviewed-by: Andrew Jones Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20230118142252.337103-1-heiko@sntech.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin

x86/xen: add CPU dependencies for 32-bit build

2024-01-01T12:38:59+00:00

[ Upstream commit 93cd0597649844a0fe7989839a3202735fb3ae67 ] Xen only supports modern CPUs even when running a 32-bit kernel, and it now requires a kernel built for a 64 byte (or larger) cache line: In file included from : In function 'xen_vcpu_setup', inlined from 'xen_vcpu_setup_restore' at arch/x86/xen/enlighten.c:111:3, inlined from 'xen_vcpu_restore' at arch/x86/xen/enlighten.c:141:3: include/linux/compiler_types.h:435:45: error: call to '__compiletime_assert_287' declared with attribute error: BUILD_BUG_ON failed: sizeof(*vcpup) > SMP_CACHE_BYTES arch/x86/xen/enlighten.c:166:9: note: in expansion of macro 'BUILD_BUG_ON' 166 | BUILD_BUG_ON(sizeof(*vcpup) > SMP_CACHE_BYTES); | ^~~~~~~~~~~~ Enforce the dependency with a whitelist of CPU configurations. In normal distro kernels, CONFIG_X86_GENERIC is enabled, and this works fine. When this is not set, still allow Xen to be built on kernels that target a 64-bit capable CPU. Fixes: db2832309a82 ("x86/xen: fix percpu vcpu_info allocation") Signed-off-by: Arnd Bergmann Reviewed-by: Juergen Gross Tested-by: Alyssa Ross Link: https://lore.kernel.org/r/20231204084722.3789473-1-arnd@kernel.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin

s390/vx: fix save/restore of fpu kernel context

2024-01-01T12:38:53+00:00

[ Upstream commit e6b2dab41888332bf83f592131e7ea07756770a4 ] The KERNEL_FPR mask only contains a flag for the first eight vector registers. However floating point registers overlay parts of the first sixteen vector registers. This could lead to vector register corruption if a kernel fpu context uses any of the vector registers 8 to 15 and is interrupted or calls a KERNEL_FPR context. If that context uses also vector registers 8 to 15, their contents will be corrupted on return. Luckily this is currently not a real bug, since the kernel has only one KERNEL_FPR user with s390_adjust_jiffies() and it is only using floating point registers 0 to 2. Fix this by using the correct bits for KERNEL_FPR. Fixes: 7f79695cc1b6 ("s390/fpu: improve kernel_fpu_[begin|end]") Signed-off-by: Heiko Carstens Reviewed-by: Hendrik Brueckner Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin

ARM: OMAP2+: Fix null pointer dereference and memory leak in omap_soc_device_init

2024-01-01T12:38:53+00:00

[ Upstream commit c72b9c33ef9695ad7ce7a6eb39a9df8a01b70796 ] kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. When 'soc_dev_attr->family' is NULL,it'll trigger the null pointer dereference issue, such as in 'soc_info_show'. And when 'soc_device_register' fails, it's necessary to release 'soc_dev_attr->family' to avoid memory leaks. Fixes: 6770b2114325 ("ARM: OMAP2+: Export SoC information to userspace") Signed-off-by: Kunwu Chan Message-ID: <20231123145237.609442-1-chentao@kylinos.cn> Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

ARM: dts: dra7: Fix DRA7 L3 NoC node register size

2024-01-01T12:38:53+00:00

[ Upstream commit 1e5caee2ba8f1426e8098afb4ca38dc40a0ca71b ] This node can access any part of the L3 configuration registers space, including CLK1 and CLK2 which are 0x800000 offset. Restore this area size to include these areas. Fixes: 7f2659ce657e ("ARM: dts: Move dra7 l3 noc to a separate node") Signed-off-by: Andrew Davis Message-ID: <20231113181604.546444-1-afd@ti.com> Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin

bpf: Fix prog_array_map_poke_run map poke update

2024-01-01T12:38:52+00:00

commit 4b7de801606e504e69689df71475d27e35336fb3 upstream. Lee pointed out issue found by syscaller [0] hitting BUG in prog array map poke update in prog_array_map_poke_run function due to error value returned from bpf_arch_text_poke function. There's race window where bpf_arch_text_poke can fail due to missing bpf program kallsym symbols, which is accounted for with check for -EINVAL in that BUG_ON call. The problem is that in such case we won't update the tail call jump and cause imbalance for the next tail call update check which will fail with -EBUSY in bpf_arch_text_poke. I'm hitting following race during the program load: CPU 0 CPU 1 bpf_prog_load bpf_check do_misc_fixups prog_array_map_poke_track map_update_elem bpf_fd_array_map_update_elem prog_array_map_poke_run bpf_arch_text_poke returns -EINVAL bpf_prog_kallsyms_add After bpf_arch_text_poke (CPU 1) fails to update the tail call jump, the next poke update fails on expected jump instruction check in bpf_arch_text_poke with -EBUSY and triggers the BUG_ON in prog_array_map_poke_run. Similar race exists on the program unload. Fixing this by moving the update to bpf_arch_poke_desc_update function which makes sure we call __bpf_arch_text_poke that skips the bpf address check. Each architecture has slightly different approach wrt looking up bpf address in bpf_arch_text_poke, so instead of splitting the function or adding new 'checkip' argument in previous version, it seems best to move the whole map_poke_run update as arch specific code. [0] https://syzkaller.appspot.com/bug?extid=97a4fe20470e9bc30810 Fixes: ebf7d1f508a7 ("bpf, x64: rework pro/epilogue and tailcall handling in JIT") Reported-by: syzbot+97a4fe20470e9bc30810@syzkaller.appspotmail.com Signed-off-by: Jiri Olsa Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Cc: Lee Jones Cc: Maciej Fijalkowski Link: https://lore.kernel.org/bpf/20231206083041.1306660-2-jolsa@kernel.org Signed-off-by: Greg Kroah-Hartman