[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-xQAyPxQGvlg_hd@gmail.com>
Date: Tue, 1 Apr 2025 22:43:47 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: mingo@...hat.com, x86@...nel.org, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Uros Bizjak <ubizjak@...il.com>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86: predict __access_ok() returning true
* Ingo Molnar <mingo@...nel.org> wrote:
> It's also the right place to have the hint: that user addresses are
> valid is the common case we optimize for.
>
> Thanks,
>
> Ingo
>
> arch/x86/include/asm/uaccess_64.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/uaccess_64.h b/arch/x86/include/asm/uaccess_64.h
> index c52f0133425b..4c13883371aa 100644
> --- a/arch/x86/include/asm/uaccess_64.h
> +++ b/arch/x86/include/asm/uaccess_64.h
> @@ -54,7 +54,7 @@ static inline unsigned long __untagged_addr_remote(struct mm_struct *mm,
> #endif
>
> #define valid_user_address(x) \
> - ((__force unsigned long)(x) <= runtime_const_ptr(USER_PTR_MAX))
> + likely((__force unsigned long)(x) <= runtime_const_ptr(USER_PTR_MAX))
Should we go this way, this is the safe macro variant:
#define valid_user_address(x) \
(likely((__force unsigned long)(x) <= runtime_const_ptr(USER_PTR_MAX)))
But this compiler bug sounds weird ...
Thanks,
Ingo
Powered by blists - more mailing lists