Re: [PATCH v3 bpf-next 3/7] kbuild, btf: Expose vmlinux inline BTF through sysfs

[Alan Maguire <alan.maguire@oracle.com>]

On 03/10/2026 21:41, bot+bpf-ci@kernel.org wrote:
>> kbuild, btf: Expose vmlinux inline BTF through sysfs
> 
> TL;DR:
> - Module load may fail with -ENOENT for modules without .BTF or with BTF
>   mismatch allowed
> - mmap of /sys/kernel/btf/vmlinux may return -EINVAL on arm64
> - __SIZEOF_LONG__ may break 32-bit builds
> - Nits: .gitignore, NULL return
> 
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index b2988aa12f66..863f02660bc3 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
> 
> [ ... ]
> 
>> @@ -675,12 +675,39 @@
>> +#ifdef CONFIG_DEBUG_INFO_BTF_INLINE_MODULE
>> +/* __MODULE_NAME_LEN + SHA-256 digest + u32 BTF size */
>> +#define BTF_LINK_SIZE	(64 - __SIZEOF_LONG__ + 32 + 4)
>> +#define BTF_INLINE_LINK						\
>> +	. = ALIGN(PAGE_SIZE);					\
>> +	.BTF.inline.link : AT(ADDR(.BTF.inline.link) - LOAD_OFFSET) { \
>> +		__start_BTF_inline_link = .;				\
>> +		BYTE(0)						\
>> +		. += BTF_LINK_SIZE - 1;					\
> 
> Is __SIZEOF_LONG__ reliable in a linker script?
> 
> The lds is preprocessed with KBUILD_CPPFLAGS only.  On x86, -m32 is added
> only to KBUILD_CFLAGS and KBUILD_AFLAGS, and with clang KBUILD_CPPFLAGS
> carries --target=x86_64-linux-gnu for all of SRCARCH=x86.  So for a 32-bit
> x86 build with clang, or with a gcc whose default target is x86_64,
> __SIZEOF_LONG__ is 8 while the lds is preprocessed, and BTF_LINK_SIZE
> becomes 64 - 8 + 32 + 4 = 92.
> 
> On a 32-bit kernel __MODULE_NAME_LEN is 64 - sizeof(unsigned long) = 60, so
> sizeof(struct btf_link) is 96.
> 
> With CONFIG_DEBUG_INFO_BTF_INLINE=m, link-vmlinux.sh runs:
> 
>   resolve_btfids --btf_link .BTF.inline:btf_vmlinux_inline:vmlinux.BTF.inline
> 
> patch_btf_link() uses module_name_len = BTF_LINK_MODULE_NAME_MAX - 4 for
> ELFCLASS32 and rejects the section if
> 
>   data->d_size != module_name_len + BTF_SHA256_DIGEST_LENGTH + sizeof(u32)
> 
> Since 92 != 96, it prints "FAILED: section .BTF.inline.link is not a
> writable BTF link", returns -1, and the vmlinux link fails.  Even if the
> build got past that, btf_parse_link() checks size != sizeof(*link) and would
> reject the record.
> 
> riscv32 looks the same: -mabi=ilp32 is only in KBUILD_CFLAGS and
> KBUILD_AFLAGS, and the clang target is riscv64-linux-gnu.
> 
> Could this use something tied to Kconfig instead, such as #ifdef
> CONFIG_64BIT, or BITS_PER_LONG / 8 from asm/bitsperlong.h, rather than the
> compiler's default ABI macro?
> 
> [ ... ]
> 

yeah CONFIG_64BIT probably safest approach, will fix.

>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 0630675377aa..732ba0684667 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
> 
> [ ... ]
> 
>> @@ -9015,21 +9016,122 @@ static DEFINE_MUTEX(btf_module_mutex);
>> +static const struct btf_link *btf_parse_link(void *start, unsigned int size)
>> +{
>> +	const struct btf_link *link = start;
>> +	unsigned int module_name_len;
>> +
>> +	if (!link || size != sizeof(*link))
>> +		return NULL;
>> +
>> +	if (link->btf_size == 0)
>> +		return 0;
> 
> this isn't a bug, but btf_parse_link() returns a pointer and this path
> returns a plain integer 0 where the other failure paths return NULL.  sparse
> reports "Using plain integer as NULL pointer" here.
> 
> The only caller, btf_vmlinux_inline_lazy_init(), handles this the same way
> as the other failures and prints "invalid vmlinux inline BTF link".  Could
> this return NULL, or be folded into the check above?
> 
> [ ... ]
> 
>>  static int btf_module_notify(struct notifier_block *nb, unsigned long op,
>>  			     void *module)
>>  {
>> [ ... ]
>>  	int err = 0;
>>
>> -	if (mod->btf_data_size == 0 ||
>> -	    (op != MODULE_STATE_COMING && op != MODULE_STATE_LIVE &&
>> -	     op != MODULE_STATE_GOING))
>> +	if (op != MODULE_STATE_COMING && op != MODULE_STATE_LIVE &&
>> +	    op != MODULE_STATE_GOING)
>>  		goto out;
>>
>>  	switch (op) {
>>  	case MODULE_STATE_COMING:
>> +		err = btf_module_handle_vmlinux_inline(mod);
>> +		if (err != -ENOENT) {
>> +			err = 0;
>> +			break;
>> +		}
>> +		if (!mod->btf_data_size)
>> +			break;
>>  		btf_mod = kzalloc_obj(*btf_mod);
> 
> Can this reject every module that has no .BTF section?
> 
> btf_module_handle_vmlinux_inline() returns -ENOENT for any module that is
> not the vmlinux inline carrier, and the
> !IS_MODULE(CONFIG_DEBUG_INFO_BTF_INLINE) stub returns -ENOENT
> unconditionally.  That value stays in err.
> 
> The old code returned early with err == 0 when mod->btf_data_size was 0.
> Now a module without .BTF hits:
> 
> 		if (!mod->btf_data_size)
> 			break;
> 
> and btf_module_notify() returns notifier_from_errno(-ENOENT) from the out:
> label.
> 
> The same leftover err is returned when btf_parse_module() fails with
> CONFIG_MODULE_ALLOW_BTF_MISMATCH=y:
> 
> 		if (IS_ERR(btf)) {
> 			kfree(btf_mod);
> 			if (!IS_ENABLED(CONFIG_MODULE_ALLOW_BTF_MISMATCH)) {
> 				...
> 			} else {
> 				pr_warn_once("Kernel module BTF mismatch detected, ...");
> 			}
> 			goto out;
> 		}
> 
> That branch never resets err, so a mismatched module, which that option
> exists to let load, now fails with -ENOENT as well.
> 
> notifier_from_errno() sets NOTIFY_STOP_MASK, notifier_call_chain_robust()
> rolls back the COMING chain, prepare_coming_module() returns
> notifier_to_errno() == -ENOENT, and load_module() goes to bug_cleanup.  The
> module load then fails with "No such file or directory".
> 
> Modules without .BTF are a normal case.  scripts/Makefile.modfinal prints
> "Skipping BTF generation for %s due to unavailability of vmlinux" for
> external/DKMS modules, and the kernel.spec comment changed in this same
> commit says eu-strip removes .BTF when find-debuginfo has no --keep-section.
> Before this patch both cases loaded fine.
> 
> The problem is still there at the end of the series (e1c2367cf1b5);
> 3357b172196f ("btf: Relocate and expose module inline BTF") keeps the same
> COMING prologue.
> 
> Would resetting err to 0 when the helper returns -ENOENT work?
> 
> 	err = btf_module_handle_vmlinux_inline(mod);
> 	if (err != -ENOENT) {
> 		err = 0;
> 		break;
> 	}
> 	err = 0;
> 
> [ ... ]
> 

Yeah we don't need to keep err here so we can just check
the return value; if not -ENOENT, break.


>> diff --git a/kernel/bpf/sysfs_btf.c b/kernel/bpf/sysfs_btf.c
>> index 9cbe15ce3540..a3c54b5fe294 100644
>> --- a/kernel/bpf/sysfs_btf.c
>> +++ b/kernel/bpf/sysfs_btf.c
> 
> [ ... ]
> 
>> @@ -33,24 +31,149 @@ static int btf_sysfs_vmlinux_mmap(struct file *filp, struct kobject *kobj,
>> +static int btf_sysfs_mmap_direct(struct file *filp, struct kobject *kobj,
>> +				 const struct bin_attribute *attr,
>> +				 struct vm_area_struct *vma)
>> +{
>> +	void *data = READ_ONCE(attr->private);
>> [ ... ]
>> +	err = btf_sysfs_mmap_check(data, attr->size, vma);
>> +	if (err)
>> +		return err;
>> +	if (is_vmalloc_addr(data))
>> +		return remap_vmalloc_range(vma, data, 0);
>> +
>> +	addr = __pa_symbol(data);
>> [ ... ]
>>  static struct bin_attribute bin_attr_btf_vmlinux __ro_after_init = {
>>  	.attr = { .name = "vmlinux", .mode = 0444, },
>>  	.read = sysfs_bin_attr_simple_read,
>> -	.mmap = btf_sysfs_vmlinux_mmap,
>> +	.mmap = btf_sysfs_mmap_direct,
>>  };
> 
> Does this break mmap() of /sys/kernel/btf/vmlinux on arm64?
> 
> bin_attr_btf_vmlinux now uses btf_sysfs_mmap_direct(), which chooses between
> remap_vmalloc_range() and remap_pfn_range() based on is_vmalloc_addr(data).
> On arm64 the kernel image lives inside the vmalloc range:
> 
>   arch/arm64/include/asm/memory.h:  #define KIMAGE_VADDR (MODULES_END)
>   arch/arm64/include/asm/pgtable.h: #define VMALLOC_START (MODULES_END)
> 
> So is_vmalloc_addr(__start_BTF) returns true, and the call goes to
> remap_vmalloc_range() -> remap_vmalloc_range_partial().  There,
> find_vm_area() finds the vm_struct that declare_kernel_vmas() registered for
> the image rodata segment:
> 
>   declare_vma(&vmlinux_seg[1], __start_rodata, __inittext_begin, VM_NO_GUARD);
>   ...
>   vma->flags = VM_MAP | vm_flags;
> 
> That vm_struct has no VM_USERMAP, so this check:
> 
>   if (!(area->flags & (VM_USERMAP | VM_DMA_COHERENT)))
>           return -EINVAL;
> 
> fails and mmap() returns -EINVAL.  Before this patch,
> btf_sysfs_vmlinux_mmap() always used __pa_symbol(__start_BTF) plus
> remap_pfn_range(), which worked on arm64 since .BTF sits inside RO_DATA,
> between __start_rodata and __inittext_begin.
> 
> The same applies to the built-in /sys/kernel/btf/vmlinux.inline, which the
> commit message says supports read-only mmap().  The selftest
> test_btf_mmap_sysfs("/sys/kernel/btf/vmlinux") would fail on arm64 as well.
> 
> Would it be better to use remap_vmalloc_range() only for the lazily
> populated vmalloc_user() entries, for example from btf_sysfs_mmap_lazy() or
> by recording the backing type in struct btf_sysfs_entry, and keep the
> __pa_symbol()/remap_pfn_range() path for kernel image data instead of
> testing the address range?
>

yep, this is a good catch, will do this/retest on aarch64.
 
> [ ... ]
> 
>> diff --git a/scripts/gen-btf.sh b/scripts/gen-btf.sh
>> index 8ca96eb10a69..e638291753d0 100755
>> --- a/scripts/gen-btf.sh
>> +++ b/scripts/gen-btf.sh
> 
> [ ... ]
> 
>> @@ -83,14 +88,28 @@ gen_btf_o()
>> +	btf_inline=${ELF_FILE}.BTF.inline
>> +	if [ "${BTF_INLINE}" = "m" ]; then
>> +		if [ -f "${btf_inline}" ]; then
>> +			cp "${btf_inline}" "${objtree}/vmlinux.BTF.inline"
>> +		else
>> +			rm -f "${objtree}/vmlinux.BTF.inline"
>> +		fi
>> +	fi
> 
> With CONFIG_DEBUG_INFO_BTF_INLINE=m, this leaves a long-lived top-level
> build artifact, vmlinux.BTF.inline.  link-vmlinux.sh reads it for
> --btf_link, and Makefile.modfinal reads it later to embed .BTF.inline into
> btf_vmlinux_inline.ko.
> 
> The patch adds it to CLEAN_FILES in the top-level Makefile but not to
> .gitignore, where the other top-level vmlinux artifacts are listed
> (/vmlinux, /vmlinux.32, /vmlinux.map, /vmlinux.symvers,
> /vmlinux.thinlto-index, /vmlinux.unstripped).  In an in-tree build,
> "git check-ignore -v vmlinux.BTF.inline" returns nothing, so the file shows
> up as untracked in git status.
> 
> Should /vmlinux.BTF.inline be added to .gitignore next to
> /vmlinux.unstripped?  The later commits in the series (f61c6417ac15 through
> e1c2367cf1b5) do not touch .gitignore.
>

yep, will do.