Bug 213315 - MODULE_DEPENDs are satisfied by modules that fail MOD_LOAD
Summary: MODULE_DEPENDs are satisfied by modules that fail MOD_LOAD
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-08 20:41 UTC by Conrad Meyer
Modified: 2016-10-08 20:41 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Conrad Meyer freebsd_committer 2016-10-08 20:41:02 UTC
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.