When you use pass the -v argument to modprobe we bump
the log level from the default modprobe log level of
LOG_WARNING (4) to LOG_NOTICE (5), however the library
only has avaiable to print:
#define DBG(ctx, arg...) kmod_log_cond(ctx, LOG_DEBUG, ## arg)
#define INFO(ctx, arg...) kmod_log_cond(ctx, LOG_INFO, ## arg)
#define ERR(ctx, arg...) kmod_log_cond(ctx, LOG_ERR, ## arg)
LOG_INFO (6) however is too high of a level for it to be
effective at printing anything when modprobe -v is passed.
And so the only way in which modprobe -v can trigger the
library to print a verbose message is to use ERR() but that
always prints something and we don't want that in some
situations.
We need to add a new log level macro which uses LOG_NOTICE (5)
for a "normal but significant condition" which users and developers
can use to look underneath the hood to confirm if a situation is
happening.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
kmod_log_null() does not change ctx (does nothing).
Fix warnings
In file included from libkmod/libkmod-index.c:33:
libkmod/libkmod-index.c: In function ‘index_mm_open’:
libkmod/libkmod-index.c:757:6: warning: passing argument 1 of ‘kmod_log_null’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
757 | DBG(ctx, "file=%s\n", filename);
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
New modules.builtin.modinfo duplicates modules.builtin in the built-in
module name search. If it exists, then we can use this file, but if not,
then we need to fallback to the old file.
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
The kernel since version v5.2-rc1 exports information about built-in
modules in the modules.builtin.modinfo. Information is stored in
the same format as in the separate modules (null-terminated string
array). The module name is a prefix for each line.
$ tr '\0' '\n' < modules.builtin.modinfo
ext4.softdep=pre: crc32c
ext4.license=GPL
ext4.description=Fourth Extended Filesystem
ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
ext4.alias=fs-ext4
ext4.alias=ext3
ext4.alias=fs-ext3
ext4.alias=ext2
ext4.alias=fs-ext2
md_mod.alias=block-major-9-*
md_mod.alias=md
md_mod.description=MD RAID framework
md_mod.license=GPL
md_mod.parmtype=create_on_open:bool
md_mod.parmtype=start_dirty_degraded:int
...
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
The patch adds data fetching from the PKCS#7 certificate using
openssl library (which is used by scripts/sign-file.c in the linux
kernel to sign modules).
In general the certificate can contain many signatures, but since
kmod (modinfo) supports only one signature at the moment, only first
one is taken.
With the current sign-file.c certificate doesn't contain signer
key's fingerprint, so "serial number" is used for the key id.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signature was ignored from the modinfo. Implement its parsing
from the module data and add its output to the modinfo utility.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Currently, modprobe fails with no output by default if the
search paths it tries are missing:
$ modprobe -S notakernel dm-crypt
$
$ modprobe -S notakernel lkjjweiojo
$
This is fairly cryptic and not at all obvious there is a problem
unless the error code is checked or verbose flags are used.
Update the error message to indicate a problem and print out the
directory that failed.
usecase: two sd cards are being mounted in parallel at same time on
dual core. example modules which are getting loaded is nls_cp437.
While one module is being loaded , it starts creating sysfs files.
meanwhile on other core, modprobe might return saying the module
is KMOD_MODULE_BUILTIN, which might result in not mounting sd card.
Experiments done to prove the issue in kmod.
Added sleep in kernel module.c at the place of creation of sysfs files.
Then tried `modprobe nls_cp437` from two different shells.
While the first was still waiting for its completion ,
the second one returned saying the module is built-in.
[ Lucas:
The problem is that the creation of /sys/module/<name> and
/sys/module/<name>/initstate are not atomic. There's a small window in
which the directory exists but the initstate file was still not
created.
Built-in modules can be handled by searching the modules.builtin file.
We actually lose some "modules" that create entries in /sys/modules
(e.g. vt) and are not in modules.builtin file: only those that can be
compiled as module are present in this file.
We enforce mod->builtin to always be up-to-date when
kmod_module_get_initstate() is called. This way if the directory
exists but the initstate doesn't, we can be sure this is because the
module is in the "coming" state, i.e. kernel didn't create the file
yet, but since builtin modules were already handled by checking our
index the only reason for that to happen is that we hit the race
condition.
I also added some tweaks to the patch, so we don't repeat the code for builtin
lookup. ]
Before we had softdeps, the usual idiom was
install foo /sbin/modprobe bar; /sbin/modprobe --ignore-install foo
ignoring errors from the first modprobe invocation. This also matches
the behavior of module-init-tools' implementation of softdep.
Luis Chamberlain
Yauheni Kaliuta
Alexey Gladkov
Laura Abbott
Harish Jenny K N
Lucas De Marchi
Michal Marek