Previously, depmod would relegate failures of kmod_module_get_symbols()
to debug output, assuming the "error" was simply a lack of symbols.
Leave the ENOENT return to debug output, but report anything else as a
real error.
init_module returns -ENOENT when the module failed to load because of a
bad parameter or unknown symbol. Throw a more descriptive error message
than the generic "No such file or directory" to alert the user.
Fixes Debian bug 668216.
More or less confusing message, but if module is builtin in the live
system, it doesn't mean it's builtin in the target kernel.
Instead we now check if module has a path. It don't have a path only if
it's builtin in the target or if it doesn't exist at all. The latter
should not be a problem since this code is being called from inside the
library. Anyway, put an assert to make sure we get bug reports if any
case slipped in here.
We really haven't paid this code much attention, and it's somewhat
evident in our divergence in behavior from module-init-tools. This patch
asserts the following behavior on exit:
* modprobe -r realmod_notloaded => exit zero
* modprobe -r --first-time realmod_notloaded => exit non-zero
* modprobe -r bogusmod => exit non-zero
A simple case of breakage before this commit:
$ touch aes
$ modinfo aes
filename: /tmp/aes
ERROR: could not get modinfo from 'aes': Invalid argument
Add a new is_module_filename() function that attempts to do more than
just check if the passed argument is a regular file. We look at the name
for a '.ko' string, and if that is found, ensure it is either at the end
of the string or followed by another '.' (for .gz and .xz modules, for
instance). We don't make this second option conditional on the way the
tools are built with compression support; the file is a module file
regardless and should always be treated that way.
When doing this, and noticed in the test suite output, we open the
system modules index unconditionally, even if it is never going to be
used during the modinfo call, which is the case when passing module
filenames directly. For only one module there's not much advantage in
pre-loading the index, so just remove the call to kmod_load_resources().
With-help-from: Dave Reisner <dreisner@archlinux.org>
[lucas.demarchi@profusion.mobi: remove call to kmod_load_resources()]
Add kmod-* prefixed tool names, add 'tags' in root directory (for ctags,
matches cscope.out ignore already in there), and prefix tools/ entries
with '/' so they are absolute ignores and don't apply to subdirectories.
fopen() will not reset errno if it succeeds so we should
make sure that we only use errno in error cases.
Also fix the diagnostic messages to not use strerror
when there is no error since strerror will not return
anything useful in this case
Effectively catch and the zero and non-zero cases and error out
appropriately. Note that -EEXIST will only ever be returned when
KMOD_PROBE_STOP_ON_ALREADY_LOADED is set as a probe_insert_module flag.
Distro packagers should create them instead. It's too much trouble to
create them in the build system and every distro wants a different path
for them.
It was not on module-init-tools and it doesn't make much sense. It will
deal with dependencies, but looking at modules in the index. This might
not be the module we want if we are loading another from outside of the
tree.
Dealing with paths causes this bug (supposing there's a module names
squashfs):
# cd /
# touch squashfs
# modprobe squashfs
That is because it detects that squashfs exists as a file and it will
try to load it instead of the alias "squashfs".
If you need to load a module from a path, use insmod.
Thanks to Silvan Calarco <silvan.calarco@mambasoft.it> who reported the
bug and helped debugging it.
Index dump doesn't use stdio.h function and instead call write()
directly on STDOUT_FILENO file descriptor. Therefore we need to flush
stdio buffers before calling it, to be sure the configuration dump will
appear before index's.
Just like the module insertion, module removal is remade.
The dependencies line that comes from modules.dep already contains all
the dependencies necessary to remove that module. Therefore modprobe
doesn't have to do the recursion between the modules in order to remove
it. All we have to do is to remove in order:
For the module being removed:
----------------------------
1. softdeps (in reverse order)
2. deps (in reverse order)
3. module
4. postdeps (in reverse order)
For any of the dependencies:
----------------------------
1. softdeps (in reverse order)
2. module
3. softdeps (in reverse order)
The dependencies line that comes from modules.dep already contains all
the dependencies necessary to insert that module. Therefore modprobe
doesn't have to do the recursion between the modules in order to load a
module. All we have to do is to load in order:
For the module being loaded:
----------------------------
1. softdeps
2. deps
3. module
4. postdeps
For any of the dependencies:
----------------------------
1. softdeps
2. module
3. softdeps
Now with './tools/modprobe --show-depends ahci' (ahci is builtin) we have the following
output:
$ ./tools/modprobe --show-depends ahci
builtin ahci
Just like modprobe from m-i-t. Previously we had:
$ ./tools/modprobe --show-depends ahci
FATAL: Module ahci not found.
Deleting modules (we have found replacements) invalidates the indices
because the array collapses removed elements, hitting the assertion.
Since we don't make use of the array until the sorting step, build it from
the modules_by_name hash instead.
modprobe doesn't have support for handling dependency loop. That happens
with poorly written softdeps that can introduce a loop. We must deal
with them like it's being done in libkmod.
However, we can break a dependency loop when the dependency was already
inserted. This commit fixes this issue, that happens in the following
scenario:
dependencies:
-------------
modA:
modB: modA
modC: modA
config:
softdep modA post: modB modC
This creates the following loop:
modA
inserted ok
handle post-soft-deps of modA -> modB modC
modB
handle dependencies of modB -> modA
modA is already inserted
handle post-soft-deps of modA -> modB modC
And so on and so forth.
Now we break the loop by checking if module is already inserted, before
handling it. Thus this gives us:
modA
inserted ok
handle post-soft-deps of modA -> modB modC
modB
handle dependencies of modB -> modA
modA is already inserted
inserted ok
modC
handle dependencies of modC -> modA
modA is already inserted
inserted ok
In line with m-i-t's behavior, we should check to see if each module is:
- loaded
- has any holders
- has a 0 refcnt
Detecting any of these lets us provide a more useful message than the
kernel's EPERM response to delete_module(2).
Additionally, alter the main loop behavior to avoid exiting early on the
first error.
Symlinking tools to kmod doesn't work because argv[0] is not the name of
the symlink, but rather 'kmod' (since libtool's wrapper script calls the
tools/.libs/kmod directly)
Now we create another binary kmod-nolib that is statically linked to
libkmod so we can call the binary directly and do not worry about
LD_LIBRARY_PATH.
demarchi> scenario is the following:
demarchi> modA depends on modB and modC
demarchi> if there's a race when trying to insert a dependency of a module, say
modB, it will stop loading all the modules
demarchi> it should check by "module already loaded error"
demarchi> like it does for modA
Module aliases can be bigger than NAME_MAX. So, replace with PATH_MAX
that is bigger enough to hold them.
Technically in some places NAME_MAX would be sufficient (those using
module names only), but they use functions that can be called with
alias. So increase the buffers in these cases to PATH_MAX too.
We cannot create a kmod_module for existing module name, it will fail
due existing in the hash table "modules_by_name".
To avoid it, we first delete the existing module, if lower priority,
then add the new one.
kmod_module_new_from_path() is called only when the former module was
deleted or does not exist.
This code was never tested, my bad!
* the prefix should be ignored, as it is not stored in cfg_search/override.
* baselen should not include '/'.
* search length should not include '\0'.
* override path should not include cfg->dirname prefix.
note that the hash algorithm is different thus the output order will
be different as well.
to compare the outputs, sort the files:
depmod -n | grep '^alias symbol:' | sort > /tmp/orig
kmod-depmod -n | grep '^alias symbol:' | sort > /tmp/new
diff /tmp/orig /tmp/new
this is the initial code for depmod, it should:
* use configuration from /run/depmod.d, /etc/depmod.d, /lib/depmod.d
* respect overrides and searches
* resolve symbols and dependencies
* break circular dependencies (dependency loops)
* --errsyms: print out modules with unresolved symbols and incorrect crc
* --symbol-prefix: respect architecture symbol prefix
it will not:
* --quick: does not do quick mode
* --warn: does not warn on duplicates
* --filesyms: does not load symbols from map file
* --symvers: does not load symbol versions from map file
* dump files: does not dump any files at the moment.
it is highly untested, then I appreciate your help with real world
scenarios using overrides and searches. To get output run with -vvvvvv.
next version should fill in the gaps and at least generate the files
If using libtool 2.4.2, running the script generated by libtool will not
work because libtool changes argv[0] to lt-progname.
To test this is necessary to either fix the installed
build-aux/ltmain.sh file or run the binary directly like in:
$ export LD_LIBRARY_PATH=$PWD/libkmod/.libs/
$ ./tools/.libs/kmod help
Commit "e5e2a68 kmod_modprobe: properly handle install/remove commands"
introduced a regression that, while it worked for install/remove
commands, it ceased to work for normal module names. Move the check for
whether it's a install command or a module so both cases work.
Handle install/remove commands just like modprobe does. Test configure
file:
install installme echo "this is a install message"
remove removeme echo "this is a remove message"
Tests:
$ ./tools/kmod-modprobe installme
this is a install message
$ ./tools/kmod-modprobe -r removeme
this is a remove message
$ ./tools/kmod-modprobe removeme
FATAL: Module removeme not found.
./tools/kmod-modprobe -r installme
FATAL: Module installme not found.
The check for remove/install commands must be before the ignore_loaded
check because we will actually run something instead of
removing/inserting a module and the modname might not correspond to a
real module. Otherwise a fake module like "remove removeme echo 'bla'"
would not work.
This also keeps compatibility with modprobe.
Implement soft dependencies in a way similar to module-init-tools
modprobe. Unlike regular dependencies they are allowed to fail
inserting or removing.
The rmmod version walks the lists in reverse order, also doing post
before and pre later.
try to mimic original module-init-tools' modprobe as much as possible,
but this exposed some missing features in libkmod, these are now
listed in TODO.
Lucas De Marchi
Lucas De Marchi
Dave Reisner
Elan Ruusamäe
Dan McGee
Khem Raj
Thierry Vignaud
Jan Alexander Steffens (heftig)
Gustavo Sverzut Barbieri
Rolf Eike Beer
Dave Reisner
Leandro Pereira
Kay Sievers