On 08/26, Jiri Olsa wrote:
>
> On Mon, Aug 26, 2024 at 01:57:52PM +0200, Oleg Nesterov wrote:
> > On 08/26, Jiri Olsa wrote:
> > >
> > > > 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
> >
> > Not sure I understand... The task which hits the breakpoint is always
> > current, it is always scheduled in.
>
> hum, I might be missing something, but ;-)
No it is me ;) at least I certainly misunderstood your "scheduled in".
> assuming we have 2 tasks, each with perf uprobe event assigned
>
> in perf path there's uprobe_perf_func which calls the uprobe_perf_filter
> and if it returns true it then goes:
>
> uprobe_perf_func
> __uprobe_perf_func
> perf_trace_buf_submit
> perf_tp_event
> {
>
> hlist_for_each_entry_rcu(event, head, hlist_entry) {
> if (perf_tp_event_match(event, &data, regs)) {
> perf_swevent_event(event, count, &data, regs);
Aha. So, in this particular case, when the CLONE_VM child hits the bp
and calls uprobe_perf_func(), even perf_tp_event_match() won't be called,
head is hlist_empty(), right?
Thanks!
> in comparison with uprobe_multi path, where uprobe_multi_link_filter
Yeah, this is clear.
> > IIUC (but I am not sure), perf-record -p will work "correctly" even if we
> > remove uprobe_perf_filter() altogether. IIRC the perf layer does its own
> > filtering but I forgot everything.
>
> I think that's what I tried to describe above
Yes, thanks.
Oleg.
