On Tue, 7 Oct 2025 at 13:52, Ard Biesheuvel <[email protected]> wrote: > > On Mon, 6 Oct 2025 at 12:59, Ard Biesheuvel <[email protected]> wrote: > > > > On Mon, 6 Oct 2025 at 19:42, Christian König <[email protected]> > > wrote: > > > > > > On 02.10.25 23:00, Ard Biesheuvel wrote: > > > > From: Ard Biesheuvel <[email protected]> > > > > > > > > The point of isolating code that uses kernel mode FPU in separate > > > > compilation units is to ensure that even implicit uses of, e.g., SIMD > > > > registers for spilling occur only in a context where this is permitted, > > > > i.e., from inside a kernel_fpu_begin/end block. > > > > > > > > This is important on arm64, which uses -mgeneral-regs-only to build all > > > > kernel code, with the exception of such compilation units where FP or > > > > SIMD registers are expected to be used. Given that the compiler may > > > > invent uses of FP/SIMD anywhere in such a unit, none of its code may be > > > > accessible from outside a kernel_fpu_begin/end block. > > > > > > > > This means that all callers into such compilation units must use the > > > > DC_FP start/end macros, which must not occur there themselves. For > > > > robustness, all functions with external linkage that reside there should > > > > call dc_assert_fp_enabled() to assert that the FPU context was set up > > > > correctly. > > > > > > Thanks a lot for that, I've pointed out this restriction before as well. > > > > > > Since we had that issue multiple times now would it be somehow possible > > > to automate rejecting new code getting this wrong? > > > > > > E.g. adding something to the DC_FP_START()/DC_FP_END() or > > > kernel_fpu_begin/end macros to make sure that they fail to compile on > > > compolation units where FP use is enabled? > > > > > > > Something like the below perhaps? > > > > Never mind, that doesn't work. dc_fpu_begin() is an out-of-line > function, and so it is the DC_FP_START() macro that evaluates to > something that includes an arch-provided assert. I'll code something > and send it out.
OK, so as it turns out, the logic already exists to force a build time error in this case. However, due to the way the amdgpu driver constructs its own API around kernel_fpu_begin() and kernel_fpu_end(), the logic never fires for the users for DC_FP_START. It is sufficient to include linux/fpu.h: diff --git a/drivers/gpu/drm/amd/display/dc/os_types.h b/drivers/gpu/drm/amd/display/dc/os_types.h index 782316348941..6ef9b7f5e099 100644 --- a/drivers/gpu/drm/amd/display/dc/os_types.h +++ b/drivers/gpu/drm/amd/display/dc/os_types.h @@ -32,6 +32,7 @@ #include <linux/delay.h> #include <linux/mm.h> #include <linux/vmalloc.h> +#include <linux/fpu.h> #include <asm/byteorder.h> Maybe this could be folded into this patch?
