From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>,
bpf@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, akpm@linux-foundation.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, eddyz87@gmail.com,
memxor@gmail.com, kpsingh@kernel.org, matt@bobrowski.net,
song@kernel.org, utilityemal77@gmail.com,
sun.jian.kdev@gmail.com, "Lorenzo Stoakes (Arm)" <ljs@kernel.org>
Subject: Re: [PATCH bpf-next v4 1/7] mm: Add copy_remote_mm_str()
Date: Mon, 7 Sep 2026 12:59:57 +0200 [thread overview]
Message-ID: <0e4edfd3-0c82-42e0-ad09-19ff8b8d1511@kernel.org> (raw)
In-Reply-To: <20260904145340.40212-2-tasos.papagiannnis@gmail.com>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index ed3934bc2de4..94e3709e95fd 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1716,13 +1716,16 @@ EXPORT_SYMBOL_GPL(access_process_vm);
> * Copy a string from another process's address space as given in mm.
> * If there is any error return -EFAULT.
> */
> -static int __copy_remote_vm_str(struct mm_struct *mm, unsigned long addr,
> +static int __copy_remote_mm_str(struct mm_struct *mm, unsigned long addr,
> void *buf, int len)
> {
> unsigned long addr_end;
> struct vm_area_struct *vma;
> int ret = -EFAULT;
>
> + if (unlikely(len == 0))
> + return 0;
We have this check in copy_remote_vm_str(). Why are we performing the check now
twice?
It should either go only into __copy_remote_mm_str(), or if there a reason to
have it before get_task_mm(), it should go into copy_remote_mm_str(). Same
applies to the memory.c case.
> +
> *(char *)buf = '\0';
>
> if (mmap_read_lock_killable(mm))
> @@ -1752,6 +1755,27 @@ static int __copy_remote_vm_str(struct mm_struct *mm, unsigned long addr,
> return ret;
> }
>
> +/**
> + * copy_remote_mm_str - copy a string from a remote address space.
> + * @mm: the remote address space
> + * @addr: start address to read from
> + * @buf: destination buffer
> + * @len: number of bytes to copy
> + * @gup_flags: flags modifying lookup behaviour (unused)
> + *
> + * The caller must hold a reference on @mm.
> + *
> + * Return: number of bytes copied from @addr (source) to @buf (destination),
> + * not including the trailing NUL. If @len is zero, return 0 without accessing
> + * @buf. Otherwise, @buf is always NUL-terminated. On any error, return
> + * -EFAULT.
> + */
> +int copy_remote_mm_str(struct mm_struct *mm, unsigned long addr,
> + void *buf, int len, unsigned int gup_flags)
> +{
> + return __copy_remote_mm_str(mm, addr, buf, len);
> +}
What's more annoying is that both implementations of copy_remote_vm_str() are
identical, and both implementations of copy_remote_mm_str() are nearly identical
(just dropping the gup_flags for nommu). I'd like to avoid duplicating code for
nommu.
If we could export __copy_remote_vm_str(mm, addr, buf, len, gup_flags) for both
cases, we could instead provide a single implementation for copy_remote_vm_str()
and copy_remote_mm_str() e.g., in mm.h? (I'd prefer somewhere else, but we don't
seem to have a good git for memory.c + nommu.c shared stuff)
Now, that's also not completely nice, as I don't want us to EXPORT
__copy_remote_vm_str() ... given that these functions are "#ifdef
CONFIG_BPF_SYSCALL" could we EXPORT_SYMBOL_FOR_MODULES?
Just a thought. CCing Lorenzo.
--
Cheers,
David
next prev parent reply other threads:[~2026-09-07 11:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 14:53 [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 1/7] mm: Add copy_remote_mm_str() Anastasios Papagiannis
2026-09-07 10:59 ` David Hildenbrand (Arm) [this message]
2026-09-07 13:41 ` Anastasios Papagiannis
2026-09-07 14:01 ` Lorenzo Stoakes (ARM)
2026-09-07 14:04 ` David Hildenbrand (Arm)
2026-09-04 14:53 ` [PATCH bpf-next v4 2/7] exec: Clear bprm->mm before dropping its reference Anastasios Papagiannis
2026-09-04 15:20 ` sashiko-bot
2026-09-04 15:30 ` Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 3/7] bpf: Add user memory access kfuncs for mm_struct Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 4/7] bpf: Allow reads through trusted-or-null BTF pointers Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 5/7] selftests/bpf: Cover trusted-or-null BTF pointer reads Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 6/7] bpf: Mark linux_binprm->mm as trusted-or-null Anastasios Papagiannis
2026-09-04 14:53 ` [PATCH bpf-next v4 7/7] selftests/bpf: Test mm_struct user memory kfuncs with linux_binprm Anastasios Papagiannis
2026-09-04 18:26 ` [PATCH bpf-next v4 0/7] bpf: Add user memory access kfuncs for mm_struct Andrew Morton
2026-09-07 6:58 ` Anastasios Papagiannis
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=0e4edfd3-0c82-42e0-ad09-19ff8b8d1511@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=sun.jian.kdev@gmail.com \
--cc=tasos.papagiannnis@gmail.com \
--cc=utilityemal77@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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.