Load modules from /lib/modules for 4kb page size kernels when
the -d option is not present. Do not do this for 16kb page size kernels
due it will load the 4kb modules when PRODUCT_16K_DEVELOPER_OPTION
is true.
Depending on the value of PRODUCT_16K_DEVELOPER_OPTION, the
kernel modules can be located in several directories:
- true: There are 2 directories that contain the 4kb and 16kb
modules.
- 4kb modules are in /lib/modules
- 16kb modules are in /lib/modules/<uname -r>_16k
- false: There is only one directory that contains only one type
of the kernel modules, either 4kb or 16kb.
- /lib/modules
This is a temporary fix for the 16kb developer option. This
b/346659501 will track the proper fix.
Test: Boot target husky-trunk_staging-userdebug with developer
option.
Test: Boot target husky_pgagnostic-next-userdebug without developer
option.
Bug: 345609905
Bug: 343971855
Change-Id: I9bab33d9f06743bd10ee804b20db8f39467fcc52
When modules for multiple kernels with the same major/minor versions
are installed on a device, modprobe will search the module directories
based on whatever order scandir() returned them. In this case, it is
possible that we will try to load modules with the wrong page size for
the running kernel, which can lead to obscure symbol CRC mismatches and
ultimately a system crash.
Adjust the scandir() filtering function so that the kernel page size is
taken into account in addition to the major/minor versions returned by
utsname(). The general rule is that module directories ending in "_Nk"
contain modules for a page-size of N KiB, whilst the absence of such
a suffix implies the default of 4 KiB.
Bug: 343971855
Test: Verified that _16k module directory is excluded by modprobe when running in userspace fastboot with 4k pages.
Change-Id: I78a0a249028bbb0bcdd78eb14de36e631e233be0
This reverts commit ffdb017e7d.
Overriding an explicitly-specified module path (e.g. passed via the
'-d <path>' argument) because the kernel is using 16KiB pages is
inconsistent and unexpected. Revert this change in anticipation of
filtering incompatible modules instead.
Bug: 343971855
Test: Verified that _16k module directory is excluded by modprobe when running in userspace fastboot with 4k pages.
Change-Id: If9c6e2d26fc53b12f543d531d64ef3d288ddc179
When a file is provided (via --all=FILE), let's use libmodprobe to load
the modules. This let's us use the logic in libmodprobe to parse the
provided modules load file -- FILE. The functional differences include:
- Removes the FILE parsing logic in modprobe.
- Returns early if FILE doesn't exist.
- Adds Dirname(FILE) to mod_dirs which means libmodprobe will parse the
modules.* files inside Dirname(FILE). Previously, modprobe would only
parse the modules.* files in the mod_dirs passed in by `-d DIR`. If
no directories were provided, we would fallback to the default
/lib/modules path. This patch removes the mod_dirs.empty() fallback
path when --all=FILE is used. It's unlikely anyone uses `--all=FILE`
without `-d DIR` unless FILE is inside the fallback path --
/lib/modules.
Test: verified lsmod on pixel 6
Bug: 324018983
Change-Id: I8d241832f2a1f18d14207e3e3777e015c1ddb25f
When a module is blocklisted, LoadWithAliases() will return an error
indicating the module failed to load. When the blocklist is requested
(via the -b parameter), let's not return an error if a blocklisted
module fails to load.
Test: verified lsmod on pixel 6
Bug: 324018983
Change-Id: I68f7d46bf9fd99e4b4e51ef92ea71686907f1125
Due to GKI, the kernel UTS release string will not always (if ever)
match the vendor's UTS release string that is used to create the
initramfs file structure -- /lib/modules/<vendor uname>. This causes
module load failures when `-d DIR` is omitted. To fix this, we can
include all of the versions under /lib/modules that match the kernel's
major and minor version instead of directly using the value of uname().
In addition, we can also support modules being loaded directly from
/lib/modules.
Test: verify GKI kernel + initramfs with different UTS strings
Test: verify GKI kernel + initramfs with modules directly in /lib/modules
Fixes: 8320778425 ("toolbox/modprobe: Fallback to /lib/modules/<uname> ")
Bug: 282917063
Bug: 254835242
Change-Id: I5368f5cff139ba3165323a6a91066be38bfa0736
Make the module directory optional by reading the kernel release
version. This path is where the kernel installs modules by default.
Similar behaviour can be found in several modprobe implementations.
Bug: 254835242
Change-Id: I61707636705e5b4d9bd8ccf6351e7057eae6bcf5
Remove the function EnableBlocklist() and add a constructor argument to
enable/disable the use of modules.blocklist. In all cases, the
enabling/disabling of the blocklist happens immediately after creating
the Modprobe object. So this simplies libmodprobe.
Additionally, the use of the blocklist by libmodprobe should be enabled
by default unless explicitly disabled during creation of the Modprobe
object. Currently, only modprobe(8) defaults to not using the blocklist
and includes the argument -b BLOCKLIST for enabling it. That
functionality remains.
This refactor allows us to use the blocklist during first stage init.
However, additional logic is needed to not return an error for the
blocked non-aliased modules during first stage init; otherwise, the
error would result in an init crash leading to a device reboot. So fixup
LoadListedModules() to allow blocking modules without returning an
error.
Bug: 182582036
Test: boot test on pixel 5 with a module in modules.blocklist
Change-Id: I394b5aa98fa98821011982cfe693749010c381f7
There is a desire to ensure that modprobe as a service can log to
kmesg to help triage issues, so add support for the -s or --syslog
flag to do so.
SideEffects:
- help goes to stdout instead of stderr.
- verbose flag once, sets DEBUG, twice, sets VERBOSE minimum.
- quiet flag sets WARNING minimum.
Bug: 159424228
Bug: 151950334
Test: use modprobe as a service to load modules, check logs
Change-Id: I884995f364b0fc604861797eb90d7225a372f864
Add a means to specify the modules to load from a file, rather than
on the argument list by adding an optional argument to the --all flag.
This allows modprobe to be designated as a standalone service to load
a long series of modules in the background and be specified
separately. The specified (module.load) file contains a newline
separate list of module names, and supports line comments using '#'
since this file may be maintained by a human or scripting that
requires tagging for regions of the file.
Bug: 159424228
Bug: 151950334
Test: use modprobe as a service to load modules
Change-Id: Id32641c7244e65848fca3a4a82c8d08b2042bf2f
Add support for long options, and fit existing options to upstream
behaviors and extensions. Fix some missing std::endl and
android::base::Join() usage.
Bug: 159424228
Bug: 151950334
Test: manually test long options work
Change-Id: Id792d87d4407628e706aeccecb6e2bce22bcad10
