All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@nvidia.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Alice Ryhl <aliceryhl@google.com>,
	Viktor Malik <vmalik@redhat.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	David Laight <david.laight.linux@gmail.com>,
	linux-kernel@vger.kernel.org, Yury Norov <yury.norov@gmail.com>
Subject: Re: [PATCH 1/2] uaccess: unify inline vs outline copy_{from,to}_user() selection
Date: Thu, 26 Mar 2026 13:29:09 -0400	[thread overview]
Message-ID: <acVsw4QQEuKzp9gF@yury> (raw)
In-Reply-To: <6ce733b4-5fae-49ac-ab0e-9c87e620e830@kernel.org>

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.

  reply	other threads:[~2026-03-26 17:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25 16:33 [PATCH 0/2] uaccess: unify inline vs outline copy_{from,to}_user() selection Yury Norov
2026-03-25 16:33 ` [PATCH 1/2] " Yury Norov
2026-03-26 13:44   ` Christophe Leroy (CS GROUP)
2026-03-26 17:29     ` Yury Norov [this message]
2026-03-26 17:49       ` Christophe Leroy (CS GROUP)
2026-03-25 16:33 ` [PATCH 2/2] uaccess: minimize INLINE_COPY_USER-related ifdefery Yury Norov
2026-03-26  8:00   ` Alice Ryhl
2026-03-26 14:15   ` Christophe Leroy (CS GROUP)
2026-04-24 19:50     ` Yury Norov
2026-04-25 10:37       ` Christophe Leroy (CS GROUP)
2026-03-25 23:31 ` [PATCH 0/2] uaccess: unify inline vs outline copy_{from,to}_user() selection Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acVsw4QQEuKzp9gF@yury \
    --to=ynorov@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=chleroy@kernel.org \
    --cc=david.laight.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=tglx@kernel.org \
    --cc=vmalik@redhat.com \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.