No change for this in v3: https://lore.kernel.org/bpf/[email protected]/
This cannot be reached with btf_vmlinux NULL. In check_reg_type(), for ARG_PTR_TO_BTF_ID and ARG_PTR_TO_BTF_ID_SOCK_COMMON without meta->btf, arg_btf is only used when the register is PTR_TO_BTF_ID; a PTR_TO_SOCKET, PTR_TO_SOCK_COMMON or PTR_TO_TCP_SOCK argument breaks out before it. A PTR_TO_BTF_ID register only comes from a place that has loaded the vmlinux BTF: attach_btf, kfunc returns, BTF-typed helper returns, map pointer access, the program context types, kptrs (bpf_find_btf_id() fetches it), or a ksym. The ldimm64 case in the report needs a module BTF fd, and with =m a module BTF only gets an id once the vmlinux BTF is published: bpf_get_btf_vmlinux() does smp_store_release(&btf_vmlinux) before btf_parse_deferred_modules() parses and registers the modules kept until then, and a module loaded afterwards is parsed against the published vmlinux BTF. So a program holding a module BTF implies a non-NULL btf_vmlinux. Matching ARG_PTR_TO_BTF_ID_SOCK_COMMON in helper_uses_vmlinux_btf() would load the vmlinux BTF for every tc, XDP and sk_lookup program that calls bpf_sk_release() on a socket from bpf_sk_lookup_*(), which never touches kernel BTF, so the series leaves it out. Jay
