Thread (61 messages) flat view 61 messages, 8 authors, 2025-09-03

Re: [PATCH v6 mm-new 02/10] mm: thp: add a new kfunc bpf_mm_get_mem_cgroup()

From: Shakeel Butt <shakeel.butt@linux.dev>
Date: 2025-08-28 16:00:39
Also in: bpf, linux-doc

On Thu, Aug 28, 2025 at 11:40:16AM +0100, Lorenzo Stoakes wrote:
On Wed, Aug 27, 2025 at 01:50:18PM -0700, Shakeel Butt wrote:
quoted
On Wed, Aug 27, 2025 at 04:34:48PM +0100, Lorenzo Stoakes wrote:
quoted
quoted
+__bpf_kfunc_start_defs();
+
+/**
+ * bpf_mm_get_mem_cgroup - Get the memory cgroup associated with a mm_struct.
+ * @mm: The mm_struct to query
+ *
+ * The obtained mem_cgroup must be released by calling bpf_put_mem_cgroup().
+ *
+ * Return: The associated mem_cgroup on success, or NULL on failure. Note that
+ * this function depends on CONFIG_MEMCG being enabled - it will always return
+ * NULL if CONFIG_MEMCG is not configured.
What kind of locking is assumed here?

Are we protected against mmdrop() clearing out the mm?
No locking is needed. Just the valid mm object or NULL. Usually the
underlying function (get_mem_cgroup_from_mm) is called in page fault
context where the current is holding mm. Here the only requirement is
that mm is valid either through explicit reference or the context.
I mean this may be down to me being not so familiar with BPF, but my concern is
that we're handing _any_ mm here.
It's not really any mm but rather the mm whose validity is ensured by
the caller. I don't know the BPF internals but if I understand Andrii's
response on other email, the BPF verifier will make sure the BPF program
is holding a valid mm on which it is calling this function. In non-BPF
world, get_mem_cgroup_from_mm() assumes the caller is providing a valid
mm.
So presumably this could also be a remote mm?
Which is fine as we already do this today i.e. page fault on accessing
memory of a remote process.
If not then why are we accepting an mm parameter at all, when we could just grab
current->mm?
Because current->mm might not be equal to the faulting mm as in the case
of remote page fault.
If it's a remote mm, then we need to be absolutely sure that we won't UAF.

I also feel we should talk about this in the kdoc, unless BPF always somehow
asserts these things to be the case + verifies them smoehow.
Yeah some text on how BPF verifier is making sure that the BPF program
is handling a valid mm.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help