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.
