On Mon, Sep 11, 2023 at 8:31 PM Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
>
> On Tue, Sep 12, 2023 at 4:24 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
> >
> > On Sun, Sep 10, 2023 at 11:17:48AM +0800, Yafang Shao wrote:
> > > To acquire the cgroup_id, we can resort to open coding, as exemplified below:
> > >
> > > task = bpf_get_current_task_btf();
> > > cgroups = task->cgroups;
> > > cgroup = cgroups->subsys[cpu_cgrp_id]->cgroup;
> > > key = cgroup->kn->id;
> >
> > You can't hardcode it to a specific controller tree like that. You either
> > stick with fd based interface or need also add something to identify the
> > specifc cgroup1 tree.
>
> As pointed out by Alexei, I think we can introduce some
> cgroup_id-based kfuncs which can work for both cgroup1 and cgroup2.
>
> Something as follows (untested),
>
> __bpf_kfunc u64 bpf_current_cgroup_id_from_subsys(int subsys)
> {
> struct cgroup *cgroup;
>
> cgroup = task_cgroup(current, subsys);
> if (!cgroup)
> return 0;
> return cgroup_id(cgroup);
> }
>
Can we also support checking arbitrary tasks, instead of just current?
I find myself often needing to find the cgroup only given a
task_struct. For example, when attaching to context switch, I want to
know whether the next task is under a cgroup. Having such a kfunc
would be very useful. It can also be used in task_iter programs.
Hao
