All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Dmitrii Dolgov <9erthalion6@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
	yonghong.song@linux.dev, dan.carpenter@linaro.org,
	olsajiri@gmail.com, asavkov@redhat.com
Subject: Re: [PATCH bpf-next v7 2/4] selftests/bpf: Add test for recursive attachment of tracing progs
Date: Mon, 11 Dec 2023 13:30:33 +0100	[thread overview]
Message-ID: <ZXcA6Z3IWVH1xPk_@krava> (raw)
In-Reply-To: <20231208185557.8477-3-9erthalion6@gmail.com>

On Fri, Dec 08, 2023 at 07:55:54PM +0100, Dmitrii Dolgov wrote:
> Verify the fact that only one fentry prog could be attached to another
> fentry, building up an attachment chain of limited size. Use existing
> bpf_testmod as a start of the chain.
> 
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
> Changes in v5:
>     - Test only one level of attachment
> 
>  .../bpf/prog_tests/recursive_attach.c         | 69 +++++++++++++++++++
>  .../selftests/bpf/progs/fentry_recursive.c    | 19 +++++
>  .../bpf/progs/fentry_recursive_target.c       | 20 ++++++
>  3 files changed, 108 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/recursive_attach.c
>  create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive.c
>  create mode 100644 tools/testing/selftests/bpf/progs/fentry_recursive_target.c
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/recursive_attach.c b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c
> new file mode 100644
> index 000000000000..7248d0661ee9
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/recursive_attach.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2023 Red Hat, Inc. */
> +#include <test_progs.h>
> +#include "fentry_recursive.skel.h"
> +#include "fentry_recursive_target.skel.h"
> +#include <bpf/btf.h>
> +#include "bpf/libbpf_internal.h"
> +
> +/*
> + * Test following scenarios:
> + * - attach one fentry progs to another one
> + * - more than one nesting levels are not allowed
> + */
> +void test_recursive_fentry_attach(void)
> +{
> +	struct fentry_recursive_target *target_skel = NULL;
> +	struct fentry_recursive *tracing_chain[2] = {};
> +	struct bpf_program *prog;
> +	int prev_fd, err;
> +
> +	target_skel = fentry_recursive_target__open_and_load();
> +	if (!ASSERT_OK_PTR(target_skel, "fentry_recursive_target__open_and_load"))
> +		goto close_prog;
> +
> +	/* Create an attachment chain with two fentry progs */
> +	for (int i = 0; i < 2; i++) {
> +		tracing_chain[i] = fentry_recursive__open();
> +		if (!ASSERT_OK_PTR(tracing_chain[i], "fentry_recursive__open"))
> +			goto close_prog;
> +
> +		/*
> +		 * The first prog in the chain is going to be attached to the target
> +		 * fentry program, the second one to the previous in the chain.
> +		 */
> +		if (i == 0) {
> +			prog = tracing_chain[0]->progs.recursive_attach;
> +			prev_fd = bpf_program__fd(target_skel->progs.test1);
> +			err = bpf_program__set_attach_target(prog, prev_fd, "test1");
> +		} else {
> +			prog = tracing_chain[i]->progs.recursive_attach;

nit, common line, could be placed before the loop

perhaps also the bpf_program__set_attach_target call does not need to be
in the if path, I think it should work with NULL for attach_func_name as
long as we provide attach_prog_fd

I wonder now with just 2 skels the test might be easier to read
without the loop, but I dont have strong opinion about that

> +			prev_fd = bpf_program__fd(tracing_chain[i-1]->progs.recursive_attach);
> +			err = bpf_program__set_attach_target(prog, prev_fd, "recursive_attach");
> +		}
> +
> +		if (!ASSERT_OK(err, "bpf_program__set_attach_target"))
> +			goto close_prog;
> +
> +		err = fentry_recursive__load(tracing_chain[i]);
> +		/* The first attach should succeed, the second fail */
> +		if (i == 0) {
> +			if (!ASSERT_OK(err, "fentry_recursive__load"))
> +				goto close_prog;
> +
> +			err = fentry_recursive__attach(tracing_chain[i]);
> +			if (!ASSERT_OK(err, "fentry_recursive__attach"))
> +				goto close_prog;
> +		} else {
> +			if (!ASSERT_ERR(err, "fentry_recursive__load"))
> +				goto close_prog;
> +		}
> +	}
> +
> +close_prog:
> +	fentry_recursive_target__destroy(target_skel);
> +	for (int i = 0; i < 2; i++) {
> +		if (tracing_chain[i])
> +			fentry_recursive__destroy(tracing_chain[i]);
> +	}
> +}
> diff --git a/tools/testing/selftests/bpf/progs/fentry_recursive.c b/tools/testing/selftests/bpf/progs/fentry_recursive.c
> new file mode 100644
> index 000000000000..1df490230344
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/fentry_recursive.c
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2023 Red Hat, Inc. */
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +
> +char _license[] SEC("license") = "GPL";
> +
> +__u64 test1_result = 0;

there's no reason to keep test1_result in here, please remove

> +
> +/*
> + * Dummy fentry bpf prog for testing fentry attachment chains
> + */
> +SEC("fentry/XXX")
> +int BPF_PROG(recursive_attach, int a)
> +{
> +	test1_result = a == 1;
> +	return 0;
> +}
> diff --git a/tools/testing/selftests/bpf/progs/fentry_recursive_target.c b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c
> new file mode 100644
> index 000000000000..b6fb8ebd598d
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/fentry_recursive_target.c
> @@ -0,0 +1,20 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2023 Red Hat, Inc. */
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +
> +char _license[] SEC("license") = "GPL";
> +
> +__u64 test1_result = 0;

ditto

thanks,
jirka

> +
> +/*
> + * Dummy fentry bpf prog for testing fentry attachment chains. It's going to be
> + * a start of the chain.
> + */
> +SEC("fentry/bpf_testmod_fentry_test1")
> +int BPF_PROG(test1, int a)
> +{
> +	test1_result = a == 1;
> +	return 0;
> +}
> -- 
> 2.41.0
> 

  reply	other threads:[~2023-12-11 12:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08 18:55 [PATCH bpf-next v7 0/4] Relax tracing prog recursive attach rules Dmitrii Dolgov
2023-12-08 18:55 ` [PATCH bpf-next v7 1/4] bpf: " Dmitrii Dolgov
2023-12-11 12:30   ` Jiri Olsa
2023-12-11 18:49     ` Dmitry Dolgov
2023-12-12  9:56       ` Jiri Olsa
2023-12-08 18:55 ` [PATCH bpf-next v7 2/4] selftests/bpf: Add test for recursive attachment of tracing progs Dmitrii Dolgov
2023-12-11 12:30   ` Jiri Olsa [this message]
2023-12-11 19:09     ` Dmitry Dolgov
2023-12-08 18:55 ` [PATCH bpf-next v7 3/4] bpf: Fix re-attachment branch in bpf_tracing_prog_attach Dmitrii Dolgov
2023-12-08 18:55 ` [PATCH bpf-next v7 4/4] selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach Dmitrii Dolgov
2023-12-11 12:30   ` Jiri Olsa

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=ZXcA6Z3IWVH1xPk_@krava \
    --to=olsajiri@gmail.com \
    --cc=9erthalion6@gmail.com \
    --cc=andrii@kernel.org \
    --cc=asavkov@redhat.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dan.carpenter@linaro.org \
    --cc=daniel@iogearbox.net \
    --cc=martin.lau@linux.dev \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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.