Date: Tue, 19 Mar 2019 21:28:19 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 236647] kldload can choose wrong module name for hardlinked modules Message-ID: <bug-236647-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236647 Bug ID: 236647 Summary: kldload can choose wrong module name for hardlinked modules Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org When a module gets renamed, it's customary to hard link the new module name= to the old one so newly upgraded systems can still boot before they've been reconfigured. However, sometimes "kldload newname" will register the module with the old name, as shown below: root@freebsd:/boot/kernel # ls -li fuse*.ko 2328482 -r-xr-xr-x 2 root wheel 113928 Mar 19 20:00 fuse.ko 2328482 -r-xr-xr-x 2 root wheel 113928 Mar 19 20:00 fusefs.ko root@freebsd:/boot/kernel # kldload fusefs fuse-freebsd: version 0.4.4, FUSE ABI 7.8 root@freebsd:/boot/kernel # kldstat Id Refs Address Size Name 1 3 0xffffffff80200000 25140f8 kernel 2 1 0xffffffff82811000 a270 fuse.ko There are four separate functions that cause this bug. Taken individually, each one of them behaves reasonably. But the combination is problematic: 1) kldxref(8), which generates /boot/linker.hints, examines each file in tu= rn and independently writes an entry for it into the hints file. In this case= , it legitimately writes a "fusefs" =3D> "fuse.ko" entry. It writes it before t= he "fusefs" -> "fusefs.ko" entry probably because fuse.ko sorts lexicographica= lly before fusefs.ko. This behavior is reasonable, because fuse.ko _does_ technically implement the fusefs module. 2) In the kernel, linker_hints_lookup chooses the first filename from the h= ints file that matches the desired module name. This behavior is reasonable, because it would be slower to read the entire hints file, looking for the "best" matching filename. 3) linker_hints_lookup accepts filenames that don't exactly match module na= mes. This behavior is also reasonable, because a user might legitimately have multiple filenames implementing the same module, if they're at different versions or something. 4) linker_load_file registers the module by its filename, not its module na= me.=20 This might also be reasonable for the case described above where multiple f= iles implement different versions of the same module. What's the best solution? I can think of two: 1) Change linker_load_file to register by module name, not filename. 2) Add special logic to kldxref for handling multiple-linked files. Only generate one hint instead of many. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236647-227>