CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS: Debug duplicate modules with auto-loading

General informations

The Linux kernel configuration item CONFIG_MODULE_DEBUG_AUTOLOAD_DUPS:

• prompt: Debug duplicate modules with auto-loading
• type: bool
• depends on: (none)
• defined in kernel/module/Kconfig
• found in Linux kernels: 6.4–6.8, 6.9-rc+HEAD

Help text

Module autoloading allows in-kernel code to request modules through the *request_module*() API calls. This in turn just calls userspace modprobe. Although modprobe checks to see if a module is already loaded before trying to load a module there is a small time window in which multiple duplicate requests can end up in userspace and multiple modprobe calls race calling finit_module() around the same time for duplicate modules. The finit_module() system call can consume in the worst case more than twice the respective module size in virtual memory for each duplicate module requests. Although duplicate module requests are non-fatal virtual memory is a limited resource and each duplicate module request ends up just unnecessarily straining virtual memory.

This debugging facility will create pr_warn() splats for duplicate module requests to help identify if module auto-loading may be the culprit to your early boot virtual memory pressure. Since virtual memory abuse caused by duplicate module requests could render a system unusable this functionality will also converge races in requests for the same module to a single request. You can boot with the module.enable_dups_trace=1 kernel parameter to use WARN_ON() instead of the pr_warn().

If the first module request used request_module_nowait() we cannot use that as the anchor to wait for duplicate module requests, since users of request_module() do want a proper return value. If a call for the same module happened earlier with request_module() though, then a duplicate request_module_nowait() would be detected. The non-wait request_module() call is synchronous and waits until modprobe completes. Subsequent auto-loading requests for the same module do not trigger a new finit_module() calls and do not strain virtual memory, and so as soon as modprobe successfully completes we remove tracking for duplicates for that module.

Enable this functionality to try to debug virtual memory abuse during boot on systems which are failing to boot or if you suspect you may be straining virtual memory during boot, and you want to identify if the abuse was due to module auto-loading. These issues are currently only known to occur on systems with many CPUs (over 400) and is likely the result of udev issuing duplicate module requests for each CPU, and so module auto-loading is not the culprit. There may very well still be many duplicate module auto-loading requests which could be optimized for and this debugging facility can be used to help identify them.

Only enable this for debugging system functionality, never have it enabled on real systems.

Hardware

LKDDb

Raw data from LKDDb:

• (none)

Sources

This page is automaticly generated with free (libre, open) software lkddb(see lkddb-sources).

The data is retrived from:

• Linux kernel
• Linux Kernel Driver DataBase (LKDDb)

Automatic links from Google (and ads)

Custom Search

Popular queries: