On Fri, Jan 16, 2026 at 8:25 AM Jiri Olsa <[email protected]> wrote: > > On Thu, Jan 15, 2026 at 10:52:04AM -0800, Andrii Nakryiko wrote: > > On Tue, Jan 13, 2026 at 3:43 AM Jiri Olsa <[email protected]> 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 <[email protected]> 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
You can, but that's a custom thing that every single tool has to implement. Having traced function right there in the stack would be so nice and convenient. I don't insist, but I'm just saying that practically speaking this would make sense. Even conceptually, kretprobe is (logically) called from traced function right before exit. In reality it's not exactly like that and we don't know where ret happened, but having traced function in kretprobe's stack trace is more useful than confusing, IMO. But again, I just found it interesting that we could have it, if we wanted to. > > > > 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
