From: sashiko-bot@kernel.org
To: "Mahe Tardy" <mahe.tardy@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 3/6] selftests/bpf: Add ksock kfunc test
Date: Mon, 06 Jul 2026 10:10:40 +0000 [thread overview]
Message-ID: <20260706101040.DEDBB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260706093525.13030-4-mahe.tardy@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Dead code and flawed insert logic in `ksock_ctx_insert()` due to unconditional map element overwriting.
- [Low] Unnecessary manual validation of BPF program FDs after successful skeleton load.
--
commit 559d17f26b2fc7936f58b27cbc4a4f83dacd3a73
Author: Mahe Tardy <mahe.tardy@gmail.com>
selftests/bpf: Add ksock kfunc test
Add a selftest that exercises the ksock kfuncs end-to-end. One sycall
bpf setup program creates a ksock context and connect the socket.
Another syscall bpf program lookup the context and send test data.
> diff --git a/tools/testing/selftests/bpf/prog_tests/ksock.c b/tools/testing/selftests/bpf/prog_tests/ksock.c
> new file mode 100644
> index 0000000000000..085ddb59067e8
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/ksock.c
[ ... ]
> +static bool ksock_setup_ctx(struct ksock_basic *skel)
> +{
> + LIBBPF_OPTS(bpf_test_run_opts, opts);
> + int err, pfd;
> +
> + skel->bss->ipv4_remote = inet_addr(LOOPBACK_IP);
> + skel->bss->remote_port = RECV_PORT;
> +
> + pfd = bpf_program__fd(skel->progs.ksock_setup);
> + if (!ASSERT_OK_FD(pfd, "ksock_setup fd"))
> + return false;
[Severity: Low]
This isn't a bug, but is it necessary to manually validate the program
file descriptor here?
According to the BPF subsystem selftest guidelines, after a successful
skeleton load, skeleton-generated program and map FDs are guaranteed to be
valid. Since this is called after a successful skeleton load, the
ASSERT_OK_FD check might be redundant.
> +
> + err = bpf_prog_test_run_opts(pfd, &opts);
> + if (!ASSERT_OK(err, "ksock_setup run"))
> + return false;
[ ... ]
> +void test_ksock_basic(void)
> +{
> + LIBBPF_OPTS(bpf_test_run_opts, opts);
> + struct ksock_test_env env;
> + struct ksock_basic *skel;
> + int err, pfd;
> +
> + skel = ksock_basic__open();
> + if (!ASSERT_OK_PTR(skel, "skel open"))
> + return;
> +
> + err = ksock_basic__load(skel);
> + if (!ASSERT_OK(err, "skel load")) {
> + ksock_basic__destroy(skel);
> + return;
> + }
> +
> + if (!ksock_test_env_setup(&env, NS_TEST))
> + goto fail;
> +
> + /* Step 1: Run the setup SYSCALL prog to create ksock */
> + if (!ksock_setup_ctx(skel))
> + goto fail;
> +
> + /* Step 2: Run the send SYSCALL prog */
> + pfd = bpf_program__fd(skel->progs.ksock_send);
> + if (!ASSERT_OK_FD(pfd, "ksock_send fd"))
> + goto fail;
[Severity: Low]
This isn't a bug, but similarly to the check in ksock_setup_ctx, is this
ASSERT_OK_FD necessary since the skeleton is already successfully loaded?
> +
> + err = bpf_prog_test_run_opts(pfd, &opts);
> + if (!ASSERT_OK(err, "ksock_send run"))
> + goto fail;
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/ksock_common.h b/tools/testing/selftests/bpf/progs/ksock_common.h
> new file mode 100644
> index 0000000000000..87d92372d28dc
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/ksock_common.h
[ ... ]
> +static inline int ksock_ctx_insert(struct bpf_ksock *ctx)
> +{
> + struct __ksock_ctx_value local, *v;
> + struct bpf_ksock *old;
> + u32 key = 0;
> + int err;
> +
> + local.ctx = NULL;
> + err = bpf_map_update_elem(&__ksock_ctx_map, &key, &local, 0);
[Severity: Medium]
Will this unconditional bpf_map_update_elem call defeat the intended
collision detection logic below?
Because __ksock_ctx_map is a BPF_MAP_TYPE_ARRAY map, calling
bpf_map_update_elem with a zero-initialized value (local.ctx = NULL)
will clear the existing entry and implicitly free any pre-existing kptr.
Consequently, the subsequent bpf_kptr_xchg will always see a NULL pointer,
making the if (old) check dead code and causing the function to silently
overwrite existing entries instead of returning -EEXIST.
Could the logic be adjusted to perform the lookup and exchange without
overwriting the element first?
> + if (err) {
> + bpf_ksock_release(ctx);
> + return err;
> + }
> +
> + v = bpf_map_lookup_elem(&__ksock_ctx_map, &key);
> + if (!v) {
> + bpf_ksock_release(ctx);
> + return -ENOENT;
> + }
> +
> + old = bpf_kptr_xchg(&v->ctx, ctx);
> + if (old) {
> + bpf_ksock_release(old);
> + return -EEXIST;
> + }
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260706093525.13030-1-mahe.tardy@gmail.com?part=3
next prev parent reply other threads:[~2026-07-06 10:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 9:35 [PATCH bpf-next 0/6] Introduce bpf_ksock Mahe Tardy
2026-07-06 9:35 ` [PATCH bpf-next 1/6] net: Add __sys_connect_socket() helper Mahe Tardy
2026-07-06 9:35 ` [PATCH bpf-next 2/6] bpf: Add ksock kfuncs Mahe Tardy
2026-07-06 10:01 ` sashiko-bot
2026-07-06 15:42 ` Mahe Tardy
2026-07-06 10:30 ` bot+bpf-ci
2026-07-06 15:28 ` Mahe Tardy
2026-07-06 16:58 ` Stanislav Fomichev
2026-07-06 17:26 ` Mahe Tardy
2026-07-06 20:21 ` Amery Hung
2026-07-06 21:02 ` Stanislav Fomichev
2026-07-06 22:50 ` Kuniyuki Iwashima
2026-07-06 21:33 ` Amery Hung
2026-07-06 23:01 ` Kuniyuki Iwashima
2026-07-06 9:35 ` [PATCH bpf-next 3/6] selftests/bpf: Add ksock kfunc test Mahe Tardy
2026-07-06 10:10 ` sashiko-bot [this message]
2026-07-06 16:11 ` Mahe Tardy
2026-07-06 10:16 ` bot+bpf-ci
2026-07-06 15:27 ` Mahe Tardy
2026-07-06 9:35 ` [PATCH bpf-next 4/6] selftests/bpf: Add ksock LSM recursion test Mahe Tardy
2026-07-06 9:35 ` [PATCH bpf-next 5/6] selftests/bpf: Add ksock net ns quota tests Mahe Tardy
2026-07-06 9:35 ` [PATCH bpf-next 6/6] selftests/bpf: Add ksock test for async callback guard Mahe Tardy
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=20260706101040.DEDBB1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=mahe.tardy@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