The -f switch is accepted by insmod, but silently ignored. This
causes the user to wonder why things don't work. As insmod is
most often used with "evil" modules, -f is almost default and
thus needs to work.
Signed-off-by: Philippe De Swert <philippe.deswert@jollamobile.com>
Currently, if a value that doesn't match a kernel version
("%u.%u") is passed in, depmod silently falls back to
using uname. Rather than try and work around the caller passing
bad data, just exit out instead.
In between the start of the program and the call to log_setup_kmod_log,
the only messages that will be printed are the ones at or above the
global default level. Debug messages in this range will never be printed
so remove them.
The default log level is currently LOG_ERR. Tools can override this
default but there is a non-trivial amount of setup that needs to
happen before the log level can be changed. Since tools may want to
use the warn level for things such as deprecated flags, change the
default to LOG_WARNING to ensure messages get printed.
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.
While using "localyesconfig" to build a custom kernel I noticed that
lsmod output now has trailing spaces when the list of "Used by" modules
is empty.
The following patch just delays the space to the point where we are sure
that there are more things to print.
builtin modules are handled in libkmod by looking at the modules.builtin
index. There's no need to check again for the module's initstate to
decide if it's builtin.
malloc(0) can return != NULL. We need to pass the pointer to free().
This happens if index__haschildren(node) returned true, but
child_count is set to 0.
Reusing the root variable was a bad idea. Doing so we could call free()
on a variable that was not allocated. For example: "depmod -b / -h".
Since we would jump to cmdline_failed, root would not be duplicated.
Instead of fighting the order in the options, just used the cleanup
attribute and remove the calls to free() on "config_paths" and "root".
Make the includes be libkmod/libkmod.h for code outside of library. This
fixes the broken build after 1315123 ('build-sys: Don't add libkmod
subdirectory to include path').
Instead of repeating all documentation, point to the documentation
available in libkmod-index.c
This also removes INDEX_PRIORITY_MIN that was not being used.
udev will only manage static nodes that exist at the time udev is started, so
creating static nodes later on will likely not behave as expected. In
particular, recreating the static nodes at run-time will reset any permissions
udev may have applied to the nodes at boot.
See <https://bugzilla.redhat.com/show_bug.cgi?id=1147248> and the discussion
following <http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/23795>.
Note that this requires (the yet to be released) systemd v217 or a backport
of systemd patch 8c94052ee543c3598a3c7b0c46688150aa2c6168.
This function was declared as always-inline so there was not really a
problem in returning prioname, that could possibly point to the local
buf[] variable.
However static analysis tools are often confused about this and being
always-inline was just a workaround to make it work.
So, let's move the buffer to the caller. We have only 2 callers so it
doesn't matter much. This always reduce the size of log.o, since now the
function is not inlined anymore. Below is the size for "-g -O2" with
gcc:
before:
text data bss dec hex filename
1325 4 1 1330 532 tools/log.o
after:
text data bss dec hex filename
1171 4 1 1176 498 tools/log.o
The only user outside of libkmod-util is depmod, which really only needs
to get the string for the extension of uncompressed modules. It doesn't
need to access the array itself.
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.
When we are logging to stderr we are previously relying on libkmod
sending it to the default location in case we are not asked to log to
syslog. The problem is that modprobe may be used in scripts that don't
want to log to syslog (since they are not daemons, like scripts to
generate initrd) and then it's difficult to know where the message comes
from.
This patch treats only the messages coming from libkmod.
Once we read all we need from a module, unref it so any resource taken
by it (including the mmap to access the file in libkmod) will be
dropped. This drastically reduces the number of open file descriptors
and also the memory needed, with no performance penalties. Rather,
there's a small speedup of ~2.6%.
Running depmod in a laptop with 2973 modules and comparing the number of
open file descriptors for kmod-10, before and after the last patches to
depmod (caaf438cb6 and HEAD) we have:
Before: 2980 simultaneously open fds
After: 7 simultaneously open fds
kmod-10: 7 simultaneously open fds
So now we have the speedup of caching the file in kmod_module without
the drawback of increasing the number of open file descriptors.
In depmod_module_add() we already called kmod_module_get_name() and
copied the string to our struct. Use it instead of calling again and
again the libkmod function.
The overall goal is to coalesce the accesses to a file that is the
backend of a module. This commit addresses the calls to
kmod_module_get_get_dependency_symbols(). Calling it earlier, while we
are iterating the modules allows us to free the struct kmod of each
module much sooner. We are still not freeing it since there are other
places that must be refactored first.
There's a performance penalty of ~2.5% from previous commit.
The overall goal is to coalesce the accesses to a file that is the
backend of a module. This commit addresses the calls to
kmod_module_get_info(). Calling it earlier, while we are iterating the
modules allows us to free the struct kmod of each module much sooner. We
are still not freeing it since there are other places that must be
refactored first.
A nice side effect is that this commit reduces in ~33% the calls to
malloc(), giving a speedup of ~6% for cold caches (reproduced on only 1
laptop).
We now index the modules by uncompressed-relative-path instead of
relative-path. This is because the file modules.order, coming from
kernel, always comes with uncompressed paths. This fixes the issue of
not sorting the aliases correctly due to paths not matching when using
compressed modules.
This is a broken option that only leads to misery and incompatabilities
with other systems. Kbuild doesn't come close to supporting directories
other than /lib/modules with several targets simply failing without
hacky fixes. Simply remove the option and all traces of it, as it
doesn't make sense in today's world.
This fixes a change in behavior regarding kmod and module-init-tools:
when trying to load a module by alias, we should check if it's
blacklisted, regardless of the command line arguments passed.
This was reported by "Dmitry V. Levin <ldv@altlinux.org>".
Only the public header maintains #ifndef in the header, together with
pragma. The other ones contain only pragma.
As reported by Shawn Landden on systemd mailing list this is compatible
with all major compilers and gcc has this since version 3.3.
Before:
=======
[lucas@vader kmod]$ sudo depmod
[lucas@vader kmod]$ echo $?
0
[lucas@vader kmod]$ ls -l /lib/modules/$(uname -r)
total 12
drwxr-xr-x 8 root root 160 Jun 13 11:05 kernel
-rw-r--r-- 1 root root 12288 Jun 15 21:29 modules.alias
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.alias.bin
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.dep
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.dep.bin
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.devname
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.softdep
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.symbols
-rw-r--r-- 1 root root 0 Jun 15 21:29 modules.symbols.bin
Note that modules.alias is truncated and the other have size == 0
After:
======
[lucas@vader kmod]$ sudo ./tools/depmod
WARNING: could not open /lib/modules/3.5.0-rc2-demarchi-00028-g94fa83c/modules.order: No such file or directory
ERROR: Could not create index: output truncated: No space left on device
[lucas@vader kmod]$ echo $?
1
Philippe De Swert
Laura Abbott
Lucas De Marchi
Santiago Vila
Caio Marcelo de Oliveira Filho
Colin Walters
Tom Gundersen
Anssi Hannula
Michal Marek
Stephen Kitt
Jan Engelhardt
Johannes Berg
Lucas De Marchi
Josh Boyer
Lucas De Marchi
Andrey Mazo
Aleksey Makarov
Dave Reisner