Re: [RFC PATCH v2 bpf-next 0/3] bpf: cgroup: support writing and freezing cgroups from BPF

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, Aug 20, 2025 at 12:31:01AM +0100, Djalal Harouni wrote:
...
> Approach 1:
> First RFC months ago was something like that "bpf_task_freeze_cgroup" [1],
> can make it bpf_cgroup_freeze() as a proper kfunc, so resurrect approach 1?

Thanks for reminding me. I often feel like my memory is a ring buffer which
lasts a few weeks at most.

> Internally it used an ugly path to workaround kernfs active reference since
> we don't hold a kernfs_open_file coming from userspace
> kernfs->write path.
> 
> I can improve it, but let's discuss please approach (2) since you
> suggested it ;-)
> 
> Approach 2:
> Per the old suggestions from you and Alexei [2] [3] you wanted something
> like:
> 
>   s32 bpf_kernfs_knob_write(struct kernfs_node *dir,
>                             const char *knob, char *buf);
> 
> I didn't make it generic for kernfs, since don't know yet about sysfs use
> cases and named it "bpf_cgroup_write_interface" to focus on cgroup base
> interfaces.
> Doing something that generic now including sysfs without a proper valid use
> cases seems a bit too much. Also we have some cgroup kfunc to acquire and
> release that integrate well, so I kept it focused.
> 
> Alexei suggested to refactor the cgroup_base_file[] [4][5] to take
> "kernfs_node" as argument instead of "kernfs_open_file", which will open
> other possibilities for BPF.
> 
> However, instead of going full change on cgroup_base_files[], I added a
> minimalist: cgroup_kn_cftype kn_cfts[] that for now hold only
> "cgroup.freeze".

I think there's some misunderstanding here. IIUC, Alexei didn't want to
expose direct file interface because none of the necessary abstractions are
available and the effort becomes too big and wide. However, I don't think
the suggestion to use @kn as the path designator (or @cgroup for that
matter) means that we want to pipe that all the way down to each op that's
to be written to. That'd be rather pointless - why add generic interface if
each needs a dedicated backend anyway? Can't you make kernfs to create
open_file from kn and follow the usual write path?

Thanks.

-- 
tejun