Managing Kernel Modules

Describes how to inspect loaded kernel modules, adjust parameters, and control which modules load on Oracle Linux.

Use the lsmod command to view which modules are loaded into the running kernel. Use the modinfo command to find out information about a kernel module. Use the modprobe command to load a module into the running kernel or to change kernel module parameters. You can also create configuration files in /etc/modprobe.d/ to control parameters that are used when kernel modules are loaded. You can also configure whether modules load at boot time, by editing configuration in /etc/modules-load.d/.

Listing Information About Loaded Modules

Use the lsmod command to list modules that are loaded into the kernel and use the modinfo command to find out more information about each module. For more information, see the lsmod(5) and modinfo(8) manual pages.

Run the lsmod command to list the modules that are loaded into the kernel.
```
lsmod
```
```
Module                  Size  Used by
udp_diag               16384  0
ib_core               311296  0
tcp_diag               16384  0
inet_diag              24576  2 tcp_diag,udp_diag
nfsv3                  49152  0
nfs_acl                16384  1 nfsv3
...
dm_mirror              24576  0
dm_region_hash         20480  1 dm_mirror
dm_log                 20480  2 dm_region_hash,dm_mirror
...
```
The output shows the module name, the amount of memory it uses, the number of processes using the module and the names of other modules on which it depends. The module dm_log, for example, depends on the dm_region_hash and dm_mirror modules. The example also shows that two processes are using all three modules.
Use the modinfo command to show detailed information about a module.
```
modinfo ahci
```
```
filename:       /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/ata/ahci.ko.xz
version:        3.0
license:        GPL
description:    AHCI SATA low-level driver
author:         Jeff Garzik
srcversion:     1DC2CDA088C5DC03187A5E0
alias:          pci:v*d*sv*sd*bc01sc06i01*
...
depends:        libata,libahci
intree:         Y
name:           ahci
retpoline:      Y
vermagic:       6.12.0-100.28.2.el10uek.x86_64 SMP preempt mod_unload modversions 
sig_id:         PKCS#7
signer:         Oracle CA Server
sig_key:        7B:38:D7:DC:38:51:E7:C7:F1:61:C5:5D:8D:CC:6B:1C:90:82:4D:05
sig_hashalgo:   sha512
signature:      64:05:FC:CC:B1:D3:88:91:B6:C9:A2:39:A3:A9:BB:8C:95:11:36:20:
                62:9C:95:D9:8B:B8:F6:5F:CC:D2:93:4E:7D:59:E1:80:DB:70:FA:4C:
                9B:8D:75:E3:98:AB:9D:BD:94:93:A7:72:0B:28:3B:15:4E:96:0D:E3:
                9F:FE:24:1A:09:B5:31:27:F2:EE:45:61:C8:4A:D3:4B:82:07:23:66:
                A1:06:F4:DF:B9:FF:D2:78:08:1D:AA:EC:DE:3C:E4:17:BD:69:6A:A5:

                ...
                64:F0:4F:E2:4E:F3:47:A5:40:E8:F7:07:68:3F:58:25:32:BA:13:E9:
                00:46:7A:2F:30:73:B4:32:48:76:6B:1E
parm:           marvell_enable:Marvell SATA via AHCI (1 = enabled) (int)
parm:           mobile_lpm_policy:Default LPM policy for mobile chipsets (int)
...
```
The output includes the following information:

filename

Absolute path of the kernel object file.

version

Version number of the module. Note that the version number might not be updated for patched modules and might be missing or removed in newer kernels.

license

License information for the module.

description

Short description of the module.

author

Author credit for the module.

srcversion

Hash of the source code used to create the module.

alias

Internal alias names for the module.

depends

Comma-separated list of any modules on which this module depends.

retpoline

A flag indicating that the module is built that includes a mitigation against the Spectre security vulnerability.

name

The name of the module.

intree

A flag indicating that the module is built from the kernel in-tree source and isn't tainted.

vermagic

Kernel version that was used to compile the module, which is checked against the current kernel when the module is loaded.

sig_id

The method used to store signing keys that might have been used to sign a module for Secure Boot, typically PKCS#7

signer

The name of the signing key used to sign a module for Secure Boot.

sig_key

The signature key identifier for the key used to sign the module.

sig_hashalgo

The algorithm used to generate the signature hash for a signed module.

signature

The signature data for a signed module.

parm

