Hi Tejun,
On Thu, Jul 28, 2022 at 9:51 AM Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> Hello,
>
> On Fri, Jul 22, 2022 at 05:48:25PM +0000, Yosry Ahmed wrote:
> > +
> > + /* cgroup_iter walks either the live descendants of a cgroup subtree, or the
> > + * ancestors of a given cgroup.
> > + */
> > + struct {
> > + /* Cgroup file descriptor. This is root of the subtree if walking
> > + * descendants; it's the starting cgroup if walking the ancestors.
> > + * If it is left 0, the traversal starts from the default cgroup v2
> > + * root. For walking v1 hierarchy, one should always explicitly
> > + * specify the cgroup_fd.
> > + */
> > + __u32 cgroup_fd;
>
> So, we're identifying the starting point with an fd.
>
> > + __u32 traversal_order;
> > + } cgroup;
> > };
> >
> > /* BPF syscall commands, see bpf(2) man-page for more details. */
> > @@ -6136,6 +6156,16 @@ struct bpf_link_info {
> > __u32 map_id;
> > } map;
> > };
> > + union {
> > + struct {
> > + __u64 cgroup_id;
> > + __u32 traversal_order;
> > + } cgroup;
>
> but iterating the IDs. IDs are the better choice for cgroup2 as there's
> nothing specific to the calling program or the fds it has, but I guess this
> is because you want to use it for cgroup1, right? Oh well, that's okay I
> guess.
>
Yes, we are identifying the starting point with FD. The cgroup_id here
is the information reported from kernel to userspace for identifying
the cgroup.
We use FD because it is a convention in BPF. Compatibility of cgroup1
is a good feature of this convention. My thoughts: It seems that ID
may be better, for two reasons. First, because ID is stateless, the
userspace doesn't have to remember closing the FD. Second, using
different identifications in two directions (userspace specifies
cgroup using FD, while kernel reports cgroup using ID) introduces a
little complexity when connecting them together.
Hao
> Acked-by: Tejun Heo <tj@xxxxxxxxxx>
>
> Thanks.
>
> --
> tejun
