netdev - Re: [RFC PATCH v1 bpf-next 4/4] selftests/bpf: Test BPF_STRUCT_OPS_ASSOCIATE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzYVn=TQnF-Wfum=eQG0PsKwzySow+WFjon8D_1624ZnDA@mail.gmail.com>
Date: Mon, 13 Oct 2025 17:10:37 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Amery Hung <ameryhung@...il.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, alexei.starovoitov@...il.com, 
	andrii@...nel.org, daniel@...earbox.net, tj@...nel.org, martin.lau@...nel.org, 
	kernel-team@...a.com
Subject: Re: [RFC PATCH v1 bpf-next 4/4] selftests/bpf: Test
 BPF_STRUCT_OPS_ASSOCIATE_PROG command

On Fri, Oct 10, 2025 at 10:50 AM Amery Hung <ameryhung@...il.com> wrote:
>
> Test BPF_STRUCT_OPS_ASSOCIATE_PROG command that associates a BPF program
> with a struct_ops. The test follows the same logic in commit
> ba7000f1c360 ("selftests/bpf: Test multi_st_ops and calling kfuncs from
> different programs"), but instead of using map id to identify a specific
> struct_ops this test uses the new BPF command to associate a struct_ops
> with a program.
>
> The test consists of two set of almost identical struct_ops maps and BPF
> programs associated with the map. Their only difference is a unique value
> returned by bpf_testmod_multi_st_ops::test_1().
>
> The test first loads the programs and associates them with struct_ops
> maps. Then, the test exercises the BPF programs. They will in turn call
> kfunc bpf_kfunc_multi_st_ops_test_1_prog_arg() to trigger test_1()
> of the associated struct_ops map, and then check if the right unique
> value is returned.
>
> Signed-off-by: Amery Hung <ameryhung@...il.com>
> ---
>  .../bpf/prog_tests/test_struct_ops_assoc.c    |  76 +++++++++++++
>  .../selftests/bpf/progs/struct_ops_assoc.c    | 105 ++++++++++++++++++
>  .../selftests/bpf/test_kmods/bpf_testmod.c    |  17 +++
>  .../bpf/test_kmods/bpf_testmod_kfunc.h        |   1 +
>  4 files changed, 199 insertions(+)
>  create mode 100644 tools/testing/selftests/bpf/prog_tests/test_struct_ops_assoc.c
>  create mode 100644 tools/testing/selftests/bpf/progs/struct_ops_assoc.c
>

[...]

> +/* Call test_1() of the associated struct_ops map */
> +int bpf_kfunc_multi_st_ops_test_1_prog_arg(struct st_ops_args *args, void *aux__prog)
> +{
> +       struct bpf_prog_aux *prog_aux = (struct bpf_prog_aux *)aux__prog;
> +       struct bpf_testmod_multi_st_ops *st_ops;
> +       int ret = -1;
> +
> +       st_ops = (struct bpf_testmod_multi_st_ops *)prog_aux->st_ops_assoc;

let's have internal helper API to fetch struct_ops association, this
will give us a bit more freedom in handling various edge cases (like
the poisoning I mentioned)


> +       if (st_ops)
> +               ret = st_ops->test_1(args);
> +
> +       return ret;
> +}
> +
>  static int multi_st_ops_reg(void *kdata, struct bpf_link *link)
>  {
>         struct bpf_testmod_multi_st_ops *st_ops =
> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h b/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> index 4df6fa6a92cb..d40f4cddbd1e 100644
> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod_kfunc.h
> @@ -162,5 +162,6 @@ struct task_struct *bpf_kfunc_ret_rcu_test(void) __ksym;
>  int *bpf_kfunc_ret_rcu_test_nostruct(int rdonly_buf_size) __ksym;
>
>  int bpf_kfunc_multi_st_ops_test_1(struct st_ops_args *args, u32 id) __ksym;
> +int bpf_kfunc_multi_st_ops_test_1_prog_arg(struct st_ops_args *args, void *aux__prog) __ksym;
>
>  #endif /* _BPF_TESTMOD_KFUNC_H */
> --
> 2.47.3
>