The scenario does not happen; v4 keeps this behaviour: https://lore.kernel.org/bpf/[email protected]/
With CONFIG_DEBUG_INFO_BTF=m an allocation failure of the parse is not stored: bpf_load_btf_vmlinux(), which parses the BTF in v4, returns the error without publishing it, btf_vmlinux stays NULL, the next request retries, and this check does not fire for anyone. What v4 does store with =m, as a later bpf-ci review asked, is a parse failure for any other reason. The payload was checked against the kernel's size and SHA-256 when btf_vmlinux.ko loaded, so that means the build produced a broken BTF. The same happens with =y, where upstream already fails every later bpf_check() with this message. With =y the parse happens at boot, through the first vmlinux kfunc registration, as it does today. Jay
