On Tue, Aug 27, 2024 at 10:19:26PM +0200, Oleg Nesterov wrote:
> Sorry for another reply, I just noticed I missed one part of your email...
>
> On 08/27, Jiri Olsa wrote:
> >
> > -> uretprobe-hit
> > handle_swbp
> > uprobe_handle_trampoline
> > handle_uretprobe_chain
> > {
> >
> > for_each_uprobe_consumer {
> >
> > // consumer for task 1019
> > uretprobe_dispatcher
> > uretprobe_perf_func
> > -> runs bpf program
> >
> > // consumer for task 1018
> > uretprobe_dispatcher
> > uretprobe_perf_func
> > -> runs bpf program
> >
> > }
> > }
> >
> > and I think the same will happen for perf record in this case where instead
> > of
> > running the program we will execute perf_tp_event
>
> Hmm. Really? In this case these 2 different consumers will have the different
> trace_event_call's, so
>
> // consumer for task 1019
> uretprobe_dispatcher
> uretprobe_perf_func
> __uprobe_perf_func
> perf_tp_event
>
> won't store the event because this_cpu_ptr(call->perf_events) should be
> hlist_empty() on this CPU, the perf_event for task 1019 wasn't scheduled in
> on this CPU...
I'll double check on that, but because there's no filter for uretprobe
I think it will be stored under 1018 event
>
> No?
>
> Ok, looks like I'm totally confused ;)
I'm working on bpf selftests for above (uprobe and uprobe_multi paths)
I plan to send them together with fixes we discussed earlier
I'm hoping this will make it more clear
jirka
