[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzZ5iLi=Xuw=+Ez30LWqPQuuVK8hGaVwfyHL5A+XDkFWgw@mail.gmail.com>
Date: Sun, 3 Apr 2022 21:46:57 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Alan Maguire <alan.maguire@...cle.com>,
Ilya Leoshkevich <iii@...ux.ibm.com>
Cc: Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>, Martin Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
john fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Yucong Sun <sunyucong@...il.com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH v5 bpf-next 3/5] libbpf: add auto-attach for uprobes based
on section name
On Sun, Apr 3, 2022 at 6:14 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
>
> On Wed, Mar 30, 2022 at 8:27 AM Alan Maguire <alan.maguire@...cle.com> 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@...cle.com>
> > ---
> > 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?
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
> >
Powered by blists - more mailing lists