On Tue, Aug 27, 2024 at 06:45:45PM +0200, Oleg Nesterov wrote:
> On 08/27, Jiri Olsa wrote:
> >
> > On Tue, Aug 27, 2024 at 12:29:38AM +0200, Oleg Nesterov wrote:
> > >
> > > So, can you reproduce the problem reported by Tianyi on your setup?
> >
> > yes, I can repduce the issue with uretprobe on top of perf event uprobe
>
> ...
>
> > -> 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
>
> Confused...
>
> I naively thought that if bpftrace uses bpf_uprobe_multi_link_attach() then
> it won't use perf/trace_uprobe, and uretprobe-hit will result in
right, this path is for the case when bpftrace attach to single uprobe,
but there are 2 instances of bpftrace
jirka
>
> // current->pid == 1018
>
> for_each_uprobe_consumer {
> // consumer for task 1019
> uprobe_multi_link_ret_handler
> uprobe_prog_run
> -> current->mm != link->task->mm, return
>
> // consumer for task 1018
> uprobe_multi_link_ret_handler
> uprobe_prog_run
> -> current->mm == link->task->mm, run bpf
> }
>
> > I think the uretprobe_dispatcher could call filter as suggested in the
> > original
> > patch..
>
> OK, agreed.
>
> > but I'm not sure we need to remove the uprobe from handle_uretprobe_chain
> > like we do in handler_chain..
>
> Me too. In any case this is another issue.
>
> Oleg.
>
