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

[Jiri Olsa <olsajiri@gmail.com>]

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