On Wed, Feb 03, 2021 at 09:31:31PM +0000, Will Deacon wrote: > On Wed, 3 Feb 2021 12:36:17 +0100, Ard Biesheuvel wrote: > > Given how kernel mode NEON code disables preemption (to ensure that the > > FP/SIMD register state is protected without having to context switch it), > > we need to take care not to let those algorithms operate on unbounded > > input data, or we may end up with excessive scheduling blackouts on > > CONFIG_PREEMPT kernels. > > > > This is currently handled by the cond_yield_neon macros, which check the > > preempt count and the TIF_NEED_RESCHED flag from assembler code, and call > > into kernel_neon_end()+kernel_neon_begin(), triggering a reschedule. > > This works as expected, but is a bit messy, given how much of the state > > preserve/restore code in the algorithm needs to be duplicated, as well as > > causing the need to manage the stack frame explicitly. All of this is better > > handled by the compiler, especially now that we have enabled features such > > as the shadow call stack and BTI, and are working to improve call stack > > validation. > > > > [...] > > Applied first patch only to arm64 (for-next/crypto), thanks!
Oops, looks like I typo'd the external branch (for-next/crypo). No offense intended! I'll rename it now; SHAs will stay the same. Will
