Behaviour of bpf_core_enum_value with missing value

Behaviour of bpf_core_enum_value with missing value

[Lorenz Bauer]

Hi Andrii,

The documentation for bpf_core_enum_value says that a missing
enum_value will make the macro return 0:

* 64-bit value, if specified enum type and its enumerator value are
* present in target kernel's BTF;
* 0, if no matching enum and/or enum value within that enum is found.
*/
#define bpf_core_enum_value(enum_type, enum_value)

However, the enumval___err_missing test asserts that
bpf_core_enum_value with a missing value will poison the result if I
understand correctly.

$ sudo ./test_progs -n 31/77 -vvv
...
libbpf: prog 'test_core_enumval': relo #9: kind <enumval_value> (11),
spec is [5] typedef anon_enum::ANON_ENUM_VAL2 = 32
libbpf: prog 'test_core_enumval': relo #9: non-matching candidate #0
[6] typedef anon_enum___err_missing::ANON_ENUM_VAL1___err_missing =
273
libbpf: prog 'test_core_enumval': relo #9: no matching targets found
libbpf: prog 'test_core_enumval': relo #9: substituting insn #48 w/ invalid insn
libbpf: prog 'test_core_enumval': relo #9: substituting insn #47 w/ invalid insn
libbpf: load bpf program failed: Invalid argument

What is the correct behaviour in this case?

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com

Re: Behaviour of bpf_core_enum_value with missing value

[Andrii Nakryiko]

On Tue, Apr 20, 2021 at 6:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote:
>
> Hi Andrii,
>
> The documentation for bpf_core_enum_value says that a missing
> enum_value will make the macro return 0:
>
> * 64-bit value, if specified enum type and its enumerator value are
> * present in target kernel's BTF;
> * 0, if no matching enum and/or enum value within that enum is found.
> */
> #define bpf_core_enum_value(enum_type, enum_value)
>
> However, the enumval___err_missing test asserts that
> bpf_core_enum_value with a missing value will poison the result if I
> understand correctly.
>

I think comment is outdated. This was my initial approach, but after
discussing with Alexei we decided to keep the behavior consistent with
other types of relocation and require guarding with
bpf_core_enum_value_exists() to handle cases where enum value is
expected to not exist sometimes.

> $ sudo ./test_progs -n 31/77 -vvv
> ...
> libbpf: prog 'test_core_enumval': relo #9: kind <enumval_value> (11),
> spec is [5] typedef anon_enum::ANON_ENUM_VAL2 = 32
> libbpf: prog 'test_core_enumval': relo #9: non-matching candidate #0
> [6] typedef anon_enum___err_missing::ANON_ENUM_VAL1___err_missing =
> 273
> libbpf: prog 'test_core_enumval': relo #9: no matching targets found
> libbpf: prog 'test_core_enumval': relo #9: substituting insn #48 w/ invalid insn
> libbpf: prog 'test_core_enumval': relo #9: substituting insn #47 w/ invalid insn
> libbpf: load bpf program failed: Invalid argument
>
> What is the correct behaviour in this case?

Tests and code are right, comment is wrong. Now looking at
progs/test_core_reloc_enumval.c, /* NAMED_ENUM_VAL3 value is optional
*/ should be probably replaced with if (bpf_core_enum_value_exists())
{ out->named_val3 = bpf_core_enum_value() } else { out->named_val3 =
0xBAD } pattern or similar.

>
> Lorenz
>
> --
> Lorenz Bauer  |  Systems Engineer
> 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
>
> www.cloudflare.com