This patch doesn't *enable* the SVE optimized routines, but it does let
us see if switching them to ifuncs will cause any app compat issues, so
that we can more easily use the optimized routines in future.
Test: treehugger
Change-Id: Ic5fe570bd21687da397b48127bf688f7ec68dd0c
The MTE-compatible routines are now faster than the incompatible ones,
so they merged them upstream.
I've left the ifunc boilerplate on the assumption that I'll be back
later to enable the new SVE variants.
Test: treehugger
Change-Id: Ic894bfb350b9aa70e307bca1c4978624b3e5f4fd
Outsource this to them, and choose the best of the two options available
based on the hardware we're running on.
Test: treehugger
Change-Id: I2fa7555c971b64a6decca132210e901ffa248efa
Now that the feature guarded by this flag has landed in Linux 5.10
we no longer need the flag, so we can remove it.
Bug: 135772972
Change-Id: I02fa50848cbd0486c23c8a229bb8f1ab5dd5a56f
ARM has released the remaining MTE string routines, so let's start
using them. The strnlen implementation is now compatible with MTE,
so it no longer needs to be an ifunc.
Bug: 135772972
Change-Id: I9de7fb44447aa1b878f4ad3f62cb0129857b43ad
This includes optimized strrchr and strchrnul routines, and an MTE-compatible
strlen routine.
Bug: 135772972
Change-Id: I48499f757cdc6d3e77e5649123d45b17dfa3c6b0
As it turns out, our "generic" arm64 implementations of certain string.h
functions are not actually generic, since they will eagerly read memory
possibly outside of the bounds of an MTE granule, which may lead to a segfault
on MTE-enabled hardware. Therefore, move the implementations into a "default"
directory and use ifuncs to select between them and a new set of "mte"
implementations, conditional on whether the hardware and kernel support MTE.
The MTE implementations are currently naive implementations written in C
but will later be replaced with a set of optimized assembly implementations.
Bug: 135772972
Change-Id: Ife37c4e0e6fd60ff20a34594cc09c541af4d1dd7