On Mon, Oct 23, 2023 at 3:01 PM Dave Marchevsky <davemarchevsky@xxxxxx> wrote:
>
> The newly-added test file attempts to kptr_xchg a prog_test_ref_kfunc
> kptr into a kptr field in a variety of nested aggregate types. If the
> verifier recognizes that there's a kptr field where we're trying to
> kptr_xchg, then the aggregate type digging logic works as expected.
>
> Some of the refactoring changes in this series are tested as well.
> Specifically:
> * BTF_FIELDS_MAX is now higher and represents the max size of the
> growable array. Confirm that btf_parse_fields fails for a type which
> contains too many fields.
> * If we've already seen BTF_FIELDS_MAX fields, we should continue
> looking for fields and fail if we find another one, otherwise the
> search should succeed and return BTF_FIELDS_MAX btf_field_infos.
> Confirm that this edge case works as expected.
>
> Signed-off-by: Dave Marchevsky <davemarchevsky@xxxxxx>
> ---
> .../selftests/bpf/prog_tests/array_kptr.c | 12 ++
> .../testing/selftests/bpf/progs/array_kptr.c | 179 ++++++++++++++++++
> 2 files changed, 191 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/array_kptr.c
> create mode 100644 tools/testing/selftests/bpf/progs/array_kptr.c
>
[...]
> +SEC("tc")
> +__failure __msg("map '.bss.A' has no valid kptr")
> +int test_array_fail__too_big(void *ctx)
> +{
> + /* array_too_big's btf_record parsing will fail due to the
> + * number of btf_field_infos being > BTF_FIELDS_MAX
> + */
> + return test_array_xchg(&array_too_big[50]);
how often in practice people are going to index such arrays with a
fixed index? I'd imagine it's normally going to be a calculated index
based on something (CPU ID or whatnot). Is that supported? Can we add
a test for that?
> +}
> +
> +char _license[] SEC("license") = "GPL";
> --
> 2.34.1
>
