kernel/linux.git/arch/arm/vfp, branch v6.12.80

ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros

2024-08-20T10:18:47+00:00

Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf("%fn", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c "import json" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20] <+152>: vmsr fpexc, r7 vmlinux.llvm.good [0xc0101d38] <+176>: vmrs r4, fpexc vmlinux.llvm.good [0xc0101d6c] <+228>: vmrs r0, fpscr vmlinux.llvm.good [0xc0101dc4] <+316>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101dc8] <+320>: vmrs r0, fpsid vmlinux.llvm.good [0xc0101dcc] <+324>: vmrs r6, fpscr vmlinux.llvm.good [0xc0101e10] <+392>: vmrs r10, fpinst vmlinux.llvm.good [0xc0101eb8] <+560>: vmrs r10, fpinst2 vmlinux.llvm.bad [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.bad [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.bad [0xc0101d20] <+152>: vmsr fpexc, r7 vmlinux.llvm.bad [0xc0101d30] <+168>: vmrs r0, fpscr vmlinux.llvm.bad [0xc0101d50] <+200>: vmrs r6, fpscr <== BOOM! vmlinux.llvm.bad [0xc0101d6c] <+228>: vmsr fpexc, r0 vmlinux.llvm.bad [0xc0101d70] <+232>: vmrs r0, fpsid vmlinux.llvm.bad [0xc0101da4] <+284>: vmrs r10, fpinst vmlinux.llvm.bad [0xc0101df8] <+368>: vmrs r4, fpexc vmlinux.llvm.bad [0xc0101e5c] <+468>: vmrs r10, fpinst2 I think LLVM's reordering is valid as the code is currently written: the compiler doesn't know the instructions have side effects in hardware. Fix by using "asm volatile" in fmxr() and fmrx(), so they cannot be reordered with respect to each other. The original compiler now produces working kernels on my hardware with DYNAMIC_DEBUG=n. This is the relevant piece of the diff of the vfp_support_entry() text, from the original oopsing kernel to a working kernel with this patch: vmrs r0, fpscr tst r0, #4096 bne 0xc0101d48 tst r0, #458752 beq 0xc0101ecc orr r7, r7, #536870912 ldr r0, [r4, #0x3c] mov r9, #16 -vmrs r6, fpscr orr r9, r9, #251658240 add r0, r0, #4 str r0, [r4, #0x3c] mvn r0, #159 sub r0, r0, #-1207959552 and r0, r7, r0 vmsr fpexc, r0 vmrs r0, fpsid +vmrs r6, fpscr and r0, r0, #983040 cmp r0, #65536 bne 0xc0101d88 Fixes: 4708fb041346 ("ARM: vfp: Reimplement VFP exception entry in C code") Signed-off-by: Calvin Owens Signed-off-by: Russell King (Oracle)

ARM: 9327/1: vfp: Add missing VFP instructions to neon_support_hook

2023-12-05T11:40:27+00:00

Add the missing "Unconditional Advanced SIMD and floating-point instructions" in [1] to the VFP undef hook. This commit addresses the issue reported in [2], where executing the vudot instruction on a platform with FEAT_DotProd support resulted in an undefined instruction error. Link: https://developer.arm.com/documentation/ddi0597/2023-06/?lang=en [1] Link: https://lore.kernel.org/lkml/20230920083907.30479-1-mark-pk.tsai@mediatek.com/ [2] Signed-off-by: Mark-PK Tsai Tested-by: Xuewen Yan Signed-off-by: Russell King (Oracle)

Merge branch 'devel-stable' into for-next

2023-08-14T11:18:06+00:00

Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm

2023-06-27T00:07:53+00:00

Pull ARM updates from Russell King: - lots of build cleanups from Arnd spread throughout the arch/arm tree - replace strlcpy() with the preferred strscpy() - use sign_extend32() in the module linker - drop handle_irq() machine descriptor method * tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 9315/1: fiq: include asm/mach/irq.h for prototypes ARM: 9314/1: tcm: move tcm_init() prototype to asm/tcm.h ARM: 9313/1: vdso: add missing prototypes ARM: 9312/1: vfp: include asm/neon.h in vfpmodule.c ARM: 9311/1: decompressor: move function prototypes to misc.h ARM: 9310/1: xip-kernel: add __inflate_kernel_data prototype ARM: 9309/1: add missing syscall prototypes ARM: 9308/1: move setup functions to header ARM: 9307/1: nommu: include asm/idmap.h ARM: 9306/1: cacheflush: avoid __flush_anon_page() missing-prototype warning ARM: 9305/1: add clear/copy_user_highpage declarations ARM: 9304/1: add prototype for function called only from asm ARM: 9303/1: kprobes: avoid missing-declaration warnings ARM: 9302/1: traps: hide unused functions on NOMMU ARM: 9301/1: dma-mapping: hide unused dma_contiguous_early_fixup function ARM: 9300/1: Replace all non-returning strlcpy with strscpy ARM: 9299/1: module: use sign_extend32() to extend the signedness ARM: 9298/1: Drop custom mdesc->handle_irq()

ARM: 9312/1: vfp: include asm/neon.h in vfpmodule.c

2023-06-19T08:35:58+00:00

Two functions defined here need the declaration in a header to avoid W=1 warnings: arch/arm/vfp/vfpmodule.c:735:6: error: no previous prototype for 'kernel_neon_begin' [-Werror=missing-prototypes] arch/arm/vfp/vfpmodule.c:768:6: error: no previous prototype for 'kernel_neon_end' [-Werror=missing-prototypes] Reviewed-by: Kees Cook Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle)

ARM: vfp: Use undef hook for handling VFP exceptions

2023-05-17T13:08:22+00:00

Now that the VFP support code has been reimplemented as a C function that takes a struct pt_regs pointer and an opcode, we can use the existing undef_hook framework to deal with undef exceptions triggered by VFP instructions instead of having special handling in assembler. Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel

ARM: vfp: Reimplement VFP exception entry in C code

2023-05-17T13:08:14+00:00

En/disabling softirqs from asm code turned out to be trickier than expected, so vfp_support_entry now returns by tail calling __local_enable_bh_ip() and passing the same arguments that a C call to local_bh_enable() would pass. However, this is slightly hacky, as we don't want to carry our own implementation of local_bh_enable(). So let's bite the bullet, and get rid of the asm logic in vfp_support_entry that reasons about whether or not to save and/or reload the VFP state, and about whether or not an FP exception is pending, and only keep the VFP loading logic as a function that is callable from C. Replicate the removed logic in vfp_entry(), and use the exact same reasoning as in the asm code. To emphasize the correspondence, retain some of the asm comments in the C version as well. Signed-off-by: Ard Biesheuvel Acked-by: Linus Walleij

ARM: vfp: Remove workaround for Feroceon CPUs

2023-05-17T11:11:38+00:00

Feroceon CPUs have a non-standard implementation of VFP which reports synchronous VFP exceptions using the async VFP flag. This requires a workaround which is difficult to reconcile with other implementations, making it tricky to support both versions in a single image. Since this is a v5 CPU, it is not supported by armhf and so the likelihood that anybody is using this with recent distros/kernels and rely on the VFP at the same time is extremely low. So let's just disable VFP support on these cores, so we can remove the workaround. This will help future development to support v5 and v6 CPUs with a single kernel image. Reviewed-by: Linus Walleij Acked-by: Nicolas Pitre Acked-by: Arnd Bergmann Signed-off-by: Ard Biesheuvel

ARM: vfp: Record VFP bounces as perf emulation faults

2023-05-16T18:24:08+00:00

VFP 'bouncing' occurs when the VFP unit cannot complete the execution of a VFP instruction, either because it is not implemented at all, or because the values of the arguments are out of range for the hardware implementation, and the software needs to step in to complete the operation. To give some insight in how much certain programs rely on this bouncing, record the emulation of a VFP instruction in perf's emulation-faults counter. This can be used like so perf stat -e emulation-faults ./testfloat -all2 and the output will be something like Performance counter stats for './testfloat -all2': 259,277 emulation-faults:u 6.846432176 seconds time elapsed Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel

ARM: 9297/1: vfp: avoid unbalanced stack on 'success' return path

2023-05-10T09:50:25+00:00

Commit c76c6c4ecbec0deb5 ("ARM: 9294/2: vfp: Fix broken softirq handling with instrumentation enabled") updated the VFP exception entry logic to go via a C function, so that we get the compiler's version of local_bh_disable(), which may be instrumented, and isn't generally callable from assembler. However, this assumes that passing an alternative 'success' return address works in C as it does in asm, and this is only the case if the C calls in question are tail calls, as otherwise, the stack will need some unwinding as well. I have already sent patches to the list that replace most of the asm logic with C code, and so it is preferable to have a minimal fix that addresses the issue and can be backported along with the commit that it fixes to v6.3 from v6.4. Hopefully, we can land the C conversion for v6.5. So instead of passing the 'success' return address as a function argument, pass the stack address from where to pop it so that both LR and SP have the expected value. Fixes: c76c6c4ecbec0deb5 ("ARM: 9294/2: vfp: Fix broken softirq handling with ...") Reported-by: syzbot+d4b00edc2d0c910d4bf4@syzkaller.appspotmail.com Tested-by: syzbot+d4b00edc2d0c910d4bf4@syzkaller.appspotmail.com Reviewed-by: Linus Walleij Tested-by: Andrew Lunn Signed-off-by: Ard Biesheuvel Tested-by: Andre Przywara Signed-off-by: Russell King (Oracle)