Hi folks! I would like to check with you if the verifier failure I'm
facing is expected. The verifier rejects the following eBPF program on
kernel 5.10.232.
```
static long loop_fn(uint32_t index, void *ctx) {
bpf_printk("handle_exit\n");
return 0;
}
SEC("tp/raw_syscalls/sys_enter")
int test(void *ctx) {
if (bpf_core_enum_value_exists(enum bpf_func_id, BPF_FUNC_loop)) {
bpf_printk("loop\n");
bpf_loop(12, loop_fn, NULL, 0);
} else {
bpf_printk("skip loop\n");
}
return 0;
}
```
With this error:
```
libbpf: prog 'test': BPF program load failed: Invalid argument
libbpf: prog 'test': -- BEGIN PROG LOAD LOG --
number of funcs in func_info doesn't match number of subprogs
processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0
peak_states 0 mark_read 0
-- END PROG LOAD LOG --
libbpf: prog 'test': failed to load: -22
```
This sounds like a valid use case. I would like to use bpf_loop if
supported by the running kernel otherwise I can fall back to a simple
loop. This issue goes away on kernel 5.13 with the introduction of
PTR_TO_FUNC [0]. Is there a way I can use CO-RE features to avoid this
issue? I would expect the verifier to prune the dead code inside the
`if` but the error seems to be triggered before the control flow
analysis.
[0]: https://github.com/torvalds/linux/commit/69c087ba6225b574afb6e505b72cb75242a3d844
