All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Alan Maguire <alan.maguire@oracle.com>,
	andrii@kernel.org, ast@kernel.org
Cc: kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, jolsa@kernel.org,
	sunyucong@gmail.com, netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH v3 bpf-next 0/4] libbpf: name-based u[ret]probe attach
Date: Tue, 1 Feb 2022 09:52:17 +0100	[thread overview]
Message-ID: <a74d3ab8-152a-b81b-54f3-9a46d6ba682d@iogearbox.net> (raw)
In-Reply-To: <1643645554-28723-1-git-send-email-alan.maguire@oracle.com>

Hi Alan,

On 1/31/22 5:12 PM, Alan Maguire wrote:
> This patch series is a refinement of the RFC patchset [1], focusing
> on support for attach by name for uprobes and uretprobes. v3
> because there was an earlier RFC [2].
> 
> 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.
> Patch 1 adds the "func_name" option to allow uprobe attach by
> name; the mechanics are described there.
> 
> Having name-based support allows us to support auto-attach for
> uprobes; patch 2 adds auto-attach support while attempting
> to handle backwards-compatibility issues that arise.  The format
> supported is
> 
> u[ret]probe//path/2/binary:[raw_offset|function[+offset]]
> 
> For example, to attach to libc malloc:
> 
> SEC("uprobe//usr/lib64/libc.so.6:malloc")
> 
> Patch 3 introduces a helper function to trace_helpers, allowing
> us to retrieve the path to a library by reading /proc/self/maps.
> 
> Finally patch 4 add tests to the attach_probe selftests covering
> attach by name, auto-attach and auto-attach failure.

Looks like the selftest in the series fails the BPF CI (test_progs & test_progs-no_alu32):

https://github.com/kernel-patches/bpf/runs/5012260907?check_suite_focus=true

   [...]
   test_attach_probe:PASS:uprobe_offset 0 nsec
   test_attach_probe:PASS:ref_ctr_offset 0 nsec
   test_attach_probe:PASS:skel_open 0 nsec
   test_attach_probe:PASS:check_bss 0 nsec
   test_attach_probe:PASS:attach_kprobe 0 nsec
   test_attach_probe:PASS:attach_kretprobe 0 nsec
   test_attach_probe:PASS:uprobe_ref_ctr_before 0 nsec
   test_attach_probe:PASS:attach_uprobe 0 nsec
   test_attach_probe:PASS:uprobe_ref_ctr_after 0 nsec
   test_attach_probe:PASS:attach_uretprobe 0 nsec
   test_attach_probe:PASS:auto-attach should fail for old-style name 0 nsec
   test_attach_probe:PASS:attach_uprobe_byname 0 nsec
   test_attach_probe:PASS:attach_uretprobe_byname 0 nsec
   test_attach_probe:PASS:get path to libc 0 nsec
   test_attach_probe:PASS:find libc path in /proc/self/maps 0 nsec
   libbpf: failed to open 7f55b225c000-7f55b2282000 r--p 00000000 fe:00 3381                       /usr/lib/libc-2.32.so: No such file or directory
   test_attach_probe:FAIL:attach_uprobe_byname2 unexpected error: -2
   test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec
   #4 attach_probe:FAIL
   [...]

Thanks,
Daniel

      parent reply	other threads:[~2022-02-01  8:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 16:12 [PATCH v3 bpf-next 0/4] libbpf: name-based u[ret]probe attach Alan Maguire
2022-01-31 16:12 ` [PATCH v3 bpf-next 1/4] libbpf: support function name-based attach uprobes Alan Maguire
2022-02-04 19:17   ` Andrii Nakryiko
2022-02-25 16:12     ` Alan Maguire
2022-01-31 16:12 ` [PATCH v3 bpf-next 2/4] libbpf: add auto-attach for uprobes based on section name Alan Maguire
2022-02-04 19:22   ` Andrii Nakryiko
2022-02-23  9:32     ` Alan Maguire
2022-02-24  1:49       ` Andrii Nakryiko
2022-02-24 15:39         ` Alan Maguire
2022-03-01  1:45           ` Andrii Nakryiko
2022-01-31 16:12 ` [PATCH v3 bpf-next 3/4] selftests/bpf: add get_lib_path() helper Alan Maguire
2022-02-04 19:24   ` Andrii Nakryiko
2022-01-31 16:12 ` [PATCH v3 bpf-next 4/4] selftests/bpf: add tests for u[ret]probe attach by name Alan Maguire
2022-02-04 19:30   ` Andrii Nakryiko
2022-02-26 16:00   ` Jiri Olsa
2022-02-01  8:52 ` Daniel Borkmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a74d3ab8-152a-b81b-54f3-9a46d6ba682d@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=sunyucong@gmail.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.