[PATCH v2] ARM: entry: omit FP emulation for UND exceptions taken in kernel mode

[Dmitry Osipenko]

25.11.2020 10:00, Ard Biesheuvel пишет:
> On Tue, 24 Nov 2020 at 23:59, Dmitry Osipenko <digetx at gmail.com> wrote:
>>
>> 18.11.2020 16:08, Ard Biesheuvel пишет:
>>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>>> index c4220f51fcf3..0ea8529a4872 100644
>>> --- a/arch/arm/kernel/entry-armv.S
>>> +++ b/arch/arm/kernel/entry-armv.S
>>> @@ -252,31 +252,10 @@ __und_svc:
>>>  #else
>>>       svc_entry
>>>  #endif
>>> -     @
>>> -     @ call emulation code, which returns using r9 if it has emulated
>>> -     @ the instruction, or the more conventional lr if we are to treat
>>> -     @ this as a real undefined instruction
>>> -     @
>>> -     @  r0 - instruction
>>> -     @
>>> -#ifndef CONFIG_THUMB2_KERNEL
>>> -     ldr     r0, [r4, #-4]
>>> -#else
>>> -     mov     r1, #2
>>> -     ldrh    r0, [r4, #-2]                   @ Thumb instruction at LR - 2
>>> -     cmp     r0, #0xe800                     @ 32-bit instruction if xx >= 0
>>> -     blo     __und_svc_fault
>>> -     ldrh    r9, [r4]                        @ bottom 16 bits
>>> -     add     r4, r4, #2
>>> -     str     r4, [sp, #S_PC]
>>> -     orr     r0, r9, r0, lsl #16
>>> -#endif
>>> -     badr    r9, __und_svc_finish
>>> -     mov     r2, r4
>>> -     bl      call_fpe
>>>
>>>       mov     r1, #4                          @ PC correction to apply
>>> -__und_svc_fault:
>>> + THUMB(      tst     r5, #PSR_T_BIT          )       @ exception taken in Thumb mode?
>>> + THUMB(      movne   r1, #2                  )       @ if so, fix up PC correction
>>>       mov     r0, sp                          @ struct pt_regs *regs
>>>       bl      __und_fault
>>
>> Am I understanding correctly that when call_fpe was invoked previously,
>> it was supposed to print extra debug info about the VFP state? But it
>> didn't work properly for thumb mode, correct?
> 
> call_fpe was originally called to perform emulation of any UNDEF
> instruction that matched the same constraints that also apply when the
> UNDEF is taken in user mode. If the UNDEF was triggered by a VFP/NEON
> instruction, the VFP handler would check for kernel or user mode, and
> trigger an error if the exception was taken in kernel mode.
> 
> The Thumb mode opcode matching was wrong in this case, so if a Thumb2
> NEON exception triggered an UNDEF exception in kernel mode (which only
> happens if there are bugs in the kernel) we would fail to identify it
> as a NEON instruction.
> 
> This code removes the call into the emulation code from kernel mode
> entirely, as it no longer has valid users, and the invalid ones can
> simply be served by undef hooks.
> 

Thanks, that's a cleaner explanation in comparison to the commit
message. Would be nice to have an improved commit message, although
maybe not really worth the v3, either way:

Reviwed-by: Dmitry Osipenko <digetx at gmail.com>
Tested-by: Dmitry Osipenko <digetx at gmail.com>