d46136bb59 ("depmod: Ignore PowerPC64 ABIv2 .TOC. symbol") adds fake
.TOC. unconditionally but when there is .TOC. in the kernel adding the
fake one breaks resolving .TOC.
Fixes: d46136bb59 ("depmod: Ignore PowerPC64 ABIv2 .TOC. symbol")
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
The idea is to add a configuration keyword, external, which
will list directories for scanning for particular kernel version
mask:
external 4.10 /the/modules/dir /second/modules/dir
And extend "search" keyword to set it's priority with pseudo dir
"external" (as it's done for built-in):
search subdir external subdir2 built-in subdir3
(actually, the version is the same as for override keyword: * or
posix regexp, so example above is a bit incorrect).
All other logic left the same: if there are duplicates, only one
is under consideration and it is unloadable if it is bad.
The resulting modules.dep will contain entries a-la:
/the/modules/dir/module1.ko:
kernel/module2.ko: /the/modules/dir/module1.ko
(here /lib/modules/$(uname -r)/kernel/module2.ko depends of
symbols, provided by /the/modules/dir/module1.ko and external has
higher priority).
modprobe and modinfo understand it out of box.
This is a pretty simple extention of existing logic, since now
depmod already is able to:
a) scan modules with full path from command line without -a
switch;
b) detects broken symbol dependencies and broken modversions,
what assumes, that modules are already are not built for the
existing kernel.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
The recursive search code used used pretty big, PATH_MAX,
automatic storage buffer for the module directory scanning. Some
time ago there was scratchbuf implemented, which dynamically
reallocates its buffer on demand. The patch takes it in use for
the scanning code also. The initial size is hardcoded to 256
bytes which sounds good enough for most usecases so there should
be not many reallocations.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Prepare to implement external directories support.
The patch splits depmod_modules_search() function to two
functions: depmod_modules_search(), called by the high level with
intention to search all possible modules, and
depmod_module_search_path(), which takes path as a parameter and
scans modules under the path only. Initially it is used to scan
the same depmod->cfg->dirname path only.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Prepare to implement external directories support.
It's better to isolate behaviour difference under the
cfg_search_add() call, then make the client code aware of it.
In case of external modules/directories support, there will be
one more keyword added, so making the clients aware of it makes
even less sense.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
The c7ce9f0c80 commit (depmod:
handle nested loops) introduced a bunch of possible memory leaks
in error path. In the real world scenario it is not a problem,
since the utility quits if it detects any of the errors, but from
the programming point of view, it is not nice. So, add the
cleanups.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
This is a rework of depmod report cycles logic to make it
tolerant to more complex loops.
The patch tries to remember own path for vertexes which makes it
possible to handle configurations with common edges and
non-cyclic modules.
It assumes that the previous dependency calculations can not give
as input something like
mod_a -> mod_b -> <loop>, but
<loop> -> mod_a -> mod_b should be fine.
Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Only print actual cyclic dependencies. Print count of all the modules
in cyclic dependency at the end of the function so that dependent
modules which are not in cyclic chain can be ignored.
Printing dependent modules which are not in cyclic chain causes buffer
overflow as m->modnamesz is not included in buffer size calculations
(loop == m is never true). This buffer overflow causes kmod to crash.
Update depmod test to reflect the change as well.
Reported-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
The .TOC. symbol on the PowerPC64 ABIv2 identifies the GOT
pointer, similar to how other architectures use _GLOBAL_OFFSET_TABLE_.
This is not a symbol that needs relocation, and should be ignored
by depmod.
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.
