[Bug 236647] kldload can choose wrong module name for hardlinked modules

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236647

            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 at FreeBSD.org
          Reporter: asomers at 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 at 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 at freebsd:/boot/kernel # kldload fusefs
fuse-freebsd: version 0.4.4, FUSE ABI 7.8
root at 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 turn
and independently writes an entry for it into the hints file.  In this case, it
legitimately writes a "fusefs" => "fuse.ko" entry.  It writes it before the
"fusefs" -> "fusefs.ko" entry probably because fuse.ko sorts lexicographically
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 hints
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 names.
 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 name. 
This might also be reasonable for the case described above where multiple files
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.