Re: [PATCH 1/2] uaccess: unify inline vs outline copy_{from,to}_user() selection

[Yury Norov]

On Thu, Mar 26, 2026 at 02:44:40PM +0100, Christophe Leroy (CS GROUP) wrote:
> 
> 
> Le 25/03/2026 à 17:33, Yury Norov a écrit :
> > The kernel allows arches to select between inline and outline
> > implementations of the copy_{from,to}_user() by defining individual
> > INLINE_COPY_FROM_USER and INLINE_COPY_TO_USER, correspondingly.
> > However, all arches enable or disable them always together.
> > 
> > Without the real use-case for one helper being inlined while the other
> > outlined, having independent controls is excessive and error prone.
> > 
> > Switch the codebase to the single unified INLINE_COPY_USER control.
> 
> Could we use a (non user selectable) Kconfig item instead, e.g.
> CONFIG_ARCH_WANT_OUTLINE_USER_COPY ?

This sounds interesting. I need to wrap it around my head for a while.
Right now, I believe, the best solution is to isolate this setting
from the sources as much as we can, and your suggestion looks like a
step forward.

Overall, I'm puzzled why some arches enable this while the others
don't. The next question is why copy_{from,to}_user is so special.
If this function benefits from being inlined for that particular
arch or compiler, which functions would also benefit and why?

Reasoning logically, if this WANT_INLINE thing makes sense, it would
make much more sense if we create a machinery for something like:

        unsigned long __arch_inline copy_to_user();

> Also, looks like only powerpc doesn't select INLINE_COPY. Would it be
> cleaner to change the logic to a flag for OUTLINE_COPY ?

How that? x86_64 outlines it. Check it yourself:

  @@ -206,7 +206,9 @@ _inline_copy_to_user(void __user *to, const void *from, unsigned long n)
   #ifdef INLINE_COPY_USER
   # define _copy_to_user _inline_copy_to_user
   # define _copy_from_user _inline_copy_from_user
  +#error INLINE_COPY_USER
   #else
  +#error OUTLINE_COPY_USER
   extern __must_check unsigned long
   _copy_from_user(void *, const void __user *, unsigned long);

If it was really a single arch, it would be worth to discuss what for do
we need this customization at all.