Re: [PATCH bpf-next 1/2] bpf: add new BPF_CGROUP_ITER_CHILDREN_ONLY control option

[Matt Bobrowski <mattbobrowski@google.com>]

On Thu, Jan 22, 2026 at 08:26:49PM -0800, Alexei Starovoitov wrote:
> On Wed, Jan 21, 2026 at 5:54 AM Matt Bobrowski <mattbobrowski@google.com> wrote:
> >
> >                 break;
> > +       case BPF_CGROUP_ITER_CHILDREN_ONLY:
> > +               kit->pos = css_next_child(kit->pos, kit->start);
> > +               break;
>
> There are no users of css_next_child() outside of cgroup
> internals. It's a red flag for me.

Hm, I can see the slight hesitation here. However, until somewhat
recently, the same argument could have been applied to functions like
css_next_descendant_post(), right?

css_next_descendant_post() has rather recently started seeing usage in
other subsystems (block/, kernel/sched/, kernel/bpf), despite
remaining internal-only since its inception over a decade ago. Given
that css_next_descendant_post() continues to remain unexported, in all
fairness, I don't see css_next_child() being all that different in
this context.

Would your stance change if Tejun agreed to mark css_next_child() as
exportable, or simply agreed to it being used from BPF cgroup
iterators?

Both css_next_child() and css_for_each_child() have remained virtually
unchanged - and therefore inherently stable - since their
introduction. I should also mention that functions like
css_next_child() and css_next_descendant_post() were originally marked
as exported, and only later unmarked. This presumably was done as part
of a symbol cleanup, not because the functions were unstable
primitives.

> I feel there is something wrong with the use case. It should have
> been handled by the primitives we have.

Right, arguably it could be handled with the current set of
primitives, but it isn't nice and certainly not as efficient as I'd
like.