On Fri, May 16, 2025 at 04:18:55PM -0700, Eric Biggers wrote: > This series returns to my earlier suggestion to make x86 not support > kernel-mode FPU when hardirqs are disabled, aligning it with arm64 > (https://lore.kernel.org/r/20250220051325.340691-2-ebiggers@xxxxxxxxxx). > To make this possible despite the use of the kernel-mode FPU functions > by __save_processor_state() (which I mentioned at > https://lore.kernel.org/r/20250228035924.GC5588@sol.localdomain), I've > changed __save_processor_state() to use a new function instead of > (mis)using the kernel-mode FPU functions. > > This slightly reduces the overhead of kernel-mode FPU (since the result > is fewer checks), and it fixes the issue reported at > https://lore.kernel.org/r/20250516112217.GBaCcf6Yoc6LkIIryP@fat_crate.local/ > where irq_fpu_usable() incorrectly returned false during CPU > initialization, causing a crash in the SHA-256 library code. > > Eric Biggers (3): > x86/fpu: Add fpu_save_state() for __save_processor_state() > x86/pm: Use fpu_save_state() in __save_processor_state() > x86/fpu: Don't support kernel-mode FPU when irqs_disabled() > > arch/x86/include/asm/fpu/api.h | 1 + > arch/x86/kernel/fpu/core.c | 92 ++++++++++++++++++++-------------- > arch/x86/power/cpu.c | 18 +++---- > 3 files changed, 62 insertions(+), 49 deletions(-) I realized I forgot about EFI again. Ard had mentioned that earlier. I think we'll need a !irq_disabled()-safe solution for efi_fpu_begin(). It could be a different function from the regular kernel_fpu_begin(), though. - Eric
