Re: [PATCH bpf-next 2/4] x86/fgraph,bpf: Switch kprobe_multi program stack unwind to hw_regs path

[Jiri Olsa <olsajiri@gmail.com>]

On Thu, Jan 15, 2026 at 10:52:04AM -0800, Andrii Nakryiko wrote:
> On Tue, Jan 13, 2026 at 3:43 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Mon, Jan 12, 2026 at 05:07:57PM -0500, Steven Rostedt wrote:
> > > On Mon, 12 Jan 2026 22:49:38 +0100
> > > Jiri Olsa <jolsa@kernel.org> wrote:
> > >
> > > > To recreate same stack setup for return probe as we have for entry
> > > > probe, we set the instruction pointer to the attached function address,
> > > > which gets us the same unwind setup and same stack trace.
> > > >
> > > > With the fix, entry probe:
> > > >
> > > >   # bpftrace -e 'kprobe:__x64_sys_newuname* { print(kstack)}'
> > > >   Attaching 1 probe...
> > > >
> > > >         __x64_sys_newuname+9
> > > >         do_syscall_64+134
> > > >         entry_SYSCALL_64_after_hwframe+118
> > > >
> > > > return probe:
> > > >
> > > >   # bpftrace -e 'kretprobe:__x64_sys_newuname* { print(kstack)}'
> > > >   Attaching 1 probe...
> > > >
> > > >         __x64_sys_newuname+4
> > > >         do_syscall_64+134
> > > >         entry_SYSCALL_64_after_hwframe+118
> > >
> > > But is this really correct?
> > >
> > > The stack trace of the return from __x86_sys_newuname is from offset "+4".
> > >
> > > The stack trace from entry is offset "+9". Isn't it confusing that the
> > > offset is likely not from the return portion of that function?
> >
> > right, makes sense.. so standard kprobe actualy skips attached function
> > (__x86_sys_newuname) on return probe stacktrace.. perhaps we should do
> > the same for kprobe_multi
> 
> but it is quite nice to see what function we were kretprobing,
> actually...

IIUC Steven doesn't like the wrong +offset that comes from entry probe,
maybe we could have func+(ADDRESS_OF_RET+1) ..but not sure how hard that
would be

still.. you always have the attached function ip when you get the stacktrace,
so I'm not sure how usefull it's to have it in stacktrace as well.. you can
always add it yourself


> How hard would it be to support that for singular kprobe
> as well? And what does fexit's stack trace show for such case?

I think we will get the bpf_program address, so we see the attached
function in stacktrace, will check

thanks,
jirka