linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, Hao Luo <haoluo@google.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Arnaldo Carvalho de Melo <acme@kernel.org>,
	bpf@vger.kernel.org, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	 linux-perf-users@vger.kernel.org,
	Martin KaFai Lau <kafai@fb.com>,
	 Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	 John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>,
	 Stanislav Fomichev <sdf@google.com>,
	Daniel Borkmann <daniel@iogearbox.net>
Subject: Re: [PATCH RFC 5/5] selftests/bpf: Add iter_task_vma_buildid test
Date: Wed, 8 Feb 2023 16:01:42 -0800	[thread overview]
Message-ID: <CAEf4BzYGQGdydeVbZf5YTnDTvGduA_wbeQ=t5nSc6Wi=S17+=A@mail.gmail.com> (raw)
In-Reply-To: <20230201135737.800527-6-jolsa@kernel.org>

On Wed, Feb 1, 2023 at 5:58 AM Jiri Olsa <jolsa@kernel.org> wrote:
>
> Testing iterator access to build id in vma->vm_file object
> by storing each binary with buildid into map and checking
> it against buildid retrieved in user space.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
>  .../selftests/bpf/prog_tests/bpf_iter.c       | 88 +++++++++++++++++++
>  .../bpf/progs/bpf_iter_task_vma_buildid.c     | 49 +++++++++++
>  2 files changed, 137 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
> index 3af6450763e9..fd3217b68c2e 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
> @@ -33,6 +33,7 @@
>  #include "bpf_iter_bpf_link.skel.h"
>  #include "bpf_iter_ksym.skel.h"
>  #include "bpf_iter_sockmap.skel.h"
> +#include "bpf_iter_task_vma_buildid.skel.h"
>
>  static int duration;
>
> @@ -1536,6 +1537,91 @@ static void test_task_vma_dead_task(void)
>         bpf_iter_task_vma__destroy(skel);
>  }
>
> +#define D_PATH_BUF_SIZE                1024
> +#define BUILD_ID_SIZE_MAX      20
> +
> +struct build_id {
> +       u32 sz;
> +       char data[BUILD_ID_SIZE_MAX];
> +};
> +
> +#define BUILDID_STR_SIZE (BPF_BUILD_ID_SIZE*2 + 1)
> +
> +static void test_task_vma_buildid(void)
> +{
> +       int err, iter_fd = -1, proc_maps_fd = -1;
> +       struct bpf_iter_task_vma_buildid *skel;
> +       char key[D_PATH_BUF_SIZE], *prev_key;
> +       char bpf_build_id[BUILDID_STR_SIZE];
> +       int len, files_fd, i, cnt = 0;
> +       struct build_id val;
> +       char *build_id;
> +       char c;
> +
> +       skel = bpf_iter_task_vma_buildid__open();
> +       if (!ASSERT_OK_PTR(skel, "bpf_iter_task_vma_buildid__open"))
> +               return;
> +
> +       err = bpf_iter_task_vma_buildid__load(skel);
> +       if (!ASSERT_OK(err, "bpf_iter_task_vma_buildid__load"))
> +               goto out;

minor: you can do __open_and_load() in one step

> +
> +       skel->links.proc_maps = bpf_program__attach_iter(
> +               skel->progs.proc_maps, NULL);
> +
> +       if (!ASSERT_OK_PTR(skel->links.proc_maps, "bpf_program__attach_iter")) {
> +               skel->links.proc_maps = NULL;
> +               goto out;
> +       }
> +
> +       iter_fd = bpf_iter_create(bpf_link__fd(skel->links.proc_maps));
> +       if (!ASSERT_GE(iter_fd, 0, "create_iter"))
> +               goto out;
> +
> +       /* trigger the iterator, there's no output, just map */
> +       len = read(iter_fd, &c, 1);
> +       ASSERT_EQ(len, 0, "len_check");
> +
> +       files_fd = bpf_map__fd(skel->maps.files);
> +
> +       prev_key = NULL;
> +
> +       while (true) {
> +               err = bpf_map_get_next_key(files_fd, prev_key, &key);
> +               if (err) {
> +                       if (errno == ENOENT)
> +                               err = 0;
> +                       break;
> +               }
> +               if (bpf_map_lookup_elem(files_fd, key, &val))
> +                       break;
> +               if (!ASSERT_LE(val.sz, BUILD_ID_SIZE_MAX, "buildid_size"))
> +                       break;
> +
> +               memset(bpf_build_id, 0x0, sizeof(bpf_build_id));
> +               for (i = 0; i < val.sz; i++) {
> +                       sprintf(bpf_build_id + i*2, "%02x",
> +                               (unsigned char) val.data[i]);
> +               }
> +
> +               if (!ASSERT_OK(read_buildid(key, &build_id), "read_buildid"))
> +                       break;
> +
> +               printf("BUILDID %s %s %s\n", bpf_build_id, build_id, key);

debugging leftover or intentional?

> +               ASSERT_OK(strncmp(bpf_build_id, build_id, strlen(bpf_build_id)), "buildid_cmp");
> +
> +               free(build_id);
> +               prev_key = key;
> +               cnt++;
> +       }
> +
> +       printf("checked %d files\n", cnt);

ditto

> +out:
> +       close(proc_maps_fd);
> +       close(iter_fd);
> +       bpf_iter_task_vma_buildid__destroy(skel);
> +}
> +
>  void test_bpf_sockmap_map_iter_fd(void)
>  {
>         struct bpf_iter_sockmap *skel;
> @@ -1659,6 +1745,8 @@ void test_bpf_iter(void)
>                 test_task_vma();
>         if (test__start_subtest("task_vma_dead_task"))
>                 test_task_vma_dead_task();
> +       if (test__start_subtest("task_vma_buildid"))
> +               test_task_vma_buildid();
>         if (test__start_subtest("task_btf"))
>                 test_task_btf();
>         if (test__start_subtest("tcp4"))
> diff --git a/tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c b/tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c
> new file mode 100644
> index 000000000000..25e2179ae5f4
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/bpf_iter_task_vma_buildid.c
> @@ -0,0 +1,49 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include "bpf_iter.h"
> +#include <bpf/bpf_helpers.h>
> +#include <string.h>
> +
> +char _license[] SEC("license") = "GPL";
> +
> +#define VM_EXEC                0x00000004
> +#define D_PATH_BUF_SIZE        1024
> +
> +struct {
> +       __uint(type, BPF_MAP_TYPE_HASH);
> +       __uint(max_entries, 10000);
> +       __type(key, char[D_PATH_BUF_SIZE]);
> +       __type(value, struct build_id);
> +} files SEC(".maps");
> +
> +static char tmp_key[D_PATH_BUF_SIZE];
> +static struct build_id tmp_data;
> +
> +SEC("iter/task_vma") int proc_maps(struct bpf_iter__task_vma *ctx)

nit: let's keep SEC() on separate line from function itself

> +{
> +       struct vm_area_struct *vma = ctx->vma;
> +       struct seq_file *seq = ctx->meta->seq;
> +       struct task_struct *task = ctx->task;
> +       unsigned long file_key;
> +       struct file *file;
> +
> +       if (task == (void *)0 || vma == (void *)0)
> +               return 0;
> +
> +       if (!(vma->vm_flags & VM_EXEC))
> +               return 0;
> +
> +       file = vma->vm_file;
> +       if (!file)
> +               return 0;
> +
> +       memset(tmp_key, 0x0, D_PATH_BUF_SIZE);

__builtin_memset() to not rely on compiler optimization?

> +       bpf_d_path(&file->f_path, (char *) &tmp_key, D_PATH_BUF_SIZE);
> +
> +       if (bpf_map_lookup_elem(&files, &tmp_key))
> +               return 0;
> +
> +       memcpy(&tmp_data, file->f_bid, sizeof(*file->f_bid));

same about __builtin_memcpy()

> +       bpf_map_update_elem(&files, &tmp_key, &tmp_data, 0);
> +       return 0;
> +}
> --
> 2.39.1
>


  reply	other threads:[~2023-02-09  0:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 13:57 [RFC 0/5] mm/bpf/perf: Store build id in file object Jiri Olsa
2023-02-01 13:57 ` [PATCH RFC 1/5] mm: " Jiri Olsa
2023-02-08 23:52   ` Andrii Nakryiko
2023-02-09 14:04     ` Jiri Olsa
2023-02-01 13:57 ` [PATCH RFC 2/5] bpf: Use file object build id in stackmap Jiri Olsa
2023-02-09  7:23   ` Hao Luo
2023-02-09 13:19     ` Jiri Olsa
2023-02-01 13:57 ` [PATCH RFC 3/5] perf: Use file object build id in perf_event_mmap_event Jiri Olsa
2023-02-01 13:57 ` [PATCH RFC 4/5] selftests/bpf: Add file_build_id test Jiri Olsa
2023-02-08 23:58   ` Andrii Nakryiko
2023-02-09 14:04     ` Jiri Olsa
2023-02-01 13:57 ` [PATCH RFC 5/5] selftests/bpf: Add iter_task_vma_buildid test Jiri Olsa
2023-02-09  0:01   ` Andrii Nakryiko [this message]
2023-02-09 14:04     ` Jiri Olsa
2023-02-09 17:16       ` Andrii Nakryiko
2023-02-02 11:15 ` [RFC 0/5] mm/bpf/perf: Store build id in file object Alexei Starovoitov
2023-02-02 14:47   ` Jiri Olsa
2023-02-03 10:03   ` Peter Zijlstra
2023-02-02 15:10 ` Matthew Wilcox
2023-02-02 15:33   ` Jiri Olsa
2023-02-09  7:12     ` Hao Luo
2023-02-09 14:18 ` Jiri Olsa
2023-02-09 19:38   ` 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='CAEf4BzYGQGdydeVbZf5YTnDTvGduA_wbeQ=t5nSc6Wi=S17+=A@mail.gmail.com' \
    --to=andrii.nakryiko@gmail.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.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@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox