Addressed since v2; the current version is v3 (patch 3/9): https://lore.kernel.org/bpf/[email protected]/
Two of these are real gaps in the set of fetch sites and are fixed: - bpf_ctx_convert.t: the program context types are kernel types too, and btf_prepare_func_args() (global subprogs taking the context) and btf_translate_to_vmlinux() (ctx access of tracing/EXT programs) read the table without anything having fetched the BTF. It is now fetched in the table's readers. Tested with a socket filter whose global subprogram takes struct __sk_buff * as the first user on a fresh boot. - bpf_snprintf_btf()/bpf_seq_printf_btf(): the type id travels inside struct btf_ptr, so the arg/ret type check does not see it. The two helpers are now named explicitly. Tested with a raw_tp program calling bpf_snprintf_btf() as the first user. Also addressed: - The IS_ERR(btf_vmlinux) check in bpf_check() now reads through bpf_peek_btf_vmlinux(). With =m a failed parse is not stored (below), so it only fires for =y, where the BTF is parsed at boot as before; with =m each fetch site reports the failure itself. - btf_prepare_func_args() and btf_check_kfunc_name() check the result of bpf_get_btf_vmlinux() (pre-existing, but cheap). - A failed parse is no longer cached with =m; the payload was verified against the kernel when the module loaded, so a failure there is a resource problem and the next caller retries. =y keeps caching, as before: a parse failure there means the build is broken. Not a bug: - bpf_verifier_lock vs request_module(): the lock is only taken for unprivileged programs, and none of the fetch sites is reachable from one: kfuncs, ksyms, map pointer access and the BTF helpers all need privileged program types, and the context-type path needs a global subprogram, i.e. program BTF, which BPF_BTF_LOAD only accepts with CAP_BPF. modprobe does not load BPF programs. Jay
