Since now depmod fails when there are module loops, let's at least give
better error messages, printing the loops we found. Since we may have
more than 1 loop, just printing the modules that are in loop is not
very clear.
Assuming as an example 2 independent loops, this is how the new messages
compare to the old ones:
Before:
depmod: ERROR: Found 5 modules in dependency cycles!
depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleE.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleB.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleC.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleD.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod//lib/modules/3.14.4-1-ARCH/kernel/moduleA.ko in dependency cycle!
After:
depmod: ERROR: Found 5 modules in dependency cycles!
depmod: ERROR: Cycle detected: moduleE -> moduleD -> moduleE
depmod: ERROR: Cycle detected: moduleB -> moduleC -> moduleA -> moduleB
In mod->modnamelen we were actually including the '\0', i.e.
strlen(modname) + 1. So rename it to modnamesz and add a comment in
depmod_module_is_higher_priority() to notice why it's correct since the
new one is really using strlen(modname).
Since the beginning depmod just warned about dependency loops and upon
creation of modules.dep{,.bin} it skipped the modules that were part of
a loop. However just skipping the modules may come as a surprise to
kernel module developers: they will need to try to load the module (or
to pay attention to the log messages) to notice thavt the module has not
been put in the index. Also, differently from module-init-tools we were
not skipping modules that depend on modules with dependency loops,
leading to a segfault in depmod.
So this is a summary of the change in behavior with this patch:
Loop 1)
A -> B -> C -
^ |
'------------
Before:
depmod: WARNING: found 3 modules in dependency cycles!
depmod: WARNING: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleB.ko in dependency cycle!
depmod: WARNING: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleC.ko in dependency cycle!
depmod: WARNING: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleA.ko in dependency cycle!
return code: 0
After:
depmod: ERROR: Found 3 modules in dependency cycles!
depmod: ERROR: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleB.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleC.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleA.ko in dependency cycle!
return code: 2
Loop 2)
A -> B -> C -
^ |
'-------
Before:
depmod: WARNING: found 2 modules in dependency cycles!
depmod: WARNING: /tmp/test-kmod//lib/modules/3.14.2-1-ARCH/kernel/moduleB.ko in dependency cycle!
depmod: WARNING: /tmp/test-kmod//lib/modules/3.14.2-1-ARCH/kernel/moduleC.ko in dependency cycle!
Segmentation fault (core dumped)
After:
depmod: ERROR: Found 2 modules in dependency cycles!
depmod: ERROR: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleB.ko in dependency cycle!
depmod: ERROR: /tmp/test-kmod/lib/modules/3.14.2-1-ARCH/kernel/moduleC.ko in dependency cycle!
return code: 2
The segfault above could be fixed, but let's just fail everything
because dependency cycles should be fixed in the modules rather than
just be skipped in the index.
This information can be found in /lib/modules/`uname -r`/modules.softdep, and
has only recently been exported by the kernel.
Also remove the advice about copying modules.softdep to /lib/modules as it is
not clear how to do this correctly with several kernels installed with
potentially conflicting soft dependencies.
Currently e.g. "search foo foobar built-in" will cause unpredictable
results if baz.ko is in both foo/ and foobar/, since "foo" in search may
match both of those directories and the preferred module therefore
depends on processing order.
Fix the code to ensure that the match is performed on full pathname
components only.
These redirecting makefiles simplifies compiling from some editors and
when CWD is not the root of the source tree. This is similar to what was
introduced in systemd in 340d89e ("build-sys: add small redirecting
Makefiles to simplify compilation from within emacs")
If we can open it and read it, it's good enough for us. Otherwise, we
cannot use -C /dev/null to skip the system configuration for instance:
$ ./tools/modprobe -C /dev/null -c
libkmod: ERROR libkmod/libkmod-config.c:821 conf_files_list: unsupported
file mode /dev/null: 0x21b6
...
During the last merge window (3.12) a couple of modules gained devname
aliases, but without the necessary major and minor information. These were
then silently ignored when generating modules.devname.
Complain loudly to avoid such errors sneaking in undetected in the future:
depmod: ERROR: Module 'zram' has devname (zram) but lacks major and minor information. Ignoring.
depmod: ERROR: Module 'uhid' has devname (uhid) but lacks major and minor information. Ignoring.
Cc: Kay Sievers <kay@vrfy.org>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
With readdir_r() we should be providing enough space to store the dir
name. This could be accomplished by define an union like systemd does:
union dirent_storage {
struct dirent de;
uint8_t storage[offsetof(struct dirent, d_name) +
((NAME_MAX + 1 + sizeof(long)) & ~(sizeof(long) - 1))];
};
However in all places that we use readdir_r() we have no concerns about
reentrance nor we have problems with threads. Thus use the simpler
readdir() instead.
We also remove the error logging here (that could be added back by
checking errno), but it was not adding much value so it's gone.
It occurred to an openSUSE user that our mkinitrd would throw a
warning when used with kmod:
libkmod: conf_files_list: unsupported file mode /dev/null: 0x21b6
Grepping for the error message revealed that there might be a missing
"else" keyword here, since it is unusual to put an "if" directly after
closing brace.
In containers/VM's/initrd one might not have installed any modules and
accompanying modules.devname Don't fail if this is the case, just warn.
When used in systemd this means we don't get a failing unit on booting
containers.
The reason to have a kmod-nolib binary is that we need to call kmod on
test cases (or a symlink to it) and for testing things in tree. Since
we are using libtool if we are dinamically linking to libkmod what we
end up having is a shell script that (depending on the version *)
changes argv[0] to contain an "lt-" prefix. Since this screws with our
compat stuff, we had a kmod-nolib that links statically.
This all workaround works fine iff we are using one of the compat
commands, i.e. we are using the symlinks insmod, rmmod, modprobe, etc.
However if we are actually trying the kmod binary, this doesn't work
because we can't create a kmod symlink since there's already a kmod
binary.
So, completely give up on libtool fixing their mess. Now we create a
tool/test/ directory and the symlinks and kmod is put there.
* http://lists.gnu.org/archive/html/bug-libtool/2011-12/msg00023.html
The modprobe.d (5) documentation for the "install" command
states that you could specify
install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred
This makes some sense, but then the loading of "barney" is
hidden from the user who did only "modprobe fred". Thus,
it seems it should be possible to be able to unload the
"fred" module with "modprobe -r fred" by configuring the
"barney" module to also be removed:
remove fred /sbin/rmmod barney fred
(or similar.)
Make this possible by not checking the refcount when an
unload command was configured.
Reported-by: David Spinadel <david.spinadel@intel.com>
Add __attribute__((format)) to log_filep() and _show() functions, fixing
the bugs they found in the source code.
For functions that receive va_list instead of being variadic functions
we put 0 in the last argument, so at least the string is checked and we
get warnings of -Wformat-nonliteral type. So, it's better than adding a
pragma here to shut up the warning.
This file is created by depmod even if there's no node. In this case it
will be empty.
Previously 'kmod static-nodes' was segfaulting due to passing in==NULL
to fgets.
Also show the error message with %m.
This tool reads modules.devname from the current kernel directory and outputs
the information. By default in a human-readable format, and optionally in
machine-readable formats.
For now only the tmpfiles.d(5) format is supported, but more could easily be
added in the future if there is a need.
This means nothing but kmod needs to reads the private files under
/lib/modules/. In particular systemd-udevd can stop reading modules.devname.
Tools that used to read /lib/modules/`uname -r`/modules.devname directly, can
now move to reading 'kmod static-nodes devname'.
Putting something like "alias psmouse deadbeef" is a hackish way to
blacklist a module. While I don't encourage doing so, let's not explode
if we fiund such config files.
A small difference from the behavior of module-init-tools: we exit with
0 instead of 1.
Currently modprobe -r will fail if a module is built in and report that it
is built in. rmmod calls the same function to determine state but doesn't
handle the KMOD_MODULE_BUILTIN return code. This leads to confusing errors
like this:
libkmod: kmod_module_get_holders: could not open '/sys/module/loop/holders': No such file or directory
Error: Module loop is in use
Fix this so that it actually reports the correct problem to the user.
When the prefix symbol is set, take it into account while adding symbols
from System.map file by skipping it before "__ksymtab_" comparison.
Also, prevent inserted fake symbols (like "__this_module") from being
wrongly truncated from beginning.
In depfile_up_to_date_dir() we need to check if name has a kmod
extension. "path" variable there will be the directory name, which
doesn't contain an extension.
Without this, "depmod -A" returns that the modules.dep is up to date,
even if it isn't.
In depmod_modules_search_file() it's pointless to compare the basename,
so pass only the name to be checked.
If we are replacing a lower priority module (due to its location), we
already created a kmod_module, but didn't open the file for reading its
symbols. This means mod->kmod won't be NULL, and this is just ok. Since
all the functions freeing stuff below the previous assert already takes
NULL into consideration, it's safe to just unref mod->kmod and let the
right thing happens.
We index modules in depmod by it's uncompressed relative path, not
relative path. We didn't notice this bug before since this function is
only triggered if we release a module to be replaced by one of higher
priority.
Also fix a leftover log message referring to relpath instead of
uncrelpath.
This also fixes a bug in "e6996c5 rmmod: route all messages to syslog if
told to" in which "+ verbose" was removed. Instead of letting verbose
add to kmod_get_log_priority(), let it be similar to the other programs
instead.
When user supplied --help/-h, program should output to stdout the usage,
not to stderr. It's the expected behavior, what the user asked for,
not something to log or an error.
Lucas De Marchi
Tom Gundersen
Anssi Hannula
Michal Marek
Stephen Kitt
Jan Engelhardt
Johannes Berg
Lucas De Marchi
Josh Boyer
Lucas De Marchi
Andrey Mazo
Aleksey Makarov