arm64: Remove useless UAO IPI and describe how this gets enabled
authorJames Morse <james.morse@arm.com>
Mon, 9 Jan 2017 18:14:02 +0000 (18:14 +0000)
committerWill Deacon <will.deacon@arm.com>
Tue, 10 Jan 2017 12:38:06 +0000 (12:38 +0000)
commitc8b06e3fddddaae1a87ed479edcb8b3d85caecc7
treeff55ee6357ef78ade4faeeef4cd36d688dd18907
parent510224c2b10aba2149c0d24595be98f2254c641a
arm64: Remove useless UAO IPI and describe how this gets enabled

Since its introduction, the UAO enable call was broken, and useless.
commit 2a6dcb2b5f3e ("arm64: cpufeature: Schedule enable() calls instead
of calling them via IPI"), fixed the framework so that these calls
are scheduled, so that they can modify PSTATE.

Now it is just useless. Remove it. UAO is enabled by the code patching
which causes get_user() and friends to use the 'ldtr' family of
instructions. This relies on the PSTATE.UAO bit being set to match
addr_limit, which we do in uao_thread_switch() called via __switch_to().

All that is needed to enable UAO is patch the code, and call schedule().
__apply_alternatives_multi_stop() calls stop_machine() when it modifies
the kernel text to enable the alternatives, (including the UAO code in
uao_thread_switch()). Once stop_machine() has finished __switch_to() is
called to reschedule the original task, this causes PSTATE.UAO to be set
appropriately. An explicit enable() call is not needed.

Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
arch/arm64/include/asm/processor.h
arch/arm64/kernel/cpufeature.c
arch/arm64/mm/fault.c