BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v3 02/15] selftests/bpf: Bind an exclusive map through a continuous fd_array
Date: Thu, 15 Oct 2026 23:53:39 +0000	[thread overview]
Message-ID: <sashiko-outbox-173493@kernel.org> (raw)
In-Reply-To: <20261015234125.3152346-3-memxor@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] selftests/bpf: missing NULL check for skeleton pointer in test_map_excl_fd_array()
--

commit 1bd492fc1fe89d69931d1485e93eef135d1cd6e5
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

selftests/bpf: Bind an exclusive map through a continuous fd_array

Load the exclusive program of map_excl with the map in a continuous
fd_array rather than through its insns alone, which has to work, and
the other program the same way, which has to be refused. The two
programs used to be identical and so shared a digest; give the second
one a value of its own so that the kernel can tell them apart.

> diff --git a/tools/testing/selftests/bpf/prog_tests/map_excl.c b/tools/testing/selftests/bpf/prog_tests/map_excl.c
> index 3f4422b9ffa69..3592f3ec49490 100644
> --- a/tools/testing/selftests/bpf/prog_tests/map_excl.c
> +++ b/tools/testing/selftests/bpf/prog_tests/map_excl.c
> @@ -161,12 +161,47 @@ static void test_map_excl_create_validation(void)
>  	ASSERT_EQ(fd, -EINVAL, "reject size with NULL hash pointer");
>  }
>  
> +/*
> + * The exclusive map bound through a continuous fd_array rather than by an
> + * insn. The kernel resolves the array before it verifies the program, so it
> + * has to have the digest of the program at hand by then.
> + */
> +static void test_map_excl_fd_array(void)
> +{
> +	struct map_excl *skel = map_excl__open();
> +	LIBBPF_OPTS(bpf_prog_load_opts, opts);
> +	int err, fd, map_fd;
> +
> +	err = bpf_map__set_exclusive_program(skel->maps.excl_map, skel->progs.should_have_access);

[Severity: Medium]
Does this code need to check if skel is NULL before dereferencing it?

If map_excl__open() fails to open the BPF object (for instance, due to
ENOMEM or a missing object file), it returns a NULL pointer. By passing
skel->maps.excl_map and skel->progs.should_have_access directly to
bpf_map__set_exclusive_program(), this will cause a segmentation fault in
the test runner instead of gracefully reporting a test failure.

Should there be an ASSERT_OK_PTR(skel, "open") check here before proceeding?

> +	if (!ASSERT_OK(err, "bpf_map__set_exclusive_program"))
> +		goto out;
> +
> +	bpf_program__set_autoload(skel->progs.should_have_access, true);
> +	bpf_program__set_autoload(skel->progs.should_not_have_access, true);
> +	err = bpf_object__prepare(skel->obj);
> +	if (!ASSERT_OK(err, "map_excl prepare"))
> +		goto out;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015234125.3152346-1-memxor@gmail.com?part=2

  reply	other threads:[~2026-10-15 23:53 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 23:41 [PATCH bpf-next v3 00/15] Fix some arena paper cuts Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 01/15] bpf: Compute the program digest before resolving the fd_array Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 02/15] selftests/bpf: Bind an exclusive map through a continuous fd_array Kumar Kartikeya Dwivedi
2026-10-15 23:53   ` sashiko-bot [this message]
2026-10-16  0:00     ` Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 03/15] libbpf: Keep the fd_array fill index out of bpf_program__clone() Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 04/15] selftests/bpf: Clone a program that calls a module kfunc Kumar Kartikeya Dwivedi
2026-10-16  0:12   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 05/15] compiler_types: Add __arena and __nullable BTF type tag qualifiers Kumar Kartikeya Dwivedi
2026-10-16  1:08   ` Alexei Starovoitov
2026-10-16  1:15     ` Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 06/15] bpf: Recognize __nullable on pointer members of kernel structs Kumar Kartikeya Dwivedi
2026-10-15 23:54   ` sashiko-bot
2026-10-16  0:00     ` Kumar Kartikeya Dwivedi
2026-10-16  1:09   ` Alexei Starovoitov
2026-10-16  1:24     ` Kumar Kartikeya Dwivedi
2026-10-16  1:31       ` Alexei Starovoitov
2026-10-16  1:39         ` Kumar Kartikeya Dwivedi
2026-10-16  1:53           ` Alexei Starovoitov
2026-10-16  2:04             ` Kumar Kartikeya Dwivedi
2026-10-16  2:20               ` Alexei Starovoitov
2026-10-15 23:41 ` [PATCH bpf-next v3 07/15] bpf: Turn loads of __arena pointer members into arena pointers Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 08/15] selftests/bpf: Test __nullable pointer members Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 09/15] selftests/bpf: Test __arena " Kumar Kartikeya Dwivedi
2026-10-16  1:11   ` Alexei Starovoitov
2026-10-16  1:39     ` Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 10/15] libbpf: Bind the arena of an object to every program in it Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 11/15] selftests/bpf: Test arena binding by libbpf Kumar Kartikeya Dwivedi
2026-10-16  0:28   ` bot+bpf-ci
2026-10-15 23:41 ` [PATCH bpf-next v3 12/15] bpf: Set up the arena base only in functions that use it Kumar Kartikeya Dwivedi
2026-10-16  1:13   ` Alexei Starovoitov
2026-10-15 23:41 ` [PATCH bpf-next v3 13/15] libbpf: Render the arena type tag with its address space Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 14/15] selftests/bpf: Test the address space rendering of the arena type tag Kumar Kartikeya Dwivedi
2026-10-15 23:41 ` [PATCH bpf-next v3 15/15] selftests/bpf: Test an arena kfunc argument passed from a subprogram Kumar Kartikeya Dwivedi

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=sashiko-outbox-173493@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=memxor@gmail.com \
    --cc=sashiko-reviews@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox