It makes more sense to have libkmod-config.c deal with the configuration
directly and the others get the config from ctx. As a bonus point we get
a smaller binary. Following numbers are for x86-64, libkmod + kmod:
Before:
text data bss dec hex filename
128840 1496 104 130440 1fd88 tools/modprobe
After:
text data bss dec hex filename
128392 1496 104 129992 1fbc8 tools/modprobe
I hate this kind of READV and WRITEV macros that Gustavo seems to love.
clang-analyzer hates them as well.
I'm not motivated enough to refactor this, but I want a clean clang
report, so just shut it up.
If we don't have --gc-sections support, linking kmod fails:
libkmod/.libs/libkmod-util.a(libkmod-util.o): In function 'underscores':
libkmod/libkmod-util.c:117: undefined reference to 'kmod_log'
This is because libkmod-util.la uses kmod_log(), that is in libkmod.la.
Move the function so we don't have a dependency loop while building the
libraries and it works with compilers with no support for --gc-sections.
There's no reason kmod_log should be exported, remove it from linker
script. This doesn't break the API/ABI because we are luck: since the
function had visibility=hidden it was not getting exported as a global
symbol.
This reverts commit 88a170dbd6.
There's no reason for users of the API to call this method, it's just
wrong to export it.
The bug that this patch fixed needs to be fixed another way, not
exporting this function.
zlib won't necessarily set the system errno, and this is particularly
evident on corrupted data (which results in a double free). Use zlib's
gzerror to detect the failure, returning a generic EINVAL when zlib
doesn't provide us with an errno.
If we don't have --gc-sections support, linking kmod fails:
libkmod/.libs/libkmod-util.a(libkmod-util.o): In function 'underscores':
libkmod/libkmod-util.c:117: undefined reference to 'kmod_log'
This is because kmod_log is missing the export define, even though it's
already listed in the exported symbol list.
This matches the change in systemd and udev. Log message on udev's
change by Kay Sievers:
After long consideration we came to the conclusion that user
configuration in /etc should always override the (generally
computer generated) configuration in /run. User configuration
should always be what matters over anything else. Hence rearrange
the search orders accordingly. In general this should change
very little as overriding like this is seldomn done so far,
and the order between /etc and /usr stays the same.
If kernel doesn't have support to unload modules,
/sys/module/<modname>/refcnt will not exist and that's ok.
Reported by: Sven Anders <anders@anduras.de>
This is a more generic method of applying filters to module lists. This
deprecates kmod_module_get_filtered_blacklist() which now simply returns
a call to _apply_filter with the extra filter enum arg.
Running two instances of modprobe with the same module should both
succeed or both fail:
modprobe foo&; modprobe foo;
Previously if foo failed to be inserted by the first call, the second one
could return 0 because it may have occurred while the first one was being
processed by kernel (thus marked as "coming").
Now we simply don't check by "coming" in order to decide if we need to
call init_module(). module-init-tools used to spin calling
usleep(100000), but calls to init_module() are already synchronous.
Therefore let kernel synchronize the calls.
Search modules.builtin file before saying the module was not found.
Note: these "modules" should not appear as dependencies of other modules
(in modules.dep) even if they appear in modinfo. This fixes the return
code of modprobe with builtin modules.
Also fixes a small coding style issue in module_is_inkernel().
If a softdep depends on a module in the dependency list of the module
being inserted, we would enter and infinite loop.
Move the "mod->visited = true" assignment to the proper place, hoping it
didn't break other use cases. This is a bug that comes and goes every
now and then. Since we have a testsuite now, a test for this should be
written.
Commit "af9572c lib/module: check initstate before inserting module"
removed the check for "we should return -EEXIST" and moved it back to
the start of the function. The problem with this is the following
scenario:
- We check if module is in kernel -> no
- We insert the dependencies
<-- External program loads
the module
- We check if module is in kernel -> yes
- We return 0, when we should return -EEXIST
Use a function to properly get an unsigned short from memory that is
possibly unaligned.
Note that it implicitly fixes a small bug in the hash function that
was introduced when modifying the eina code: the line "hash ^= key[2]
<< 18;" is supposed to be accessing the 3rd byte of the remainder of
the input, but when 'it' was introduced, 'key' ('data' in eina code)
was no longer incremented, so this ended up accessing the 3rd byte of
the input from the beginning. This is fixed by iterating over 'key',
like the eina code does.
Before this patch depmod was failing on ARMv5 and possibly others that
don't have unaligned access. They do not calculate correctly the
dependencies as shown below:
[root@alarm ~]# modinfo bridge
filename: /lib/modules/2.6.39.4/kernel/net/bridge/bridge.ko
version: 2.3
license: GPL
srcversion: 6B583530AE2B39C7E2317BF
depends: stp,llc
vermagic: 2.6.39.4 preempt mod_unload ARMv5
[root@alarm ~]# depmod
[root@alarm ~]# cat /lib/modules/2.6.39.4/modules.dep |grep bridge
kernel/net/bridge/bridge.ko:
[root@alarm ~]#
See how modinfo properly lists the dependencies, but modules.dep which
depmod generates does not contain them. As a result, most kernel
modules fail to load because their dependencies are not loaded by
modprobe.
This applies to both the high level probe_insert_module() and the
underlying insert_module() functions. By checking module initstate prior
to inserting a module, we can avoid a lot of needless work just to find
out that the init_module call fails with EEXIST.
This implements a helper function, module_is_inkernel, to return a
boolean value describing if a module is live, coming, or builtin.
Just printing the errno string such as "%m\n" is not enough to help
debug or users understand the problem.
Change to provide more context on the failing operation.
Some messages may happen more than once in the same function and
discovering the line is hard. Now we print the actual log priority
that exposed the message as well as filename and line.
NOTE: We should consider printing the log priority in the non-debug
version as well.
We need a way to tell libkmod to ignore loaded modules, so modprobe can
tell it to dry-run and show dependencies. However there's a conflict
with two flags. KMOD_PROBE_STOP_ON_ALREADY_LOADED prevails if passed
together with KMOD_PROBE_IGNORE_LOADED.
