All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii@kernel.org>
To: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>
Cc: <andrii@kernel.org>, <kernel-team@fb.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Kenta Tada <kenta.tada@sony.com>,
	Hengqi Chen <hengqi.chen@gmail.com>
Subject: [PATCH RFC bpf-next 0/3] libbpf: add better syscall kprobing support
Date: Wed, 6 Jul 2022 17:41:15 -0700	[thread overview]
Message-ID: <20220707004118.298323-1-andrii@kernel.org> (raw)

This RFC patch set is to gather feedback about new
SEC("ksyscall") and SEC("kretsyscall") section definitions meant to simplify
life of BPF users that want to trace Linux syscalls without having to know or
care about things like CONFIG_ARCH_HAS_SYSCALL_WRAPPER and related arch-specific
vs arch-agnostic __<arch>_sys_xxx vs __se_sys_xxx function names, calling
convention woes ("nested" pt_regs), etc. All this is quite annoying to
remember and care about as BPF user, especially if the goal is to write
achitecture- and kernel version-agnostic BPF code (e.g., things like
libbpf-tools, etc).

By using SEC("ksyscall/xxx")/SEC("kretsyscall/xxx") user clearly communicates
the desire to kprobe/kretprobe kernel function that corresponds to the
specified syscall. Libbpf will take care of all the details of determining
correct function name and calling conventions.

This patch set also improves BPF_KPROBE_SYSCALL (and renames it to
BPF_KSYSCALL to match SEC("ksyscall")) macro to take into account
CONFIG_ARCH_HAS_SYSCALL_WRAPPER instead of hard-coding whether host
architecture is expected to use syscall wrapper or not (which is less reliable
and can change over time).

It would be great to get feedback about the overall feature, but also I'd
appreciate help with testing this, especially for non-x86_64 architectures.

Cc: Ilya Leoshkevich <iii@linux.ibm.com>
Cc: Kenta Tada <kenta.tada@sony.com>
Cc: Hengqi Chen <hengqi.chen@gmail.com>

Andrii Nakryiko (3):
  libbpf: improve and rename BPF_KPROBE_SYSCALL
  libbpf: add ksyscall/kretsyscall sections support for syscall kprobes
  selftests/bpf: use BPF_KSYSCALL and SEC("ksyscall") in selftests

 tools/lib/bpf/bpf_tracing.h                   |  44 +++++--
 tools/lib/bpf/libbpf.c                        | 109 ++++++++++++++++++
 tools/lib/bpf/libbpf.h                        |  16 +++
 tools/lib/bpf/libbpf.map                      |   1 +
 tools/lib/bpf/libbpf_internal.h               |   2 +
 .../selftests/bpf/progs/bpf_syscall_macro.c   |   6 +-
 .../selftests/bpf/progs/test_attach_probe.c   |   6 +-
 .../selftests/bpf/progs/test_probe_user.c     |  27 +----
 8 files changed, 172 insertions(+), 39 deletions(-)

-- 
2.30.2


             reply	other threads:[~2022-07-07  0:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07  0:41 Andrii Nakryiko [this message]
2022-07-07  0:41 ` [PATCH RFC bpf-next 1/3] libbpf: improve and rename BPF_KPROBE_SYSCALL Andrii Nakryiko
2022-07-07  0:41 ` [PATCH RFC bpf-next 2/3] libbpf: add ksyscall/kretsyscall sections support for syscall kprobes Andrii Nakryiko
2022-07-07 17:23   ` Alexei Starovoitov
2022-07-07 19:10     ` Andrii Nakryiko
2022-07-07 19:36       ` Alexei Starovoitov
2022-07-07 20:50         ` Andrii Nakryiko
2022-07-08 11:28       ` Jiri Olsa
2022-07-08 22:05         ` Andrii Nakryiko
2022-07-10  0:38           ` Alexei Starovoitov
2022-07-11 16:28             ` Andrii Nakryiko
2022-07-12  4:20               ` Alexei Starovoitov
2022-07-12  5:00                 ` Andrii Nakryiko
2022-07-08  9:35   ` Jiri Olsa
2022-07-08 22:04     ` Andrii Nakryiko
2022-07-07  0:41 ` [PATCH RFC bpf-next 3/3] selftests/bpf: use BPF_KSYSCALL and SEC("ksyscall") in selftests Andrii Nakryiko
2022-07-07  8:28 ` [PATCH RFC bpf-next 0/3] libbpf: add better syscall kprobing support Yaniv Agman
2022-07-07 20:56   ` Andrii Nakryiko
2022-07-11 16:23     ` Andrii Nakryiko
2022-07-07 15:51 ` Ilya Leoshkevich
2022-07-07 20:59   ` Andrii Nakryiko
2022-07-11 18:25     ` Ilya Leoshkevich
2022-07-12  4:24       ` Andrii Nakryiko
2022-07-13  7:12         ` Alan Maguire
2022-07-13 17:52           ` Andrii Nakryiko

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=20220707004118.298323-1-andrii@kernel.org \
    --to=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=hengqi.chen@gmail.com \
    --cc=iii@linux.ibm.com \
    --cc=kenta.tada@sony.com \
    --cc=kernel-team@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.