Re: [PATCH v2] tracing/uprobe: Add missing PID filter for uretprobe

Jiri Olsa
2024-09-09T10:41:49Z

On Fri, Sep 06, 2024 at 09:18:15PM +0200, Oleg Nesterov wrote:
> On 09/06, Jiri Olsa wrote:
> >
> > On Mon, Sep 02, 2024 at 03:22:25AM +0800, Tianyi Liu wrote:
> > >
> > > For now, please forget the original patch as we need a new solution ;)
> >
> > hi,
> > any chance we could go with your fix until we find better solution?
>
> Well, as I said from the very beginning I won't really argue even if
> I obviously don't like this change very much. As long as the changelog /
> comments clearly explain this change. I understand that sometimes an
> ugly/incomplete/whatever workaround is better than nothing.
>
> > it's simple and it fixes most of the cases for return uprobe pid filter
> > for events with bpf programs..
>
> But to remind it doesn't even fixes all the filtering problems with uprobes,
> not uretprobes,
>
> > I know during the discussion we found
> > that standard perf record path won't work if there's bpf program
> > attached on the same event,
>
> Ah. Yes, this is another problem I tried to point out. But if we discuss
> the filtering we can forget about /usr/bin/perf.
>
> Again, again, again, I know nothing about bpf. But it seems to me that
> perf_event_attach_bpf_prog() allows to attach up to BPF_TRACE_MAX_PROGS
> progs to event->tp_event->prog_array, and then bpf_prog_run_array_uprobe()
> should run them all. Right?
>
> So I think that if you run 2 instances of run_prog from my last test-case
> with $PID1 and $PID2, the filtering will be broken again. Both instances
> will share the same trace_event_call and the same trace_uprobe_filter.
>
> > and also it's not a common use case
>
> OK.
>
> And btw... Can bpftrace attach to the uprobe tp?
>
> # perf probe -x ./test -a func
> Added new event:
> probe_test:func (on func in /root/TTT/test)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_test:func -aR sleep 1
>
> # bpftrace -e 'tracepoint:probe_test:func { printf("%d\n", pid); }'
> Attaching 1 probe...
> ioctl(PERF_EVENT_IOC_SET_BPF): Invalid argument
> ERROR: Error attaching probe: tracepoint:probe_test:func

the problem here is that bpftrace assumes BPF_PROG_TYPE_TRACEPOINT type
for bpf program, but that will fail in perf_event_set_bpf_prog where
perf event will be identified as uprobe and demands bpf program type
to be BPF_PROG_TYPE_KPROBE

there's same issue with kprobe as well:

# perf probe -a ksys_read
Added new event:
probe:ksys_read (on ksys_read)

You can now use it in all perf tools, such as:

perf record -e probe:ksys_read -aR sleep 1

# bpftrace -e 'tracepoint:probe:ksys_read { printf("%d\n", pid); }'
Attaching 1 probe...
ioctl(PERF_EVENT_IOC_SET_BPF): Invalid argument
ERROR: Error attaching probe: tracepoint:probe:ksys_read

I'm not sure there's an easy way to filter these events from bpftrce -l
output (or change the program type accordingly), because I don't think
there's a way to find out the tracepoint subtype (kprobe/uprobe) from
the tracefs record

jirka