On Sun, Nov 19, 2023 at 6:06 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
>
> On Sun, 2023-11-19 at 18:00 -0800, Alexei Starovoitov wrote:
> > On Fri, Nov 17, 2023 at 5:34 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
> > >
> > > diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
> > > index 7def320aceef..71b7c7c39cea 100644
> > > --- a/include/linux/bpf_verifier.h
> > > +++ b/include/linux/bpf_verifier.h
> > > @@ -301,6 +301,15 @@ struct bpf_func_state {
> > > struct tnum callback_ret_range;
> > > bool in_async_callback_fn;
> > > bool in_exception_callback_fn;
> > > + /* For callback calling functions that limit number of possible
> > > + * callback executions (e.g. bpf_loop) keeps track of current
> > > + * simulated iteration number. When non-zero either:
> > > + * - current frame has a child frame, in such case it's callsite points
> > > + * to callback calling function;
> > > + * - current frame is a topmost frame, in such case callback has just
> > > + * returned and env->insn_idx points to callback calling function.
> > > + */
> > > + u32 callback_depth;
> >
> > The first part of the comment makes sense, but the second...
> > What are you trying to explain with the second part ?
> > How does the knowledge of insn_idx help here ? or helps to
> > understand the rest of the patch?
>
> The intent was to explain that 'callback_depth' in frame N refers to
> number of times callback with frame N+1 was simulated, e.g.:
>
> bpf_loop(..., fn, ...); | suppose current frame is N
> | fn would be simulated in frame N+1
> | number of simulations is tracked in frame N
I see. Pls use this instead. Much clearer :)
