From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 4/4] selftests/bpf: Add tests for memory usage for arena
Date: Fri, 17 Jul 2026 21:18:47 +0800 [thread overview]
Message-ID: <d365c74d-a8a0-4331-921b-4cb3d546590f@linux.dev> (raw)
In-Reply-To: <20260717115336.A78DC1F000E9@smtp.kernel.org>
On 7/17/26 7:53 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Incorrect use of ASSERT_OK_PTR to check for a NULL pointer read from BPF userspace memory, breaking intended error handling.
> --
>
> --- Patch [4]: [PATCH bpf-next v2 4/4] selftests/bpf: Add tests for memory usage for arena ---
> commit b8bd79585d9f7cbf2a83d5381d0df2c316e65ed7
> Author: Jiayuan Chen <jiayuan.chen@linux.dev>
>
> selftests/bpf: Add tests for memory usage for arena
>
> This patch adds a selftest to verify memory usage tracking for BPF arenas.
> It allocates and frees arena pages both from BPF and user-space and checks
> the map's memlock value via fdinfo to ensure it tracks populated pages.
>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/arena_mem_usage.c b/tools/testing/selftests/bpf/prog_tests/arena_mem_usage.c
>> new file mode 100644
>> index 0000000000000..14c2d1a1d673c
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/prog_tests/arena_mem_usage.c
> [ ... ]
>
>> +void serial_test_arena_mem_usage(void)
>> +{
>> + struct arena_mem_usage *skel;
>> + const long ps = PAGE_SIZE;
>> + char *base;
>> + size_t sz;
>> + int fd, i;
>> +
>> + skel = arena_mem_usage__open_and_load();
>> + if (!ASSERT_OK_PTR(skel, "open_load"))
>> + return;
>> + fd = bpf_map__fd(skel->maps.arena);
>> +
>> + /* Fresh arena: no data pages, and the scratch page is not counted. */
>> + ASSERT_EQ(map_memlock(fd), 0, "initial");
>> +
>> + /* BPF-side allocation of 17 pages. */
>> + skel->bss->alloc_cnt = 17;
>> + if (run(skel->progs.alloc, "alloc"))
>> + goto out;
>> + /*
>> + * A NULL ptr means bpf_arena_alloc_pages() itself failed (e.g. the host
>> + * is under memory pressure), not a miscount -- flag it distinctly so a
>> + * red CI run is not mistaken for a counting bug.
>> + */
>> + if (!ASSERT_OK_PTR(skel->bss->ptr, "arena_alloc_pages"))
> [Severity: Medium]
> Will this check actually catch a NULL pointer when bpf_arena_alloc_pages()
> fails?
>
> When skel->bss->ptr is NULL, ASSERT_OK_PTR() evaluates libbpf_get_error(NULL),
> which returns -errno. Since the userspace errno is likely 0 following a
> successful bpf_prog_test_run_opts() ioctl call, ASSERT_OK_PTR silently
> evaluates to true (success).
>
> This would cause the goto out to be skipped, and the test to proceed to
> evaluate ASSERT_EQ(map_memlock(fd), 17 * ps). This subsequent check would
> then fail, emitting the exact counting bug error the comment mentions trying
> to avoid.
>
> Should this use a different macro, like ASSERT_NEQ(skel->bss->ptr, NULL), to
> correctly verify the userspace pointer?
On success ptr is a valid arena address and ASSERT_OK_PTR() passes
correctly.
On alloc failure ptr is NULL and ASSERT_OK_PTR() may treat it as OK
(libbpf_get_error(NULL)
returns -errno, which can be 0), but the next ASSERT_EQ(map_memlock(fd),
17 * ps) still fails.
I can switch it to ASSERT_NEQ(skel->bss->ptr, NULL, ...) in the next
revision.
prev parent reply other threads:[~2026-07-17 13:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 11:37 [PATCH bpf-next v2 0/4] bpf: Add memory usage for arena and selftest Jiayuan Chen
2026-07-17 11:37 ` [PATCH bpf-next v2 1/4] bpf: Pass arena instead of scratch_page to the pte callbacks Jiayuan Chen
2026-07-17 11:37 ` [PATCH bpf-next v2 2/4] bpf: Add memory usage for arena Jiayuan Chen
2026-07-17 11:37 ` [PATCH bpf-next v2 3/4] selftests/bpf: Run arena tests serially Jiayuan Chen
2026-07-17 11:37 ` [PATCH bpf-next v2 4/4] selftests/bpf: Add tests for memory usage for arena Jiayuan Chen
2026-07-17 11:53 ` sashiko-bot
2026-07-17 13:18 ` Jiayuan Chen [this message]
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=d365c74d-a8a0-4331-921b-4cb3d546590f@linux.dev \
--to=jiayuan.chen@linux.dev \
--cc=bpf@vger.kernel.org \
--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 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.