[PATCH] RFC: riscv: evaluate put_user() arg before enabling user access

[Christoph Hellwig]

On Thu, Mar 18, 2021 at 10:41:35PM +0000, Ben Dooks wrote:
> The <asm/uaccess.h> header has a problem with
> put_user(a, ptr) if the 'a' is not a simple
> variable, such as a function. This can lead
> to the compiler producing code as so:

Nit: your commit log seeems to truncate lines after 50 chars, you can
and should use almost 1.5 as much.

>   * @ptr must have pointer-to-simple-variable type, and @x must be assignable
> - * to the result of dereferencing @ptr.
> + * to the result of dereferencing @ptr. The @x is copied inside the macro
> + * to avoid code re-ordering where @x gets evaulated within the block that
> + * enables user-space access (thus possibly bypassing some of the protection
> + * this feautre provides).

Well, hopefully the compiler is smart enought to not actually copy.
So we should probably talk about evaluating the argument here.

>  #define __put_user(x, ptr)					\
>  ({								\
>  	__typeof__(*(ptr)) __user *__gu_ptr = (ptr);		\
> +	__typeof__(*__gu_ptr) __val = (x);			\
>  	long __pu_err = 0;					\
>  								\
>  	__chk_user_ptr(__gu_ptr);				\
>  								\
>  	__enable_user_access();					\
> -	__put_user_nocheck(x, __gu_ptr, __pu_err);		\
> +	__put_user_nocheck(__val, __gu_ptr, __pu_err);		\
>  	__disable_user_access();				\

It looks like __get_user needs the same treatment.