On Sun, Apr 3, 2022 at 9:46 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Sun, Apr 3, 2022 at 6:14 PM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Wed, Mar 30, 2022 at 8:27 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote:
> > >
> > > Now that u[ret]probes can use name-based specification, it makes
> > > sense to add support for auto-attach based on SEC() definition.
> > > The format proposed is
> > >
> > > SEC("u[ret]probe/binary:[raw_offset|[function_name[+offset]]")
> > >
> > > For example, to trace malloc() in libc:
> > >
> > > SEC("uprobe/libc.so.6:malloc")
> > >
> > > ...or to trace function foo2 in /usr/bin/foo:
> > >
> > > SEC("uprobe//usr/bin/foo:foo2")
> > >
> > > Auto-attach is done for all tasks (pid -1). prog can be an absolute
> > > path or simply a program/library name; in the latter case, we use
> > > PATH/LD_LIBRARY_PATH to resolve the full path, falling back to
> > > standard locations (/usr/bin:/usr/sbin or /usr/lib64:/usr/lib) if
> > > the file is not found via environment-variable specified locations.
> > >
> > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
> > > ---
> > > tools/lib/bpf/libbpf.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 72 insertions(+), 2 deletions(-)
> > >
> >
> > [...]
> >
> > > +static int attach_uprobe(const struct bpf_program *prog, long cookie, struct bpf_link **link)
> > > +{
> > > + DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, opts);
> > > + char *func, *probe_name, *func_end;
> > > + char *func_name, binary_path[512];
> > > + unsigned long long raw_offset;
> > > + size_t offset = 0;
> > > + int n;
> > > +
> > > + *link = NULL;
> > > +
> > > + opts.retprobe = str_has_pfx(prog->sec_name, "uretprobe/");
> > > + if (opts.retprobe)
> > > + probe_name = prog->sec_name + sizeof("uretprobe/") - 1;
> > > + else
> > > + probe_name = prog->sec_name + sizeof("uprobe/") - 1;
> >
> > I think this will mishandle SEC("uretprobe"), let's fix this in a
> > follow up (and see a note about uretprobe selftests)
>
> So I actually fixed it up a little bit to avoid test failure on s390x
> arch. But now it's a different problem, complaining about not being
> able to resolve libc.so.6. CC'ing Ilya, but I was wondering if it's
> better to use more generic "libc.so" instead of "libc.so.6"? Have you
> tried that?
See [0] for one such failure log.
[0] https://github.com/kernel-patches/bpf/runs/5810017263?check_suite_focus=true
>
> We should also probably refactor attach_probe.c selftest to be a
> collection of subtest, so that we can blacklist only some subtests.
> For now I have to blacklist it entirely on s390x.
>
> >
> > > +
> > > + /* handle SEC("u[ret]probe") - format is valid, but auto-attach is impossible. */
> > > + if (strlen(probe_name) == 0) {
> > > + pr_debug("section '%s' is old-style u[ret]probe/function, cannot auto-attach\n",
> > > + prog->sec_name);
> >
> > this seems excessive to log this, it's expected situation. The message
> > itself is also misleading, SEC("uretprobe") isn't old-style, it's
> > valid and supported case. SEC("uretprobe/something") is an error now,
> > so that's a different thing (let's improve handling in the follow up).
> >
> > > + return 0;
> > > + }
> > > + snprintf(binary_path, sizeof(binary_path), "%s", probe_name);
> > > + /* ':' should be prior to function+offset */
> > > + func_name = strrchr(binary_path, ':');
> > > + if (!func_name) {
> > > + pr_warn("section '%s' missing ':function[+offset]' specification\n",
> > > + prog->sec_name);
> > > + return -EINVAL;
> > > + }
> > > + func_name[0] = '\0';
> > > + func_name++;
> > > + n = sscanf(func_name, "%m[a-zA-Z0-9_.]+%li", &func, &offset);
> > > + if (n < 1) {
> > > + pr_warn("uprobe name '%s' is invalid\n", func_name);
> > > + return -EINVAL;
> > > + }
> >
> > I have this feeling that you could have simplified this a bunch with
> > just one sscanf. Something along the lines of
> > "%m[^/]/%m[^:]:%m[a-zA-Z0-9_.]+%li". If one argument matched (supposed
> > to be uprobe or uretprobe), then it is a no-auto-attach case, just
> > exit. If two matched -- invalid definition (old-style definition you
> > were reporting erroneously above in pr_debug). If 3 matched -- binary
> > + func (or abs offset), if 4 matched - binary + func + offset. That
> > should cover everything, right?
> >
> > Please try to do this in a follow up.
> >
> > > + if (opts.retprobe && offset != 0) {
> > > + free(func);
> > > + pr_warn("uretprobes do not support offset specification\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + /* Is func a raw address? */
> > > + errno = 0;
> > > + raw_offset = strtoull(func, &func_end, 0);
> > > + if (!errno && !*func_end) {
> > > + free(func);
> > > + func = NULL;
> > > + offset = (size_t)raw_offset;
> > > + }
> > > + opts.func_name = func;
> > > +
> > > + *link = bpf_program__attach_uprobe_opts(prog, -1, binary_path, offset, &opts);
> > > + free(func);
> > > + return 0;
> >
> > this should have been return libbpf_get_error(*link), fixed it
> >
> >
> > > +}
> > > +
> > > struct bpf_link *bpf_program__attach_uprobe(const struct bpf_program *prog,
> > > bool retprobe, pid_t pid,
> > > const char *binary_path,
> > > --
> > > 1.8.3.1
> > >
