From: Andrew Morton <akpm@linux-foundation.org>
To: Jordan Rome <linux@jordanrome.com>
Cc: bpf@vger.kernel.org, linux-mm@kvack.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Kernel Team <kernel-team@fb.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Alexander Potapenko <glider@google.com>
Subject: Re: [bpf-next v8 1/3] mm: add copy_remote_vm_str
Date: Wed, 19 Feb 2025 16:18:21 -0800 [thread overview]
Message-ID: <20250219161821.6f05272f1a3131ddfe978865@linux-foundation.org> (raw)
In-Reply-To: <20250213152125.1837400-1-linux@jordanrome.com>
On Thu, 13 Feb 2025 07:21:23 -0800 Jordan Rome <linux@jordanrome.com> wrote:
> Similar to `access_process_vm` but specific to strings.
> Also chunks reads by page and utilizes `strscpy`
> for handling null termination.
>
> The primary motivation for this change is to copy
> strings from a non-current task/process in BPF.
> There is already a helper `bpf_copy_from_user_task`,
> which uses `access_process_vm` but one to handle
> strings would be very helpful.
>
> ...
>
> include/linux/mm.h | 3 ++
> mm/memory.c | 122 +++++++++++++++++++++++++++++++++++++++++++++
> mm/nommu.c | 76 ++++++++++++++++++++++++++++
Is there any way in which we can avoid adding all this to vmlinux if
it's unneeded?
Any such ifdeffery would of course need removal or alteration if
callers other than BPF emerge.
> ...
>
> +/*
> + * 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,
> + void *buf, int len, unsigned int gup_flags)
> +{
> + void *old_buf = buf;
> + int err = 0;
> +
> + *(char *)buf = '\0';
> +
> + if (mmap_read_lock_killable(mm))
> + return -EFAULT;
> +
> + /* Untag the address before looking up the VMA */
> + addr = untagged_addr_remote(mm, addr);
Well that's a crappy little comment which you copied-n-pasted. It
tells us "what" (which is utterly obvious) but not "why". whodidthat.
> +/**
> + * copy_remote_vm_str - copy a string from another process's address space.
> + * @tsk: the task of the target address space
> + * @addr: start address to read from
> + * @buf: destination buffer
> + * @len: number of bytes to copy
> + * @gup_flags: flags modifying lookup behaviour
> + *
> + * The caller must hold a reference on @mm.
> + *
> + * Return: number of bytes copied from @addr (source) to @buf (destination);
> + * not including the trailing NUL. Always guaranteed to leave NUL-terminated
> + * buffer. On any error, return -EFAULT.
> + */
> +int copy_remote_vm_str(struct task_struct *tsk, unsigned long addr,
> + void *buf, int len, unsigned int gup_flags)
> +{
> + struct mm_struct *mm;
> + int ret;
> +
> + if (unlikely(len < 1))
> + return 0;
I wonder if this can ever happen. And if it does, should it WARN? And
returen -Efoo?
> + mm = get_task_mm(tsk);
> + if (!mm) {
> + *(char *)buf = '\0';
> + return -EFAULT;
> + }
> +
> + ret = __copy_remote_vm_str(mm, addr, buf, len, gup_flags);
> +
> + mmput(mm);
> +
> + return ret;
> +}
next prev parent reply other threads:[~2025-02-20 0:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 15:21 Jordan Rome
2025-02-13 15:21 ` [bpf-next v8 2/3] bpf: Add bpf_copy_from_user_task_str kfunc Jordan Rome
2025-02-13 15:21 ` [bpf-next v8 3/3] selftests/bpf: Add tests for bpf_copy_from_user_task_str Jordan Rome
2025-02-21 15:00 ` Marcus Wichelmann
2025-02-21 18:26 ` Andrii Nakryiko
2025-02-22 13:19 ` Marcus Wichelmann
2025-02-19 23:33 ` [bpf-next v8 1/3] mm: add copy_remote_vm_str Shakeel Butt
2025-02-20 0:19 ` Andrew Morton
2025-02-20 1:02 ` Andrii Nakryiko
2025-02-20 11:22 ` Jordan Rome
2025-02-20 0:18 ` Andrew Morton [this message]
2025-02-20 1:02 ` Andrii Nakryiko
2025-02-20 1:20 ` patchwork-bot+netdevbpf
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=20250219161821.6f05272f1a3131ddfe978865@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=glider@google.com \
--cc=kernel-team@fb.com \
--cc=linux-mm@kvack.org \
--cc=linux@jordanrome.com \
--cc=shakeel.butt@linux.dev \
/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