summaryrefslogtreecommitdiff
path: root/lib/crypto
diff options
context:
space:
mode:
authorLuis Chamberlain <mcgrof@kernel.org>2023-04-13 22:28:39 -0700
committerLuis Chamberlain <mcgrof@kernel.org>2023-04-19 17:26:01 -0700
commit8660484ed1cf3261e89e0bad94c6395597e87599 (patch)
tree610f317ce8366a17f3b1aaa8d753285088316ffd /lib/crypto
parenta81b1fc8ea639e03326c1d0dcde041986bc11500 (diff)
module: add debugging auto-load duplicate module support
The finit_module() system call can in the worst case use up to more than twice of a module's size in virtual memory. Duplicate finit_module() system calls are non fatal, however they unnecessarily strain virtual memory during bootup and in the worst case can cause a system to fail to boot. This is only known to currently be an issue on systems with larger number of CPUs. To help debug this situation we need to consider the different sources for finit_module(). Requests from the kernel that rely on module auto-loading, ie, the kernel's *request_module() API, are one source of calls. Although modprobe checks to see if a module is already loaded prior to calling finit_module() there is a small race possible allowing userspace to trigger multiple modprobe calls racing against modprobe and this not seeing the module yet loaded. This adds debugging support to the kernel module auto-loader (*request_module() calls) to easily detect duplicate module requests. To aid with possible bootup failure issues incurred by this, it will converge duplicates requests to a single request. This avoids any possible strain on virtual memory during bootup which could be incurred by duplicate module autoloading requests. Folks debugging virtual memory abuse on bootup can and should enable this to see what pr_warn()s come on, to see if module auto-loading is to blame for their wores. If they see duplicates they can further debug this by enabling the module.enable_dups_trace kernel parameter or by enabling CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS_TRACE. Current evidence seems to point to only a few duplicates for module auto-loading. And so the source for other duplicates creating heavy virtual memory pressure due to larger number of CPUs should becoming from another place (likely udev). Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Diffstat (limited to 'lib/crypto')
0 files changed, 0 insertions, 0 deletions