Move underscores() to shared/. It's the same as alias_normalize(), but
it rather operates in place, with the same string being passed.
The difference now that it's in shared/ is that it's a non-logging
function.
This makes us a little bit more verbose: we don't accept partially
correct module and aliases names in kcmdline and in configuration files.
We log an error instead.
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.
Older systems may not have the be32toh function defined. Check for this
and fall back to checking the endianness and calling bswap_32 directly
if needed. This works on both old and new systems.
[Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>:
address comments raised by Lucas De Marchi [1], update commit message]
[1] http://www.spinics.net/lists/linux-modules/msg01129.html
Add assert_return to use in testcases instead of assert. The issues
with assert are:
1) It's disabled when NDEBUG is defined
2) Even if it's well supported by testsuite (the parent will
report the child died) it can't output any meaningful
error message
If a test has expected_fail=true, it means the return code must be
different from 0 *and* the outputs must match. This way it's possible to
check if the error messages are printed as they should.
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).
If a value is added to the hash under a key that already exists the new value
replaces the old value for that key. Since key can be a pointer to data that
is part of value and freed by hash->free_value(), the key must be also
replaced and not only the value. Otherwise key potentially points to freed data.
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.