Module parameters and descriptions.
Use the modinfo -n command to find the file path to the module on the file system.
Modules are loaded into the kernel from kernel object files (/lib/modules/kernel_version/kernel/*ko*). To display the absolute path of a kernel object file, specify the -n option, for example:
```
modinfo -n parport
```
```
/lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/parport/parport.ko.xz
```

Loading and Unloading Modules

Modules are loaded and unloaded by using the modprobe command. For more information, see the modprobe(8) and modules.dep(5) manual pages.

Load a kernel module using the modprobe command.

The modprobe command loads kernel modules, for example:

sudo modprobe nfs
sudo lsmod | grep nfs

nfs                   266415  0 
lockd                  66530  1 nfs
fscache                41704  1 nfs
nfs_acl                 2477  1 nfs
auth_rpcgss            38976  1 nfs
sunrpc                204268  5 nfs,lockd,nfs_acl,auth_rpcgss

Include the -v (verbose) option to show whether any other modules are loaded to resolve dependencies.

sudo modprobe -v nfs

insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs_common/nfs_acl.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko 
...

Note

The modprobe command doesn't reload modules that are already loaded. You must first unload a module before you can load it again.

Unload a module by using the modprobe -r command.

Use the -r option to unload kernel modules:

sudo modprobe -rv nfs

rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs/nfs.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/lockd/lockd.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko
...

Modules are unloaded in reverse order in which they were first loaded. Modules aren't unloaded if a process or another loaded module requires them.

Changing Kernel Module Parameters

Kernel modules, such as hardware drivers, often have custom parameters that can be set to change the behavior of the driver or module. Several mechanisms are available to update module parameters.

Use sysfs to update module parameters immediately.
You can change the values of some parameters for loaded modules and built-in drivers by writing the new value to a file under /sys/module/module_name/parameters, for example:
```
echo 0 | sudo tee /sys/module/ahci/parameters/skip_host_reset
```
See About the /sys Virtual File System and sysfs Directory Reference.

Note that changes aren't persistent and don't apply automatically after reboot.
Use the modprobe command to change the running configuration for a module.
To change a module's behavior, specify parameters for the module in the modprobe command:
```
sudo modprobe module_name parameter=value ...
```
Separate parameter and value pairs with spaces. Array values are represented by a comma-separated list, for example:
```
sudo modprobe foo parm=bar arrayparm=1,2,3,4
```
Update the modprobe configuration for more permanent module configuration changes.
Configuration files (/etc/modprobe.d/*.conf) specify module options, create module aliases, and override the usual behavior of modprobe for modules with special requirements. The /etc/modprobe.conf file that was used with earlier versions of modprobe is also valid if it exists. Entries in the /etc/modprobe.conf and /etc/modprobe.d/*.conf files use the same syntax. See Modprobe Configuration Reference for more information.

Specifying Modules To Be Loaded at Boot Time

The system loads most modules automatically at boot time. You can also add modules to be loaded by creating a configuration file for the module in the /etc/modules-load.d directory. The file name must have the extension .conf.

Changes to the /etc/modules-load.d directory persist across reboots.

To force a module to load at boot time, create a configuration file in /etc/modules-load.d for the module.
For example to force the bnxt_en.conf to load at boot time, run the following command:
```
echo bnxt_en | sudo tee /etc/modules-load.d/bnxt_en.conf
```
Verify that the file exists and contains the module name.
```
cat /etc/modules-load.d/bnxt_en.conf
```
If the module isn't already loaded, you can load it manually by using the modprobe command, or you can reboot the system and it loads automatically using the configuration that you have provided.

Preventing Modules From Loading at Boot Time

You can prevent modules from loading at boot time by adding a deny rule in a configuration file in the /etc/modprobe.d directory and then rebuilding the initial ramdisk used to load the kernel at boot time.

Warning

Disabling modules can have unintended consequences and can prevent a system from booting or from being fully functional after boot. As a best practice, create a backup ramdisk image before making changes and ensure that the configuration is correct.

Create a configuration file to prevent the module from loading.

For example:

sudo tee /etc/modprobe.d/bnxt_en-deny.conf <<'EOF'
#DENY bnxt_en
blacklist bnxt_en
install bnxt_en /bin/false
EOF

Rebuild the initial ramdisk image.
```
sudo dracut -f -v
```
Reboot the system for the changes to take effect.
```
sudo reboot
```

Removing Weak Update Modules

In certain cases, you might remove weak update modules in place of a newer kernel, for example, in the case where an issue with a shipped driver has been resolved in a newer kernel. In this case, you might prefer to use the new driver rather than the external module that you installed as part of a driver update. See About Weak Update Modules for more information.

Two different approaches can be used to remove a weak update module.

Remove the symbolic link manually.
Because weak update modules are symbolically linked for each kernel version on the system, you can remove the symbolic link for the module from each kernel where you don't want it to apply. For example:
```
sudo rm -rf /lib/modules/6.12.0-100.28.2.el10uek.x86_64/weak-updates/kmod-kvdo
```
In this example, the weak update module, kmod-kvdo, is removed from the kernel, 6.12.0-100.28.2.el10uek.x86_64.
Use the weak-modules command to remove the module.
You can use the weak-modules command to remove a specified weak update module for all compatible kernels or use the command to remove the weak update module for the current kernel. You can also use the weak-modules command similarly to add weak update modules. For more information on this command, run:
```
weak-modules -h
```
You can also use the weak-modules command with the dry-run option to test the results without making actual changes, for example:
```
weak-modules --remove-kernel --dry-run --verbose
```