Re: [PATCH bpf-next v5 2/2] selftests/bpf: Cover attach type checks in link update

[bot+bpf-ci@kernel.org]

[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]

> diff --git a/tools/testing/selftests/bpf/prog_tests/cgroup_link.c b/tools/testing/selftests/bpf/prog_tests/cgroup_link.c
> index 15093a69510eb..3b43c34917ccc 100644
> --- a/tools/testing/selftests/bpf/prog_tests/cgroup_link.c
> +++ b/tools/testing/selftests/bpf/prog_tests/cgroup_link.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>
>  #include <test_progs.h>
> +#include "cap_helpers.h"
>  #include "cgroup_helpers.h"
>  #include "testing_helpers.h"
>  #include "test_cgroup_link.skel.h"

[ ... ]

> +static void test_cgroup_link_update(void)
> +{
> +	const __u64 caps = (1ULL << CAP_NET_ADMIN) | (1ULL << CAP_SYS_ADMIN);
> +	struct bpf_link *link = NULL;
> +	__u64 saved_caps = 0;
> +	int cg_fd = -1, err;
> +
> +	skel = test_cgroup_link__open_and_load();
> +	if (!ASSERT_OK_PTR(skel, "skel_open_load"))
> +		return;

This isn't a bug, but since this subtest never goes through
ping_and_check(), would a local `struct test_cgroup_link *skel` work
here instead of the file-scope global (which would also make the
trailing `skel = NULL;` unnecessary)?

> +
> +	err = setup_cgroup_environment();
> +	if (!ASSERT_OK(err, "cg_init"))
> +		goto cleanup;
> +
> +	cg_fd = create_and_get_cgroup("/cgroup_link_update");
> +	if (!ASSERT_GE(cg_fd, 0, "cg_create"))
> +		goto cleanup;
> +
> +	err = join_cgroup("/cgroup_link_update");
> +	if (!ASSERT_OK(err, "cg_join"))
> +		goto cleanup;

A subsystem pattern flags this as potentially concerning: the three-call
sequence setup_cgroup_environment() + create_and_get_cgroup(path) +
join_cgroup(path) is exactly what test__join_cgroup(path) provides in
test_progs.c. Using the shared helper would collapse these three blocks
(and their three separate ASSERT/goto arms) into one call plus one
ASSERT_GE(cg_fd, 0, ...). The harness also sets env.test->
need_cgroup_cleanup so teardown happens even if the subtest exits early.

The hand-rolled sequence is functionally equivalent - the three calls
are in the same order, all return values are checked, and the single
cleanup label reaches cleanup_cgroup_environment() on every failure
path. There's also a consistency argument for writing it out:
test_cgroup_link_attach() in this file hand-rolls the same sequence
because it needs four cgroups and cannot use a single-cgroup helper.
Does the test__join_cgroup() approach make sense for this subtest, or is
the hand-rolled version preferred for consistency with the sibling test?

> +
> +	link = bpf_program__attach_cgroup(skel->progs.sendmsg4, cg_fd);
> +	if (!ASSERT_OK_PTR(link, "attach_sendmsg4"))
> +		goto cleanup;
> +
> +	err = bpf_link__update_program(link, skel->progs.sendmsg6);
> +	ASSERT_EQ(err, -EINVAL, "reject_sendmsg6_update");

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/lsm_cgroup.c b/tools/testing/selftests/bpf/progs/lsm_cgroup.c
> index 3bfa479104be8..30727945cecc3 100644
> --- a/tools/testing/selftests/bpf/progs/lsm_cgroup.c
> +++ b/tools/testing/selftests/bpf/progs/lsm_cgroup.c
> @@ -213,6 +213,12 @@ int BPF_PROG(socket_first, int family, int type, int protocol, int kern)
>  	return 0;
>  }
>
> +SEC("lsm/socket_create")
> +int BPF_PROG(socket_create_lsm, int family, int type, int protocol, int kern)
> +{
> +	return 0;
> +}
> +
>  SEC("lsm_cgroup/socket_create")
>  int BPF_PROG(socket_second, int family, int type, int protocol, int kern)
>  {

[ ... ]

> diff --git a/tools/testing/selftests/bpf/progs/test_cgroup_link.c b/tools/testing/selftests/bpf/progs/test_cgroup_link.c
> index 4faba88e45a5a..a987744d129cd 100644
> --- a/tools/testing/selftests/bpf/progs/test_cgroup_link.c
> +++ b/tools/testing/selftests/bpf/progs/test_cgroup_link.c
> @@ -20,5 +20,17 @@ int egress_alt(struct __sk_buff *skb)
>  	return 1;
>  }
>
> -char _license[] SEC("license") = "GPL";
> +SEC("cgroup/sendmsg4")
> +int sendmsg4(struct bpf_sock_addr *ctx)
> +{
> +	return 1;
> +}
>
> +SEC("cgroup/sendmsg6")
> +int sendmsg6(struct bpf_sock_addr *ctx)
> +{
> +	ctx->msg_src_ip6[2] = 0;
> +	return 1;
> +}

This isn't a bug, but is the ctx->msg_src_ip6[2] store here load-bearing
for the -EINVAL assertion, or is it standing in for the out-of-bounds
write the companion patch prevents? A short comment (or making sendmsg6
as minimal as sendmsg4) would make the asymmetry between the two new
programs clearer.

> +
> +char _license[] SEC("license") = "GPL";

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33461362664