arm64 memcpy+memove 5.10 patch

[Greg KH]

On Tue, Mar 08, 2022 at 11:11:38PM +0000, Robin Murphy wrote:
> On 2022-03-08 22:38, Nick Desaulniers wrote:
> > Dear stable kernel maintainers,
> > Please consider cherry-picking
> > 
> > commit 6c23d54f4cb8 ("arm64: Import latest memcpy()/memmove() implementation")
> > 
> > to v5.10.y.  It first landed in v5.14-rc1.
> > 
> > It fixes a linkage failure observed when building kernels for ChromeOS
> > under AutoFDO:
> > 
> > ld.lld: error: arch/arm64/lib/lib.a(memmove.o):(function __memmove:
> > .text+0x8): relocation R_AARCH64_CONDBR19 out of range: -6331272 is
> > not in [-1048576, 1048575]; references __memcpy
> > > > > defined in arch/arm64/lib/lib.a(memcpy.o)
> > 
> > (The prior version of memmove used assembler conditional branches to
> > memcpy; under AutoFDO the linker will decide where best to place
> > memmove; it may be > 1MB away from memcpy. After this patch, memcpy
> > and memmove are the same function).
> 
> Just beware that the new implementation turned out to be really good at
> finding places where __iomem pointers are erroneously being passed to
> memcpy(), by more readily triggering alignment faults, so there is a
> non-zero possibility of functional regressions if any of those places are
> still present in 5.10.y (particularly any which had "naturally" disappeared
> before 5.14). At least one of them still isn't fixed in mainline, but that
> one's so obscure I wouldn't consider it a major concern by itself.

Yeah, because of this, I'm a bit nervous to add this change to the
stable tree.  ChromeOS can keep it in their tree as they "know" they
have properly audited all of their drivers to get this right and they
can own the fallout if they didn't :)

thanks,

greg k-h