On Wed, Aug 28, 2024 at 12:08 PM JP Kobryn <inwardvessel@xxxxxxxxx> wrote: > > With this change, anywhere we do > register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &some_kfunc_set), > BTF_KFUNC_HOOK_TRACING becomes allowed. So even if we never register the > extra program types like PROG_TYPE_PERF_EVENT, we still allow them as a > side effect since at runtime the program type mapping returns HOOK_TRACING. > Any program type associated with this hook will be allowed even though not > explicitly registered. Correct. kfuncs differentiate by type of their arguments. prog_type -> helper was an old style when context was the only thing we had. So we had to differentiate by prog_type. kfuncs are currently register by prog_type too, but that will go away. We're planning to do large refactoring in that area to satisfy sched-ext requests. It's not the prog type that would allow or disallow certain kfuncs but rather hook point plus custom flags.
