On Thu, Aug 28, 2025 at 09:00:15AM -0700, Shakeel Butt wrote: > 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: > > > On Wed, Aug 27, 2025 at 04:34:48PM +0100, Lorenzo Stoakes wrote: > > > > > +__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. OK cool. The verifier aspect of this is really nice... :) > > > > > 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. OK. > > > > > 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. Ack yeah as per above. > > > > > 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. This would be nice indeed!
