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).
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.
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
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Nick Desaulniers -
Robin Murphy