On Tue, Feb 01, 2022 at 12:55:34PM -0800, Hao Luo wrote:
> +
> +SEC("iter/cgroup_view")
> +int dump_cgroup_lat(struct bpf_iter__cgroup_view *ctx)
> +{
> + struct seq_file *seq = ctx->meta->seq;
> + struct cgroup *cgroup = ctx->cgroup;
> + struct wait_lat *lat;
> + u64 id;
> +
> + BPF_SEQ_PRINTF(seq, "cgroup_id: %8lu\n", cgroup->kn->id);
> + lat = bpf_map_lookup_elem(&cgroup_lat, &id);
Looks like "id = cgroup->kn->id" assignment is missing here?
Thanks a lot for this test. It explains the motivation well.
It seems that the patches 1-4 are there to automatically
supply cgroup pointer into bpf_iter__cgroup_view.
Since user space needs to track good part of cgroup dir opreations
can we task it with the job of patches 1-4 as well?
It can register notifier for cgroupfs operations and
do mkdir in bpffs similarly _and_ parametrize 'view' bpf program
with corresponding cgroup_id.
Ideally there is no new 'view' program and it's a subset of 'iter'
bpf program. They're already parametrizable.
When 'iter' is pinned the user space can tell it which object it should
iterate on. The 'view' will be an interator of one element and
argument to it can be cgroup_id.
When user space pins the same 'view' program in a newly created bpffs
directory it will parametrize it with a different cgroup_id.
At the end the same 'view' program will be pinned in multiple directories
with different cgroup_id arguments.
This patch 5 will look very much the same, but patches 1-4 will not be
necessary.
Of course there are races between cgroup create/destroy and bpffs
mkdir, prog pin operatiosn, but they will be there regardless.
The patch 1-4 approach is not race free either.
Will that work?
