On Tue, Jun 4, 2024 at 10:16 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Tue, Jun 4, 2024 at 7:13 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > On Tue, 21 May 2024 18:38:43 -0700 > > Andrii Nakryiko <andrii@xxxxxxxxxx> 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) <mhiramat@xxxxxxxxxx> > > > > Thank you! > > Great, thanks for reviewing, Masami! > > Would you take this fix through your tree, or where should it be routed to? > Ping! What would you like me to do with this patch set? Should I resend it without patch 3 (the one that tries to guess whether we are at the entry to the function?), or did I manage to convince you that this heuristic is OK, given perf's stack trace capturing logic already makes heavy assumption of rbp register being used for frame pointer? Please let me know your preference, I could drop patch 3 and send it separately, if that helps move the main fix forward. Thanks! > > > > > Reported-by: Riham Selim <rihams@xxxxxxxx> > > > Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx> > > > --- > > > kernel/events/callchain.c | 43 ++++++++++++++++++++++++++++++++++++++- > > > kernel/events/uprobes.c | 9 ++++++++ > > > 2 files changed, 51 insertions(+), 1 deletion(-) > > > > > [...]
