On Tue, Jun 4, 2024 at 7:13 AM Masami Hiramatsu <[email protected]> wrote: > > On Tue, 21 May 2024 18:38:43 -0700 > Andrii Nakryiko <[email protected]> wrote: > > > When kernel has pending uretprobes installed, it hijacks original user > > function return address on the stack with a uretprobe trampoline > > address. There could be multiple such pending uretprobes (either on > > different user functions or on the same recursive one) at any given > > time within the same task. > > > > This approach interferes with the user stack trace capture logic, which > > would report suprising addresses (like 0x7fffffffe000) that correspond > > to a special "[uprobes]" section that kernel installs in the target > > process address space for uretprobe trampoline code, while logically it > > should be an address somewhere within the calling function of another > > traced user function. > > > > This is easy to correct for, though. Uprobes subsystem keeps track of > > pending uretprobes and records original return addresses. This patch is > > using this to do a post-processing step and restore each trampoline > > address entries with correct original return address. This is done only > > if there are pending uretprobes for current task. > > > > This is a similar approach to what fprobe/kretprobe infrastructure is > > doing when capturing kernel stack traces in the presence of pending > > return probes. > > > > This looks good to me because this trampoline information is only > managed in uprobes. And it should be provided when unwinding user > stack. > > Reviewed-by: Masami Hiramatsu (Google) <[email protected]> > > Thank you!
Great, thanks for reviewing, Masami! Would you take this fix through your tree, or where should it be routed to? > > > Reported-by: Riham Selim <[email protected]> > > Signed-off-by: Andrii Nakryiko <[email protected]> > > --- > > kernel/events/callchain.c | 43 ++++++++++++++++++++++++++++++++++++++- > > kernel/events/uprobes.c | 9 ++++++++ > > 2 files changed, 51 insertions(+), 1 deletion(-) > > [...]
