On Tue, 3 Nov 2020 at 09:43, Dmitry Osipenko <dig...@gmail.com> 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).