On Wed, 12 Mar 2025 at 13:07, Ed Maste <[email protected]> wrote: > > Our in-kernel module linker currently performs symbol resolution > against local symbols from other modules, which is a bug. > > In commits 95c20faf11a1 and ecd8245e0d77 kib introduced support to > have the kernel linker stop resolving local symbols from other files, > but did not change it by default to avoid surprises. The > debug.link_elf_leak_locals sysctl controls this behaviour, currently > defaulting to resolving against local symbols (1). Setting it to 0 > turns this off. > > I plan to flip the default soon, in advance of FreeBSD 15.0. See > PR207898 and https://reviews.freebsd.org/D47742 for more information.
This did not happen for 15.0, but should for 16.0. I flipped the default earlier today but reverted again after reports of module load failures and because it's currently stabweek. I hope to commit it again next week, and need some help identifying and resolving potential issues before doing so. A failure will show up on the system console (and in dmesg, /var/log/messages) as something like: link_elf_obj: symbol kern_kmq_open undefined linker_load_file: /boot/kernel/linux.ko - unsupported file type I'm aware of two failures so far: 1. i915kms.ko, on a system with agp built as a module PR291214, fixed by a87c1e2dd8fc 2. linux.ko (presumably) due to kern_kmq_* symbols Fix in review: https://reviews.freebsd.org/D53907 There is also a possible issue with x11/nvidia-driver, but it may not be related. Investigation is ongoing in PR291212. I would appreciate it if folks can test other modules. To do so, add the following lines to /boot/loader.conf and reboot: debug.link_elf_leak_locals=0 debug.link_elf_obj_leak_locals=0 If any module starts failing to load (with "symbol ____ undefined" console messages) please open a PR with the details. Then remove the loader.conf lines and carry on as before.
