Re: [PATCH v5 3/6] arm64: remove uaccess_ttbr0 asm macros from cache functions

[Will Deacon]

On Thu, Jan 02, 2020 at 04:13:54PM -0500, Pavel Tatashin wrote:
> We currently duplicate the logic to enable/disable uaccess via TTBR0,
> with C functions and assembly macros. This is a maintenenace burden
> and is liable to lead to subtle bugs, so let's get rid of the assembly
> macros, and always use the C functions. This requires refactoring
> some assembly functions to have a C wrapper.
> 
> Signed-off-by: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
> ---
>  arch/arm64/include/asm/asm-uaccess.h | 22 ----------------
>  arch/arm64/include/asm/cacheflush.h  | 39 +++++++++++++++++++++++++---
>  arch/arm64/mm/cache.S                | 36 ++++++++++---------------
>  arch/arm64/mm/flush.c                |  2 +-
>  4 files changed, 50 insertions(+), 49 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
> index f68a0e64482a..fba2a69f7fef 100644
> --- a/arch/arm64/include/asm/asm-uaccess.h
> +++ b/arch/arm64/include/asm/asm-uaccess.h
> @@ -34,28 +34,6 @@
>  	msr	ttbr0_el1, \tmp1		// set the non-PAN TTBR0_EL1
>  	isb
>  	.endm
> -
> -	.macro	uaccess_ttbr0_disable, tmp1, tmp2
> -alternative_if_not ARM64_HAS_PAN
> -	save_and_disable_irq \tmp2		// avoid preemption
> -	__uaccess_ttbr0_disable \tmp1
> -	restore_irq \tmp2
> -alternative_else_nop_endif
> -	.endm
> -
> -	.macro	uaccess_ttbr0_enable, tmp1, tmp2, tmp3
> -alternative_if_not ARM64_HAS_PAN
> -	save_and_disable_irq \tmp3		// avoid preemption
> -	__uaccess_ttbr0_enable \tmp1, \tmp2
> -	restore_irq \tmp3
> -alternative_else_nop_endif
> -	.endm
> -#else
> -	.macro	uaccess_ttbr0_disable, tmp1, tmp2
> -	.endm
> -
> -	.macro	uaccess_ttbr0_enable, tmp1, tmp2, tmp3
> -	.endm
>  #endif
>  
>  #endif
> diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
> index 665c78e0665a..cb00c61e0bde 100644
> --- a/arch/arm64/include/asm/cacheflush.h
> +++ b/arch/arm64/include/asm/cacheflush.h
> @@ -61,16 +61,49 @@
>   *		- kaddr  - page address
>   *		- size   - region size
>   */
> -extern void __flush_icache_range(unsigned long start, unsigned long end);
> -extern int  invalidate_icache_range(unsigned long start, unsigned long end);
> +extern void __asm_flush_icache_range(unsigned long start, unsigned long end);
> +extern long __asm_flush_cache_user_range(unsigned long start,
> +					 unsigned long end);
> +extern int  __asm_invalidate_icache_range(unsigned long start,
> +					  unsigned long end);
>  extern void __flush_dcache_area(void *addr, size_t len);
>  extern void __inval_dcache_area(void *addr, size_t len);
>  extern void __clean_dcache_area_poc(void *addr, size_t len);
>  extern void __clean_dcache_area_pop(void *addr, size_t len);
>  extern void __clean_dcache_area_pou(void *addr, size_t len);
> -extern long __flush_cache_user_range(unsigned long start, unsigned long end);
>  extern void sync_icache_aliases(void *kaddr, unsigned long len);
>  
> +static inline long __flush_cache_user_range(unsigned long start,
> +					    unsigned long end)
> +{
> +	int ret;
> +
> +	uaccess_ttbr0_enable();
> +	ret = __asm_flush_cache_user_range(start, end);
> +	uaccess_ttbr0_disable();
> +
> +	return ret;
> +}
> +
> +static inline void __flush_icache_range(unsigned long start, unsigned long end)
> +{
> +	uaccess_ttbr0_enable();
> +	__asm_flush_icache_range(start, end);
> +	uaccess_ttbr0_disable();
> +}

Interesting... I don't think we should be enabling uaccess here: the
function has a void return type so we can't communicate failure back to the
caller if we fault, so my feeling is that this should only ever be called on
kernel addresses.

> +
> +static inline int invalidate_icache_range(unsigned long start,
> +					  unsigned long end)
> +{
> +	int ret;
> +
> +	uaccess_ttbr0_enable();
> +	ret = __asm_invalidate_icache_range(start, end);
> +	uaccess_ttbr0_disable();
> +
> +	return ret;
> +}

Same here -- I don't think think this is ever called on user addresses.
Can we make the return type void and drop the uaccess toggle?

Will