[Bug 213315] MODULE_DEPENDs are satisfied by modules that fail MOD_LOAD

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 213315
           Summary: MODULE_DEPENDs are satisfied by modules that fail
                    MOD_LOAD
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: cem at freebsd.org

This seems undesirable.

Consider a kernel object (KO1) that contains two modules, A and B.  If MOD_LOAD
succeeds for A and fails for B, KO1 is kept loaded and both A and B appear on
kern_linker.c's `found_modules` list.

Because B failed to load, only A appears on kern_module.c's `modules` list.

After this, a second kernel object (KO2) that contains a module C is loaded.  C
has a MODULE_DEPEND on B.  Because B is still on `found_modules`, C is allowed
to load.  It may fail to probe or panic if it assumes B is actually present.

Maybe that's not the promise MODULE_DEPEND makes.  But it would be nice if it
was.

The common case of one module per ko is already handled by the runtime loader
(and proposed patch to do the same in the preload linker is on phabricator:
https://reviews.freebsd.org/D8200 ).  (If the linker detects that all modules
in a KO failed to MOD_LOAD, the entire KO is unloaded.)

Fixing this just for runtime module loading maybe isn't too hard.  Load one
module at a time and only put successful modules (already maintained in
lf->modules) on the `found_modules` global list.

Solving this generally for preloaded kernel objects is more difficult, at least
without changing how preloaded KO sysinits are run.  I'm not sure changing that
is a real problem, though.

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