Re: [RFC PATCH bpf-next] bpf: ephemeral cgroup BPF control programs

[Tejun Heo <tj@kernel.org>]

Hello, Rohan.

On Tue, Feb 03, 2026 at 10:20:55AM +0000, Rohan Kakulawaram wrote:
...
> One of the main gaps in achieving these ends, however, is that
> there is no infrastructure that supports exposing per cgroup data
> via file paths that mirror the cgroupfs hierarchy. This would
> allow for a unified source of truth as it relates to accessing
> various streams of data related to cgroups. It is important to
> note that we would want the fate of these ephemeral files to be
> tied to the manipulation of the cgroup tree, such as exposing/
> deleting files when creating/removing cgroups respectively.
> Cgroup iterators can mimic some of this functionality through
> bpffs pins but lack the dynamism of the listed approach.

On one hand, I think why not, but at the same time, I'm having a hard time
why this would need to be on some file system. After all, we're talking
about BPF, there are numerous way lower overhead ways to do bi-directional
communication - shared pinned maps, BPF upcalls, BPF seqfile iterator, ring
buffer based interface and so on.

Can you elaborate why this *needs* to be a separate file interface? Note
that this doesn't really expand what BPF progs can do with cgroups. The only
thing being added is a different and not-particularly-efficient way to
communicate with BPF progs.

Thanks.

-- 
tejun