On Mon, Aug 26, 2024 at 12:40:18AM +0200, Oleg Nesterov wrote:
> On 08/25, Oleg Nesterov wrote:
> >
> > At least I certainly disagree with "Fixes: c1ae5c75e103" ;)
> >
> > uretprobe_perf_func/etc was designed for perf, and afaics this code still
> > works fine even if you run 2 perf-record's with -p PID1/PID2 at the same
> > time.
> >
> > BPF hacks/hooks were added later, so perhaps this should be fixed in the
> > bpf code, but I have no idea what bpftrace does...
>
> And I can't install bpftrace on my old Fedora 23 working laptop ;) Yes, yes,
> I know, I should upgrade it.
>
> For the moment, please forget about ret-probes. Could you compile this program
>
> #define _GNU_SOURCE
> #include <unistd.h>
> #include <sched.h>
> #include <signal.h>
>
> int func(int i)
> {
> return i;
> }
>
> int test(void *arg)
> {
> int i;
> for (i = 0;; ++i) {
> sleep(1);
> func(i);
> }
> return 0;
> }
>
> int main(void)
> {
> static char stack[65536];
>
> clone(test, stack + sizeof(stack)/2, CLONE_VM|SIGCHLD, NULL);
> test(NULL);
>
> return 0;
> }
>
> and then do something like
>
> $ ./test &
> $ bpftrace -p $! -e 'uprobe:./test:func { printf("%d\n", pid); }'
>
> I hope that the syntax of the 2nd command is correct...
>
> I _think_ that it will print 2 pids too.
yes.. but with CLONE_VM both processes share 'mm' so they are threads,
and at least uprobe_multi filters by process [1] now.. ;-)
>
> But "perf-record -p" works as expected.
I wonder it's because there's the perf layer that schedules each
uprobe event only when its process (PID1/2) is scheduled in and will
receive events only from that cpu while the process is running on it
jirka
[1] 46ba0e49b642 bpf: fix multi-uprobe PID filtering logic
>
> Oleg.
>
