[PATCHv3 11/17] arm64: uaccess: refactor __{get,put}_user
Mark Rutland
mark.rutland at arm.com
Mon Nov 2 05:25:18 EST 2020
On Tue, Oct 27, 2020 at 06:03:19PM +0000, Robin Murphy wrote:
> On 2020-10-26 13:31, Mark Rutland wrote:
> > As a step towards implementing __{get,put}_kernel_nofault(), this patch
> > splits most user-memory specific logic out of __{get,put}_user(), with
> > the memory access and fault handling in new __{raw_get,put}_mem()
> > helpers.
> >
> > For now the LDR/LDTR patching is left within the *get_mem() helpers, and
> > will be removed in a subsequent patch.
> >
> > There should be no functional change as a result of this patch.
> >
> > Signed-off-by: Mark Rutland <mark.rutland at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Christoph Hellwig <hch at lst.de>
> > Cc: James Morse <james.morse at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > ---
> > arch/arm64/include/asm/uaccess.h | 40 +++++++++++++++++++++++++---------------
> > 1 file changed, 25 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index d6a4e496ebc64..4ad2990241d78 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -253,7 +253,7 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
> > * The "__xxx_error" versions set the third argument to -EFAULT if an error
> > * occurs, and leave it unchanged on success.
> > */
> > -#define __get_user_asm(instr, alt_instr, reg, x, addr, err, feature) \
> > +#define __get_mem_asm(instr, alt_instr, reg, x, addr, err, feature) \
> > asm volatile( \
> > "1:"ALTERNATIVE(instr " " reg "1, [%2]\n", \
> > alt_instr " " reg "1, [%2]\n", feature) \
> > @@ -268,35 +268,40 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
> > : "+r" (err), "=&r" (x) \
> > : "r" (addr), "i" (-EFAULT))
> > -#define __raw_get_user(x, ptr, err) \
> > +#define __raw_get_mem(x, ptr, err) \
> > do { \
> > unsigned long __gu_val; \
> > __chk_user_ptr(ptr); \
>
> Should this move out as well?
Yes, it looks like it should!
> It seems logical that wherever we figure out whether a pointer is
> "kernel" or "user" in order to call the appropriate low-level routine,
> the __user annotation could be dropped from the "kernel" path at that
> point - or have I misunderstood?
Agreed; I can't see any reason to keep this here, and it does look like
it's liable to cause sparse warnings when we add the kernel accsessors.
I'll shuffle this into the user wrappers.
Mark.
More information about the linux-arm-kernel
mailing list