All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	bpf@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>, Hao Luo <haoluo@google.com>,
	Christoph Hellwig <hch@lst.de>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Martynas Pumputis <m@lambda.lt>
Subject: Re: [PATCH bpf-next 7/8] selftests/bpf: Add kprobe_multi kmod link api tests
Date: Fri, 14 Oct 2022 12:25:52 +0200	[thread overview]
Message-ID: <Y0k5MM5cOjqYgXZR@krava> (raw)
In-Reply-To: <CAEf4BzbX5G3LXNJAdRA0kkO=7V1pheN6fUHAHUcPjdpbFQSEuA@mail.gmail.com>

On Thu, Oct 13, 2022 at 12:06:06PM -0700, Andrii Nakryiko wrote:

SNIP

> > +static void test_testmod_link_api(struct bpf_link_create_opts *opts)
> > +{
> > +       int prog_fd, link1_fd = -1, link2_fd = -1;
> > +       struct kprobe_multi *skel = NULL;
> > +
> > +       skel = kprobe_multi__open_and_load();
> > +       if (!ASSERT_OK_PTR(skel, "fentry_raw_skel_load"))
> > +               goto cleanup;
> > +
> > +       skel->bss->pid = getpid();
> > +       prog_fd = bpf_program__fd(skel->progs.test_kprobe_testmod);
> > +       link1_fd = bpf_link_create(prog_fd, 0, BPF_TRACE_KPROBE_MULTI, opts);
> > +       if (!ASSERT_GE(link1_fd, 0, "link_fd1"))
> > +               goto cleanup;
> > +
> > +       opts->kprobe_multi.flags = BPF_F_KPROBE_MULTI_RETURN;
> > +       prog_fd = bpf_program__fd(skel->progs.test_kretprobe_testmod);
> > +       link2_fd = bpf_link_create(prog_fd, 0, BPF_TRACE_KPROBE_MULTI, opts);
> > +       if (!ASSERT_GE(link2_fd, 0, "link_fd2"))
> > +               goto cleanup;
> > +
> 
> any reason to not use bpf_program__attach_kprobe_multi_ops() and
> instead use low-level bpf_link_create?
> 
> > +       ASSERT_OK(trigger_module_test_read(1), "trigger_read");
> > +       kprobe_multi_testmod_check(skel);
> > +
> > +cleanup:
> > +       if (link1_fd != -1)
> > +               close(link1_fd);
> > +       if (link2_fd != -1)
> > +               close(link2_fd);
> 
> you don't need to even do this if you stick to high-level attach APIs

ok, I guess we can use bpf_program__attach_kprobe_multi_opts here

> 
> > +       kprobe_multi__destroy(skel);
> > +}
> > +
> > +#define GET_ADDR(__sym, __addr) ({                                     \
> > +       __addr = ksym_get_addr(__sym);                                  \
> > +       if (!ASSERT_NEQ(__addr, 0, "kallsyms load failed for " #__sym)) \
> > +               return;                                                 \
> > +})
> 
> macro for this? why? just make understanding the code and debugging
> it, if necessary, harder. You don't even need that return, just lookup
> and ASSERT_NEQ(). Go to symbol #2 and do the same. If something goes
> wrong you'll have three failed ASSERT_NEQs, which is totally fine.

sure

SNIP

> > diff --git a/tools/testing/selftests/bpf/progs/kprobe_multi.c b/tools/testing/selftests/bpf/progs/kprobe_multi.c
> > index 98c3399e15c0..b3c54ec13a45 100644
> > --- a/tools/testing/selftests/bpf/progs/kprobe_multi.c
> > +++ b/tools/testing/selftests/bpf/progs/kprobe_multi.c
> > @@ -110,3 +110,54 @@ int test_kretprobe_manual(struct pt_regs *ctx)
> >         kprobe_multi_check(ctx, true);
> >         return 0;
> >  }
> > +
> > +extern const void bpf_testmod_fentry_test1 __ksym;
> > +extern const void bpf_testmod_fentry_test2 __ksym;
> > +extern const void bpf_testmod_fentry_test3 __ksym;
> > +
> > +__u64 kprobe_testmod_test1_result = 0;
> > +__u64 kprobe_testmod_test2_result = 0;
> > +__u64 kprobe_testmod_test3_result = 0;
> > +
> > +__u64 kretprobe_testmod_test1_result = 0;
> > +__u64 kretprobe_testmod_test2_result = 0;
> > +__u64 kretprobe_testmod_test3_result = 0;
> > +
> > +static void kprobe_multi_testmod_check(void *ctx, bool is_return)
> > +{
> > +       if (bpf_get_current_pid_tgid() >> 32 != pid)
> > +               return;
> > +
> > +       __u64 addr = bpf_get_func_ip(ctx);
> > +
> > +#define SET(__var, __addr) ({                          \
> > +       if ((const void *) addr == __addr)              \
> > +               __var = 1;                              \
> > +})
> > +
> 
> same feedback, why macro for this? There is nothing repetitive done in it at all

ok, will change

thanks,
jirka

  reply	other threads:[~2022-10-14 10:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-09 21:59 [PATCH bpf-next 0/8] bpf: Fixes for kprobe multi on kernel modules Jiri Olsa
2022-10-09 21:59 ` [PATCH bpf-next 1/8] kallsyms: Make module_kallsyms_on_each_symbol generally available Jiri Olsa
2022-10-11  6:56   ` Song Liu
2022-10-09 21:59 ` [PATCH bpf-next 2/8] ftrace: Add support to resolve module symbols in ftrace_lookup_symbols Jiri Olsa
2022-10-11  7:05   ` Song Liu
2022-10-11 10:07     ` Jiri Olsa
2022-10-09 21:59 ` [PATCH bpf-next 3/8] bpf: Rename __bpf_kprobe_multi_cookie_cmp to bpf_kprobe_multi_addrs_cmp Jiri Olsa
2022-10-11  7:06   ` Song Liu
2022-10-09 21:59 ` [PATCH bpf-next 4/8] bpf: Take module reference on kprobe_multi link Jiri Olsa
2022-10-11  7:16   ` Song Liu
2022-10-11 10:09     ` Jiri Olsa
2022-10-13 18:50   ` Andrii Nakryiko
2022-10-14 10:17     ` Jiri Olsa
2022-10-09 21:59 ` [PATCH bpf-next 5/8] selftests/bpf: Add load_kallsyms_refresh function Jiri Olsa
2022-10-11  7:17   ` Song Liu
2022-10-09 21:59 ` [PATCH bpf-next 6/8] selftests/bpf: Add bpf_testmod_fentry_* functions Jiri Olsa
2022-10-11  7:24   ` Song Liu
2022-10-09 21:59 ` [PATCH bpf-next 7/8] selftests/bpf: Add kprobe_multi kmod link api tests Jiri Olsa
2022-10-11  7:27   ` Song Liu
2022-10-11 10:09     ` Jiri Olsa
2022-10-13 19:06   ` Andrii Nakryiko
2022-10-14 10:25     ` Jiri Olsa [this message]
2022-10-09 21:59 ` [PATCH bpf-next 8/8] selftests/bpf: Add kprobe_multi check to module attach test Jiri Olsa
2022-10-11  7:27   ` Song Liu

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=Y0k5MM5cOjqYgXZR@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=hch@lst.de \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=m@lambda.lt \
    --cc=mhiramat@kernel.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.