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.
Check for finit_module() and don't use our own static inline function if
there's such function in libc (or another lib).
In testsuite we need to unconditionally define HAVE_FINIT_MODULE because
we want to override this function, and never use the static inline one
in missing.h
Depending on kernel header and simply not passing the flags in
finit_module() if this header is not found is not good.
Add a missing.h header in which stuff like this should be added.
"The secure_getenv() function is intended for use in general-purpose
libraries to avoid vulnerabilities that could occur if set-user-ID or
set-group-ID programs accidentally trusted the environment."
Fix compilation issue with musl-libc:
CC libkmod/libkmod-list.lo
In file included from libkmod/libkmod-private.h:183:0,
from libkmod/libkmod-list.c:24:
libkmod/libkmod-util.h:33:45: warning: 'struct stat' declared inside parameter list [enabled by default]
libkmod/libkmod-util.h:33:45: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
When a module is being loaded directly from disk (no compression, etc),
pass the file descriptor to the new finit_module() syscall. If the
finit_module syscall is exported by the kernel syscall headers, use it.
Additionally, if the kernel's module.h file is available, map kmod flags
to finit_module flags.
If the module is built with CONFIG_MODULE_SIG, add the the signer's
name, hexadecimal key id and hash algorithm to the list returned in
kmod_module_get_info(). The modinfo output then looks like this:
filename: /home/mmarek/kmod/testsuite/rootfs-pristine/test-modinfo/ext4-x86_64-sha256.ko
license: GPL
description: Fourth Extended Filesystem
author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
alias: ext3
alias: ext2
depends: mbcache,jbd2
intree: Y
vermagic: 3.7.0 SMP mod_unload
signer: Magrathea: Glacier signing key
sig_key: E3:C8:FC:A7:3F:B3:1D:DE:84:81:EF:38:E3:4C:DE:4B:0C:FD:1B:F9
sig_hashalgo: sha256
The signature algorithm (RSA) and key identifier type (X509) are not
displayed, because they are constant information for every signed
module. But it would be trivial to add this. Note: No attempt is made at
verifying the signature, I don't think that modinfo is the right tool
for this.
When told to force load a module, we were removing only the value of
vermagic instead of the complete entry.
Philippe De Swert (philippe.deswert@jollamobile.com) sent a patch that
was additionally mangling also the last two chars of the key
("vermagic="). Instead of creating an invalid entry in .modinfo section
like this, this patch removes the complete entry, key + value, by
zeroing the entire string.
Much thanks to Philippe who found the issue and pointed to the fix.
If we are accessing several times the modules and reading some sections
by sucessive calls to the functions below, we are incurring in a penalty
of having to open, parse the header and close the file. For each
function.
- kmod_module_get_info()
- kmod_module_get_versions()
- kmod_module_get_symbols()
- kmod_module_get_dependency_symbols()
These functions are particularly important to depmod. It calls all of
them, for each module. Moreover there's a huge bottleneck in the open
operation if we are using compression. Every time we open the module we
need to uncompress the file and after getting the information we need we
discard the result. This is clearly shown by profiling depmod with perf
(record + report), using compressed modules:
64.07% depmod libz.so.1.2.7 [.] 0x00000000000074b8 ◆
18.18% depmod libz.so.1.2.7 [.] crc32 ▒
2.42% depmod libz.so.1.2.7 [.] inflate ▒
1.17% depmod libc-2.16.so [.] __memcpy_ssse3_back ▒
0.96% depmod [kernel.kallsyms] [k] copy_user_generic_string ▒
0.89% depmod libc-2.16.so [.] __strcmp_sse42 ▒
0.82% depmod [kernel.kallsyms] [k] hrtimer_interrupt ▒
0.77% depmod libc-2.16.so [.] _int_malloc ▒
0.44% depmod kmod-nolib [.] kmod_elf_get_strings ▒
0.41% depmod kmod-nolib [.] kmod_elf_get_dependency_symbols ▒
0.37% depmod kmod-nolib [.] kmod_elf_get_section ▒
0.36% depmod kmod-nolib [.] kmod_elf_get_symbols
...
Average of running depmod 5 times, dropping caches between them, in a
slow spinning disk:
Before: 12.25 +- 0.20
After: 8.20 +- 0.21
m-i-t: 9.62 +- 0.27
So this patch leads to an improvement of ~33% over unpatched version,
ending up with 15% speedup over module-init-tools.
Although the hash table implementation allows passing a callback function
to free a value when it is removed from the hash table, hash_del() wasn't
freeing it if it was provided. Now it does.
As a bonus, it now checks if the callback is set in hash_add() as well.
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.
With this flag kmod_module_probe_insert_module() check if module is
blacklisted only if it's also an alias. This is needed in order to allow
blacklisting a module by name and effectively blacklisting all its
aliases as module-init-tools was doing.
Before this patch we could load pcspkr module as follows:
/etc/modprobe.d/test.conf:
alias yay pcspkr
blacklist pcspkr
$ modprobe yay
Now libkmod has support to blacklist "yay" because "pcspkr" is blacklisted.
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.
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>
