MODULE STATISTICS DEBUGFS COUNTERS(9)

👑 module statistics debugfs counters 👑

okay bestie, welcome to module statistics debugfs counters(9) from the Kernel API Manual 💅✨ this is the group-chat breakdown of module-loading debugfs counters, and yes, we are keeping every last detail — no cap, fr fr 🫶

the total amount of wasted virtual memory allocation space during module loading can be computed by adding the total from the summation:

invalid_kread_bytes + invalid_decompress_bytes +
invalid_becoming_bytes + invalid_mod_bytes

the following debugfs counters are available to inspect module loading failures 👀:

• total_mod_size — total bytes ever used by all modules we've dealt with on this system 💖
• total_text_size — total bytes of the .text and .init.text ELF section sizes we've dealt with on this system ✨
• invalid_kread_bytes — bytes allocated and then freed on failures which happen due to the initial kernel_read_file_from_fd. kernel_read_file_from_fd uses vmalloc. these should typically not happen unless your system is under memory pressure 😭
• invalid_decompress_bytes — number of bytes allocated and freed due to memory allocations in the module decompression path that use vmap. these typically should not happen unless your system is under memory pressure 💀
• invalid_becoming_bytes — total number of bytes allocated and freed used to read the kernel module userspace wants us to read before we promote it to be processed to be added to our modules linked list. these failures can happen if we had a check in between a successful kernel_read_file_from_fd call and right before we allocate our private memory for the module which would be kept if the module is successfully loaded. the most common reason for this failure is when userspace is racing to load a module which it does not yet see loaded. the first module to succeed in add_unformed_module will add a module to our modules list and subsequent loads of modules with the same name will error out at the end of early_mod_check. the check for module_patient_check_exists at the end of early_mod_check prevents duplicate allocations on layout_and_allocate for modules already being processed. these duplicate failed modules are non-fatal, however they typically are indicative of userspace not seeing a module in userspace loaded yet and unnecessarily trying to load a module before the kernel even has a chance to begin to process prior requests. although duplicate failures can be non-fatal, we should try to reduce vmalloc pressure proactively, so ideally after boot this will be close to as 0 as possible. if module decompression was used we also add to this counter the cost of the initial kernel_read_file_from_fd of the compressed module. if module decompression was not used the value represents the total allocated and freed bytes in kernel_read_file_from_fd calls for these type of failures. these failures can occur because:
  • module_sig_check - module signature checks
  • elf_validity_cache_copy - some ELF validation issue
  • early_mod_check:
    • blacklisting
    • failed to rewrite section headers
    • version magic
    • live patch requirements didn't check out
    • the module was detected as being already present
• invalid_mod_bytes — these are the total number of bytes allocated and freed due to failures after we did all the sanity checks of the module which userspace passed to us and after our first check that the module is unique. a module can still fail to load if we detect the module is loaded after we allocate space for it with layout_and_allocate, we do this check right before processing the module as live and run its initialization routines. note that if you have a failure of this type it also means the respective kernel_read_file_from_fd memory space was also freed and not used, and so we increment this counter with twice the size of the module. additionally if you used module decompression the size of the compressed module is also added to this counter 🔥
• modcount — how many modules we've loaded in our kernel life time 👑
• failed_kreads — how many modules failed due to failed kernel_read_file_from_fd 🌸
• failed_decompress — how many failed module decompression attempts we've had. these really should not happen unless your compression / decompression might be broken 🙈
• failed_becoming — how many modules failed after we kernel_read_file_from_fd it and before we allocate memory for it with layout_and_allocate. this counter is never incremented if you manage to validate the module and call layout_and_allocate for it 🎀
• failed_load_modules — how many modules failed once we've allocated our private space for our module using layout_and_allocate. these failures should hopefully mostly be dealt with already. races in theory could still exist here, but it would just mean the kernel had started processing two threads concurrently up to early_mod_check and one thread won. these failures are good signs the kernel or userspace is doing something seriously stupid or that could be improved. we should strive to fix these, but it is perhaps not easy to fix them. a recent example are the modules requests incurred for frequency modules, a separate module request was being issued for each CPU on a system 💀

👀 SEE ALSO 👀

• Kernel file ./kernel/module/stats.c module debugging statistics overview(9) — the Kernel file reference, quoted exactly for the girlies who need it 💖
• dup_failed_modules - tracks duplicate failed modules(9) — and this one tracks duplicate failed modules, iykyk 💅

mwah 💋 — this page’s source/version is ./kernel/module, dated October 2026, and the manual tag is module stati...gfs counters(9) ✨🫶