Re: [PATCHv2 bpf-next 09/11] bpf: Remove trace_in argument from __bpf_get_stack

Andrii Nakryiko <[email protected]> Mon, 3 Aug 2026 10:45:22 -0700
Newsgroups org.kernel.vger.bpf
Message-ID <CAEf4BzapkhvCiAhPC-A7yYfYKn0cwcv3RTmJ8SCgn1+_WmNOMQ@mail.gmail.com>
On Mon, Aug 3, 2026 at 12:37=E2=80=AFAM Jiri Olsa <[email protected]> wrot=
e:
>
> On Fri, Jul 31, 2026 at 08:14:03AM -0700, Andrii Nakryiko wrote:
> > On Fri, Jul 31, 2026 at 6:33=E2=80=AFAM Jiri Olsa <[email protected]> =
wrote:
> > >
> > > On Thu, Jul 30, 2026 at 04:06:14PM -0700, Andrii Nakryiko wrote:
> > >
> > > SNIP
> > >
> > > > >  BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_event_data_kern *, =
ctx,
> > > > >            void *, buf, u32, size, u64, flags)
> > > > >  {
> > > > > @@ -947,7 +970,7 @@ BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_=
event_data_kern *, ctx,
> > > > >         int err =3D -EINVAL;
> > > > >
> > > > >         if (!(event->attr.sample_type & PERF_SAMPLE_CALLCHAIN))
> > > > > -               return __bpf_get_stack(regs, NULL, NULL, buf, siz=
e, flags, false /* !may_fault */);
> > > > > +               return __bpf_get_stack(regs, NULL, buf, size, fla=
gs, false /* !may_fault */);
> > > > >
> > > > >         if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER=
_STACK |
> > > > >                                BPF_F_USER_BUILD_ID)))
> > > > > @@ -966,7 +989,7 @@ BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_=
event_data_kern *, ctx,
> > > > >
> > > > >         if (kernel) {
> > > > >                 trace->nr =3D nr_kernel;
> > > >
> > > > this whole count_kernel_ip() logic above, why do we have it? I don'=
t
> > > > think we can have combined user and kernel stack trace, so how can =
we
> > > > end up with PERF_CONTEXT_USER "ip" at all? I might be missing
> > >
> > > the callchain comes from perf event's callchain and that can
> > > have both kernel and user part
> >
> > in general, but bpf_get_stack and bpf_get_stackid never request both
> > kernel and user stack trace in one go and we set add_mark to false, so
> > we can't have PERF_CONTEXT_USER, which is why I am asking what's the
> > deal with this nr_kernel calculation.
>
> it's the bpf_get_stack_pe helper for perf event and we store the
> callchain before we run bpf program in bpf_overflow_handler:
>
>   perf_prepare_sample(data, event, regs);
>    -> perf_sample_save_callchain
>       -> perf_callchain
>          -> get_perf_callchain(... add_mark=3Dtrue ..)
>
>   ret =3D bpf_prog_run(prog, &ctx);
>    -> bpf_get_stack_pe
>       -> trace =3D ctx->data->callchain
>
> the perf event setup is independent of bpf_get_stack execution,
> so you can have PERF_CONTEXT_USER in the callchain
>

oh, I didn't realize that's what happens, thanks, never mind then!

> jirka
>
>
> >
> > If it's unnecessary, we should just drop that part and not have that
> > extra unnecessary complication
> >
> > >
> > > > something subtle here, but can you please check again if this whole
> > > > trace->nr calculation/override is even necessary.
> > >
> > > as I wrote in the other reply I don't think we need to change
> > > trace->nr directly, just pass the needed nr/count as argument
> > >
> > > jirka
> > >
> > > >
> > > > > -               err =3D __bpf_get_stack(regs, NULL, trace, buf, s=
ize, flags, false /* !may_fault */);
> > > > > +               err =3D __bpf_get_stack_pe(trace, buf, size, flag=
s);
> > > > >
> > > > >         } else { /* user */
> > > > >                 u64 skip =3D flags & BPF_F_SKIP_FIELD_MASK;
> > > > > @@ -974,9 +997,8 @@ BPF_CALL_4(bpf_get_stack_pe, struct bpf_perf_=
event_data_kern *, ctx,
> > > > >                 skip +=3D nr_kernel;
> > > > >                 if (skip > BPF_F_SKIP_FIELD_MASK)
> > > > >                         goto clear;
> > > > > -
> > > > >                 flags =3D (flags & ~BPF_F_SKIP_FIELD_MASK) | skip=
;
> > > > > -               err =3D __bpf_get_stack(regs, NULL, trace, buf, s=
ize, flags, false /* !may_fault */);
> > > > > +               err =3D __bpf_get_stack_pe(trace, buf, size, flag=
s);
> > > > >         }
> > > > >
> > > > >         /* restore nr */
> > > > > --
> > > > > 2.54.0
> > > > >