public inbox for linuxppc-dev@ozlabs.org
 help / color / mirror / Atom feed
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Sayali Patil <sayalip@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com
Cc: aboorvad@linux.ibm.com, sshegde@linux.ibm.com,
	chleroy@kernel.org, riteshh@linux.ibm.com,
	hbathini@linux.ibm.com, ming.lei@redhat.com,
	csander@purestorage.com, czhong@redhat.com,
	venkat88@linux.ibm.com
Subject: Re: [PATCH v4 1/2] powerpc: fix KUAP warning in VMX usercopy path
Date: Mon, 09 Mar 2026 10:30:31 +0530	[thread overview]
Message-ID: <ecltlhqo.ritesh.list@gmail.com> (raw)

Sayali Patil <sayalip@linux.ibm.com> writes:

> On powerpc with PREEMPT_FULL or PREEMPT_LAZY and function tracing enabled,
> KUAP warnings can be triggered from the VMX usercopy path under memory
> stress workloads.
>
> KUAP requires that no subfunctions are called once userspace access has
> been enabled. The existing VMX copy implementation violates this
> requirement by invoking enter_vmx_usercopy() from the assembly path after
> userspace access has already been enabled. If preemption occurs
> in this window, the AMR state may not be preserved correctly,
> leading to unexpected userspace access state and resulting in
> KUAP warnings.
>
> Fix this by restructuring the VMX usercopy flow so that VMX selection
> and VMX state management are centralized in raw_copy_tofrom_user(),
> which is invoked by the raw_copy_{to,from,in}_user() wrappers.
>
> The new flow is:
>
>   - raw_copy_{to,from,in}_user() calls raw_copy_tofrom_user()
>   - raw_copy_tofrom_user() decides whether to use the VMX path
>     based on size and CPU capability
>   - Call enter_vmx_usercopy() before enabling userspace access
>   - Enable userspace access as per the copy direction
>     and perform the VMX copy
>   - Disable userspace access as per the copy direction
>   - Call exit_vmx_usercopy()
>   - Fall back to the base copy routine if the VMX copy faults
>
> With this change, the VMX assembly routines no longer perform VMX state
> management or call helper functions; they only implement the
> copy operations.
> The previous feature-section based VMX selection inside
> __copy_tofrom_user_power7() is removed, and a dedicated
> __copy_tofrom_user_power7_vmx() entry point is introduced.
>
> This ensures correct KUAP ordering, avoids subfunction calls
> while KUAP is unlocked, and eliminates the warnings while preserving
> the VMX fast path.
>
> Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection")
> Reported-by: Shrikanth Hegde <sshegde@linux.ibm.com>
> Closes: https://lore.kernel.org/all/20260109064917.777587-2-sshegde@linux.ibm.com/
> Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> Co-developed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
> ---

Thanks Sayali & Christophe for the help on this. I liked the new
wrappers which removed the code duplication by calling into a common
function call raw_copy_tofrom_user().

The new changes looks good to me too. Please feel free to add:

Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>



             reply	other threads:[~2026-03-09  5:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  5:00 Ritesh Harjani [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-03-04 12:22 [PATCH v4 1/2] powerpc: fix KUAP warning in VMX usercopy path Sayali Patil
2026-03-05  4:38 ` Venkat Rao Bagalkote
2026-03-09  5:27 ` Shrikanth Hegde
2026-03-15  4:01 ` Madhavan Srinivasan

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=ecltlhqo.ritesh.list@gmail.com \
    --to=ritesh.list@gmail.com \
    --cc=aboorvad@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=csander@purestorage.com \
    --cc=czhong@redhat.com \
    --cc=hbathini@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=ming.lei@redhat.com \
    --cc=riteshh@linux.ibm.com \
    --cc=sayalip@linux.ibm.com \
    --cc=sshegde@linux.ibm.com \
    --cc=venkat88@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox