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: 25+ 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-07 9:41 ` Mahe Tardy
2026-07-06 21:33 ` Amery Hung
2026-07-07 9:48 ` Mahe Tardy
2026-07-06 23:01 ` Kuniyuki Iwashima
2026-07-07 10:06 ` Mahe Tardy
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 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.