On Fri, Aug 9, 2024 at 12:14 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Thu, 2024-08-08 at 16:22 -0700, Andrii Nakryiko wrote:
> > There are potentially useful cases where a specific iterator type might
> > need to be passed into some kfunc. So, in addition to existing
> > bpf_iter_<type>_{new,next,destroy}() kfuncs, allow to pass iterator
> > pointer to any kfunc.
> >
> > We employ "__iter" naming suffix for arguments that are meant to accept
> > iterators. We also enforce that they accept PTR -> STRUCT btf_iter_<type>
> > type chain and point to a valid initialized on-the-stack iterator state.
> >
> > Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
> > ---
>
> In current form this allows the following usage:
>
> SEC("?socket")
> __success
> int testmod_seq_getter_good(const void *ctx)
> {
> struct bpf_iter_testmod_seq it;
> s64 sum = 0;
>
> bpf_iter_testmod_seq_new(&it, 100, 100);
> sum *= bpf_iter_testmod_seq_value(0, &it);
> bpf_iter_testmod_seq_destroy(&it);
>
> return sum;
> }
>
> Do we want to ensure that iterator is not drained before the call to
> bpf_iter_testmod_seq_value()?
>
I'm not sure I follow your question. Drained or not it's still a valid
iterator state. I don't want to put any restrictions, the user is free
to pass it at any point between new and destroy.
> Otherwise this patch lgtm.
>
> [...]
>
