On Thu, Jan 20, 2022 at 5:44 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Jan 20, 2022 at 3:43 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > This patch series is a refinement of the RFC patchset [1], focusing > > on support for attach by name for uprobes and uretprobes. Still > > marked RFC as there are unresolved questions. > > > > Currently attach for such probes is done by determining the offset > > manually, so the aim is to try and mimic the simplicity of kprobe > > attach, making use of uprobe opts to specify a name string. > > > > uprobe attach is done by specifying a binary path, a pid (where > > 0 means "this process" and -1 means "all processes") and an > > offset. Here a 'func_name' option is added to 'struct uprobe_opts' > > and that name is searched for in symbol tables. If the binary > > is a program, relative offset calcuation must be done to the > > symbol address as described in [2]. > > I think the pid discussion here and in the patches only causes > confusion. I think it's best to remove pid from the api. It's already part of the uprobe API in libbpf (bpf_program__attach_uprobe), but nothing really changes there. API-wise Alan just added an optional func_name option. I think it makes sense overall. For auto-attach it has to be all PIDs, of course. > uprobes are attached to an inode. They're not attached to a pid > or a process. Any existing process or future process started > from that inode (executable file) will have that uprobe triggering. > The kernel can do pid filtering through predicate mechanism, > but bpf uprobe doesn't do any filtering. iirc. > Similarly "attach to all processes" doesn't sound right either. > It's attached to all current and future processes.
