[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 3/6] arm64: remove uaccess_ttbr0 asm macros from cache functions
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |