On 09/02, Tianyi Liu wrote: > > On Fri, Aug 30, 2024 at 18:12:41PM +0800, Oleg Nesterov wrote: > > > > - So I still think that the "right" fix should change the > > bpf_prog_run_array_uprobe() paths somehow, but I know nothing > > about bpf. > > I agree that this patch does not address the issue correctly. > The PID filter should be implemented within bpf_prog_run_array_uprobe, OK, > or alternatively, bpf_prog_run_array_uprobe should be called after > perf_tp_event_match to reuse the filtering mechanism provided by perf. No, no, perf_tp_event_match() has nothing to do with pid/mm filtering in this case, afaics. See https://lore.kernel.org/all/20240829152032.GA23996@xxxxxxxxxx/ and perf_trace_add() which adds the event to this_cpu_ptr(call->perf_events), see also the hlist_empty(head) check in __uprobe_perf_func(). Again, again, I can be easily wrong, I forgot everything I knew (not too much) about perf, but at least in the case above perf_tp_event_match() is not even called. > Also, uretprobe may need UPROBE_HANDLER_REMOVE, similar to uprobe. May be... Not sure. But why do you think we want it? And... I think that BPF has even more problems with filtering. Not sure, I'll try to write another test-case tomorrow. Oleg.
