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
Oleg.
