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

[Ard Biesheuvel]

On Wed, 18 Nov 2020 at 18:08, Nick Desaulniers <ndesaulniers at google.com> wrote:
>
> On Wed, Nov 18, 2020 at 9:00 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > On Wed, 18 Nov 2020 at 17:59, Nick Desaulniers <ndesaulniers at google.com> wrote:
> > >
> > > On Wed, Nov 18, 2020 at 8:48 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > > >
> > > > On Wed, 18 Nov 2020 at 17:42, Nick Desaulniers <ndesaulniers at google.com> wrote:
> > > > >
> > > > > On Wed, Nov 18, 2020 at 5:09 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> > > > > >
> > > > > > There are a couple of problems with the exception entry code that deals
> > > > > > with FP exceptions (which are reported as UND exceptions) when building
> > > > > > the kernel in Thumb2 mode:
> > > > > > - the conditional branch to vfp_kmode_exception in vfp_support_entry()
> > > > > >   may be out of range for its target, depending on how the linker decides
> > > > > >   to arrange the sections;
> > > > > > - when the UND exception is taken in kernel mode, the emulation handling
> > > > > >   logic is entered via the 'call_fpe' label, which means we end up using
> > > > > >   the wrong value/mask pairs to match and detect the NEON opcodes.
> > > > > >
> > > > > > Since UND exceptions in kernel mode are unlikely to occur on a hot path
> > > > > > (as opposed to the user mode version which is invoked for VFP support
> > > > > > code and lazy restore), we can use the existing undef hook machinery for
> > > > >
> > > > > Right, I'd expect these maybe from userspace, but within the kernel?
> > > > >
> > > >
> > > > Russell explained off-list that there used to be a case in the pre-VFP
> > > > era, but this is no longer relevant.
> > >
> > > If the use case is no longer relevant, consider dropping support.
> > > Dead code is technical debt.
> > >
> >
> > Dropping support for what?
>
> By `there used to be a case`, I interpret "a case" to mean one case,
> singular.  "but this is no longer relevant" seems to imply that
> singular case is not an issue anymore.
>

Indeed. Dropping support for the special FP case is precisely what I
am proposing here. The only remaining option to handle an undef
exception in kernel mode is via undef hooks, and those are not going
away.

> If what you're referring to is "UND exceptions in kernel mode," then I
> guess we need exception handling support for those, even if they occur
> less frequently than the "pre-VFP era" alluded to.  So nvm

No worries. Thanks for the review.