> 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?
[ ... ]
> 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;
[ ... ]
> 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?
[ ... ]
> 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.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37149955093
