Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	 Daniel Borkmann <daniel@iogearbox.net>,
	bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
	 Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	linux-mm@kvack.org,  Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	 linux-kselftest@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
	 John Fastabend <john.fastabend@gmail.com>
Subject: Re: [RFC bpf-next 3/9] mm: Expose locked mprotect operation
Date: Thu, 22 Oct 2026 11:25:31 +0100	[thread overview]
Message-ID: <atnjEc2-6CuKjFzH@gremlin> (raw)
In-Reply-To: <20261021195759.119421-4-jolsa@kernel.org>

On Wed, Oct 21, 2026 at 09:57:52PM +0200, Jiri Olsa wrote:
> The bpf_user_page_exec() in following patch needs to change page
> protections while holding current->mm's mmap write lock.
>
> Exposing the do_mprotect_pkey_locked helper for that.

Err, we'll need some more justification than this for exposing internal mm
logic to the rest of the kernel please.

Note that you're already allowing any caller to bypass
CONFIG_ARCH_HAS_PKEYS here which is immediately a broken thing.

>
> Assisted-by: Codex:GPT-6
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>

It's a no to this in its current form.

> ---
>  include/linux/mm.h |  3 +++
>  mm/mprotect.c      | 20 +++++++++++++++-----
>  2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 63f40e615754..47e853093601 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3435,6 +3435,9 @@ extern long change_protection(struct mmu_gather *tlb,
>  extern int mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb,
>  	  struct vm_area_struct *vma, struct vm_area_struct **pprev,
>  	  unsigned long start, unsigned long end, vm_flags_t newflags);
> +/* Caller must hold current->mm's mmap write lock. */
> +int do_mprotect_pkey_locked(unsigned long start, size_t len,
> +			    unsigned long prot, int pkey);
>
>  /*
>   * doesn't attempt to fault and will return short.
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 2888ee638d87..8d800830d3e1 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -868,8 +868,8 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb,
>  /*
>   * pkey==-1 when doing a legacy mprotect()
>   */
> -static int do_mprotect_pkey(unsigned long start, size_t len,
> -		unsigned long prot, int pkey)
> +int do_mprotect_pkey_locked(unsigned long start, size_t len,
> +			    unsigned long prot, int pkey)
>  {
>  	unsigned long nstart, end, tmp, reqprot;
>  	struct vm_area_struct *vma, *prev;
> @@ -899,8 +899,7 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
>
>  	reqprot = prot;
>
> -	if (mmap_write_lock_killable(current->mm))
> -		return -EINTR;
> +	mmap_assert_write_locked(current->mm);
>
>  	/*
>  	 * If userspace did not allocate the pkey, do not let
> @@ -1013,10 +1012,21 @@ static int do_mprotect_pkey(unsigned long start, size_t len,
>  		error = -ENOMEM;
>
>  out:
> -	mmap_write_unlock(current->mm);
>  	return error;
>  }
>
> +static int do_mprotect_pkey(unsigned long start, size_t len,
> +			    unsigned long prot, int pkey)
> +{
> +	int ret;
> +
> +	if (mmap_write_lock_killable(current->mm))
> +		return -EINTR;
> +	ret = do_mprotect_pkey_locked(start, len, prot, pkey);
> +	mmap_write_unlock(current->mm);
> +	return ret;
> +}
> +
>  SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
>  		unsigned long, prot)
>  {
> --
> 2.54.0
>

--
Cheers, Lorenzo

  parent reply	other threads:[~2026-10-22 10:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 19:57 [RFC bpf-next 0/9] bpf: Add support to allocate user page Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 1/9] bpf: Add __srcptr kfunc argument suffix Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 2/9] bpf: Add uprobe faultable user copy kfunc Jiri Olsa
2026-10-21 20:30   ` bot+bpf-ci
2026-10-21 19:57 ` [RFC bpf-next 3/9] mm: Expose locked mprotect operation Jiri Olsa
2026-10-21 20:30   ` bot+bpf-ci
2026-10-22 10:25   ` Lorenzo Stoakes (ARM) [this message]
2026-10-22 19:39     ` Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 4/9] bpf: Add kfuncs to allocate and seal user pages Jiri Olsa
2026-10-21 20:41   ` bot+bpf-ci
2026-10-21 19:57 ` [RFC bpf-next 5/9] selftests/bpf: Add __srcptr kfunc arguments test Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 6/9] selftests/bpf: Add user page allocation test Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 7/9] selftests/bpf: Add uprobe user page exec test Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 8/9] selftests/bpf: Add faultable user page writes test Jiri Olsa
2026-10-21 19:57 ` [RFC bpf-next 9/9] selftests/bpf: Add user page failures test Jiri Olsa
2026-10-21 20:30   ` bot+bpf-ci
2026-10-21 21:53 ` [RFC bpf-next 0/9] bpf: Add support to allocate user page Alexei Starovoitov
2026-10-22 10:01   ` Jiri Olsa
2026-10-22 10:27   ` Lorenzo Stoakes (ARM)

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=atnjEc2-6CuKjFzH@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=memxor@gmail.com \
    --cc=shuah@kernel.org \
    /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