* Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > Make irq_fpu_usable() return false when irqs_disabled(). That makes the > irqs_disabled() checks in kernel_fpu_begin_mask() and kernel_fpu_end() > unnecessary, so also remove those. > > Rationale: > > - There's no known use case for kernel-mode FPU when irqs_disabled(). Except EFI? > arm64 and riscv already disallow kernel-mode FPU when irqs_disabled(). > __save_processor_state() previously did expect kernel_fpu_begin() and > kernel_fpu_end() to work when irqs_disabled(), but this was a > different use case and not actual kernel-mode FPU use. > > - This is more efficient, since one call to irqs_disabled() replaces two > irqs_disabled() and one in_hardirq(). This is noise compared to the overhead of saving/restoring vector CPU context ... > - This fixes irq_fpu_usable() to correctly return false during CPU > initialization. Incorrectly returning true caused the SHA-256 library > code, which is called when loading AMD microcode, to take a > SIMD-optimized code path too early, causing a crash. By correctly > returning false from irq_fpu_usable(), the generic SHA-256 code > correctly gets used instead. (Note: SIMD-optimized SHA-256 doesn't > get enabled until subsys_initcall, but CPU hotplug can happen later.) Alternatively we could set in_kernel_fpu during CPU bootstrap, and clear it once we know the FPU is usable? This is only a relatively short early boot period, with no scheduling, right? Thanks, Ingo
