All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	linux-perf-users@vger.kernel.org, netdev@vger.kernel.org,
	bpf@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Ian Rogers <irogers@google.com>
Subject: Re: [PATCHv5 bpf-next 1/1] perf tools: Rework prologue generation code
Date: Mon, 1 Aug 2022 14:44:47 -0300	[thread overview]
Message-ID: <YugRD0jmlT3p4GNK@kernel.org> (raw)
In-Reply-To: <72122b4e-1056-7392-f9eb-6ea4c0a79529@iogearbox.net>

Em Mon, Jun 20, 2022 at 02:43:22PM +0200, Daniel Borkmann escreveu:
> On 6/16/22 10:22 PM, Jiri Olsa wrote:
> > Some functions we use for bpf prologue generation are going to be
> > deprecated. This change reworks current code not to use them.
> > 
> > We need to replace following functions/struct:
> >     bpf_program__set_prep
> >     bpf_program__nth_fd
> >     struct bpf_prog_prep_result
> > 
> > Currently we use bpf_program__set_prep to hook perf callback before
> > program is loaded and provide new instructions with the prologue.
> > 
> > We replace this function/ality by taking instructions for specific
> > program, attaching prologue to them and load such new ebpf programs
> > with prologue using separate bpf_prog_load calls (outside libbpf
> > load machinery).
> > 
> > Before we can take and use program instructions, we need libbpf to
> > actually load it. This way we get the final shape of its instructions
> > with all relocations and verifier adjustments).
> > 
> > There's one glitch though.. perf kprobe program already assumes
> > generated prologue code with proper values in argument registers,
> > so loading such program directly will fail in the verifier.
> > 
> > That's where the fallback pre-load handler fits in and prepends
> > the initialization code to the program. Once such program is loaded
> > we take its instructions, cut off the initialization code and prepend
> > the prologue.
> > 
> > I know.. sorry ;-)
> > 
> > To have access to the program when loading this patch adds support to
> > register 'fallback' section handler to take care of perf kprobe programs.
> > The fallback means that it handles any section definition besides the
> > ones that libbpf handles.
> > 
> > The handler serves two purposes:
> >    - allows perf programs to have special arguments in section name
> >    - allows perf to use pre-load callback where we can attach init
> >      code (zeroing all argument registers) to each perf program
> > 
> > Suggested-by: Andrii Nakryiko <andrii@kernel.org>
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> 
> Hey Arnaldo, if you get a chance, please take a look.

Sry, applied.

- Arnaldo

  reply	other threads:[~2022-08-01 17:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16 20:22 [PATCHv5 bpf-next 0/1] perf tools: Fix prologue generation Jiri Olsa
2022-06-16 20:22 ` [PATCHv5 bpf-next 1/1] perf tools: Rework prologue generation code Jiri Olsa
2022-06-20 12:43   ` Daniel Borkmann
2022-08-01 17:44     ` Arnaldo Carvalho de Melo [this message]
2022-06-24 18:59   ` Arnaldo Carvalho de Melo
2022-06-24 20:40 ` [PATCHv5 bpf-next 0/1] perf tools: Fix prologue generation patchwork-bot+netdevbpf

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=YugRD0jmlT3p4GNK@kernel.org \
    --to=acme@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=irogers@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.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.