All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Song Liu <songliubraving@fb.com>, Jiri Olsa <jolsa@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Cc: Martin KaFai Lau <kafai@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
	Stanislav Fomichev <sdf@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	bpf@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: [PATCH bpf-next 0/2] bpf: Allow access to perf sample data (v2)
Date: Tue, 20 Dec 2022 14:01:42 -0800	[thread overview]
Message-ID: <20221220220144.4016213-1-namhyung@kernel.org> (raw)

Hello,

I'm working on perf event sample filtering using BPF.  To do that BPF needs
to access perf sample data and return 0 or 1 to drop or keep the samples.

Changes in v2)
 - reuse perf_prepare_sample() instead of adding new bpf_prepare_sample()
 - drop bpf_perf_event_read_helper() and access ctx->data directly using
   bpf_cast_to_kern_ctx().

v1) https://lore.kernel.org/r/20221101052340.1210239-1-namhyung@kernel.org

Thanks to bpf_cast_to_kern_ctx() kfunc, it can easily access the sample data
now.  But the problem is that perf didn't populate the sample data at the time
it calls bpf_prog_run().  I changed the code to simply call perf_prepare_sample
function before calling the BPF program.

But it also checks if the BPF calls bpf_cast_to_kern_ctx() since calling
perf_prepare_sample() is unnecessary if the BPF doesn't access to the sample.
The perf_prepare_sample() was only called right before putting it to the perf
ring buffer.  I think I can add a little optimization not to fill already set
fields as it can be called twice now.  It can be a separate patch for perf.

Another issue is that perf sample data only has selected fields according to
the sample_type flags in the perf_event_attr.  Accessing other fields can
result in uninitialized read.  I'm not sure how much it's gonna be a problem
but it seems there's no way to prevent it completely.  So properly written
programs should check the sample_type flags first when reading the sample data.

The code is available at 'bpf/perf-sample-v2' branch in

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (2):
  bpf/perf: Call perf_prepare_sample() before bpf_prog_run()
  selftests/bpf: Add perf_event_read_sample test cases

 include/linux/bpf.h                           |   1 +
 kernel/bpf/verifier.c                         |   1 +
 kernel/events/core.c                          |   3 +
 .../selftests/bpf/prog_tests/perf_sample.c    | 167 ++++++++++++++++++
 .../selftests/bpf/progs/test_perf_sample.c    |  33 ++++
 5 files changed, 205 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_sample.c
 create mode 100644 tools/testing/selftests/bpf/progs/test_perf_sample.c

-- 
2.39.0.314.g84b9a713c41-goog


             reply	other threads:[~2022-12-20 22:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20 22:01 Namhyung Kim [this message]
2022-12-20 22:01 ` [PATCH bpf-next 1/2] bpf/perf: Call perf_prepare_sample() before bpf_prog_run() Namhyung Kim
2022-12-22 12:55   ` Peter Zijlstra
2022-12-22 13:17     ` Daniel Borkmann
2022-12-22 17:34       ` Namhyung Kim
2022-12-22 20:16         ` Peter Zijlstra
2022-12-22 22:25           ` Namhyung Kim
2022-12-23  7:53             ` Jiri Olsa
2022-12-27 23:19               ` Namhyung Kim
2022-12-20 22:01 ` [PATCH bpf-next 2/2] selftests/bpf: Add perf_event_read_sample test cases Namhyung Kim

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=20221220220144.4016213-1-namhyung@kernel.org \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sdf@google.com \
    --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.