Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

From: Ard Biesheuvel
Date: Mon Nov 09 2020 - 02:25:33 EST


On Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko <digetx@xxxxxxxxx> wrote:
>
> 03.11.2020 10:24, Ard Biesheuvel пишет:
> > Still broken today
> >
> > https://kernelci.org/build/id/5fa0c1a74bdb1ea4063fe7e4/
> >

Still broken today

https://kernelci.org/build/id/5fa898baa00b5f3167db8857/

> > So the options are
> >
> > a) merge my patch that adds 2 bytes of opcode to the Thumb2 build
> > b) merge Dmitry's patch that adds an unconditional literal load to all builds
> > c) remove kernel mode handling from vfp_support_entry() [my other patch]
> > d) move sections around so that vfp_kmode_exception is guaranteed to
> > be in range.
> > e) do nothing
> >
> > Given the lack of reports about this issue, it is pretty clear that
> > few people use the Thumb2 build (which I find odd, tbh, since it
> > really is much smaller).
>
> I waited for about a month, hoping that somebody will fix this problem
> before bothering with bisection, which took quite some time and effort
> because intermediate commits were broken, and then with creating and
> sending a patch :)
>
> Thumb2 usually is untested by CI farms and in a case of personal use
> it's easier to wait for a fix. Hence no much reports, I suppose.
>
> > However, that means that a) is a reasonable
> > fix, since nobody will notice the potential performance hit either,
> > and it can easily be backported to wherever the breakage was
> > introduced. (Note that eff8728fe698, which created the problem is
> > marked cc:stable itself).
>
> The performance argument is questionable to me, to be honest. In
> practice the performance difference should be absolutely negligible for
> either of the proposed options, it should stay in a noise even if
> somebody thoroughly counting cycles, IMO.
>
> I'm still thinking that the best option will be to apply a).
>

Can we take that as an acked-by?

> > Going forward, I can refine d) so that we can get rid of the kernel
> > mode path entirely.
>
> And then improve it using d).