arm64 memcpy+memove 5.10 patch

arm64 memcpy+memove 5.10 patch

[Nick Desaulniers]

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).
-- 
Thanks,
~Nick Desaulniers

Re: arm64 memcpy+memove 5.10 patch

[Robin Murphy]

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.

Thanks,
Robin.

Re: 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