From: sashiko-bot@kernel.org
To: "Kumar Kartikeya Dwivedi" <memxor@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v1 2/8] selftests/bpf: Test timer field on recycled rhtab element
Date: Fri, 04 Sep 2026 11:12:51 +0000 [thread overview]
Message-ID: <20260904111251.CC4B81F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904104203.345917-3-memxor@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Redundant file descriptor validation after successful BPF skeleton open_and_load
--
commit 3c5ef82656b9b8e3dd5798348adbe7dae8162f8d
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
selftests/bpf: Test timer field on recycled rhtab element
This commit adds a selftest to exercise the rhtab special-field lifecycle
using a one-element map. It verifies that deleting a map element and then
replacing it preserves the timer field and successfully recycles the element.
> diff --git a/tools/testing/selftests/bpf/prog_tests/rhash_timer.c b/tools/testing/selftests/bpf/prog_tests/rhash_timer.c
> new file mode 100644
> index 0000000000000..3aad9fc02e063
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/rhash_timer.c
[ ... ]
> +void test_rhash_timer(void)
> +{
> + LIBBPF_OPTS(bpf_test_run_opts, opts);
> + struct rhash_timer *skel = NULL;
[ ... ]
> + skel = rhash_timer__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "open_and_load"))
> + goto out;
> +
> + map_fd = bpf_map__fd(skel->maps.timer_map);
> + if (!ASSERT_GE(map_fd, 0, "timer_map fd"))
> + goto out;
[Severity: Low]
According to the BPF subsystem guidelines for the skeleton API, after a
successful rhash_timer__open_and_load() call, the skeleton pointer is valid
and all maps are guaranteed to be created with valid FDs. Is it necessary
to manually extract and validate map_fd using ASSERT_GE() here?
> + arm_fd = bpf_program__fd(skel->progs.arm_deleted_timer);
> + if (!ASSERT_GE(arm_fd, 0, "arm_deleted_timer fd"))
> + goto out;
> + cancel_fd = bpf_program__fd(skel->progs.cancel_recycled_timer);
> + if (!ASSERT_GE(cancel_fd, 0, "cancel_recycled_timer fd"))
> + goto out;
[Severity: Low]
Similarly, is this program FD validation needed? The skeleton guarantees
that all programs are loaded with valid FDs after open_and_load succeeds,
so bpf_program__fd() cannot return a negative value here.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904104203.345917-1-memxor@gmail.com?part=2
next prev parent reply other threads:[~2026-09-04 11:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 10:41 [PATCH bpf v1 0/8] Misc bug fixes - part 4 Kumar Kartikeya Dwivedi
2026-09-04 10:41 ` [PATCH bpf v1 1/8] bpf: Preserve special fields in recycled rhtab elements Kumar Kartikeya Dwivedi
2026-09-04 10:41 ` [PATCH bpf v1 2/8] selftests/bpf: Test timer field on recycled rhtab element Kumar Kartikeya Dwivedi
2026-09-04 11:12 ` sashiko-bot [this message]
2026-09-04 11:47 ` bot+bpf-ci
2026-09-04 10:41 ` [PATCH bpf v1 3/8] bpf: Cancel special fields when recycling rhtab elements Kumar Kartikeya Dwivedi
2026-09-04 11:37 ` sashiko-bot
2026-09-04 11:41 ` Kumar Kartikeya Dwivedi
2026-09-04 11:47 ` bot+bpf-ci
2026-09-04 10:41 ` [PATCH bpf v1 4/8] selftests/bpf: Test rhtab kptr cancellation semantics Kumar Kartikeya Dwivedi
2026-09-04 10:41 ` [PATCH bpf v1 5/8] bpf: Mark NULL kptr stores precise Kumar Kartikeya Dwivedi
2026-09-04 12:12 ` sashiko-bot
2026-09-04 16:35 ` Eduard Zingerman
2026-09-04 10:41 ` [PATCH bpf v1 6/8] selftests/bpf: Test imprecise scalar kptr stores Kumar Kartikeya Dwivedi
2026-09-04 11:47 ` bot+bpf-ci
2026-09-04 10:41 ` [PATCH bpf v1 7/8] bpf: Preserve inner map identity in callback frames Kumar Kartikeya Dwivedi
2026-09-04 11:47 ` bot+bpf-ci
2026-09-04 10:41 ` [PATCH bpf v1 8/8] selftests/bpf: Test inner map identities in callbacks Kumar Kartikeya Dwivedi
2026-09-04 11:47 ` bot+bpf-ci
2026-09-04 19:30 ` [PATCH bpf v1 0/8] Misc bug fixes - part 4 patchwork-bot+netdevbpf
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=20260904111251.CC4B81F00A3D@smtp.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 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.