Test depmod with search dirs "foo" and "foobar". Previously to 49b33c1
("depmod: do not allow partial matches with "search" directive") we were
failing this test due to matching the prefix without checking if
it's the full dir name.
We are adding 2 tests here in order to catch the case we only pass the
test due to processing the directories in a favourable order.
In a specific configuration (chroot with the linux32 personality), the
modprobe_install_cmd_loop test failed, because the bash process handling
the install command segfaulted. The backtrace showed a uname() call
during libpthread initialization, at which point the environ pointer
hadn't been initialized yet:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x080c1591 in getenv (name=<optimized out>,
name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
81 for (i = 0, len = strlen (name); environ[i]; i++)
(gdb) bt
#0 0x080c1591 in getenv (name=<optimized out>,
name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
#1 0xf775f754 in uname (u=u@entry=0xff946350) at testsuite/uname.c:32
#2 0xf74ffc6c in is_smp_system ()
at ../nptl/sysdeps/unix/sysv/linux/i386/smp.h:39
#3 __pthread_initialize_minimal_internal () at nptl-init.c:460
#4 0xf74fe32c in _init () at ../sysdeps/i386/crti.S:74
#5 0x00000000 in ?? ()
(gdb) p environ
$1 = (char **) 0x0
I don't know why it only happend in the chroot, but glibc can call its
own functions and impose any restrictions before main() is started, so
we have to adapt.
Also, do not return error if there is an environment, but the
environment variable is not found. If uname() is called by kmod, then
the respective test will simply fail later. If it's something else
calling uname(), then we do not want to disturb the program.
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")
In kcmdline it's possible to have a dot in the param's value. The
support for this was added in 66f3228 ("libkmod: Add support for '.' in
module parameter on kcmdline") and is needed to correctly support some
modules that depend on it.
This test was added in order to make sure the commit aa87854
("libkmod-config: Only match dot before '=' in /proc/cmdline") didn't
break it. Although that commit message says it's allowing to match a
dot before '=' it's actually enforcing the first part of the string to
be always in the format "<module-name>.param". Dots after '=' are still
correctly allowed.
Strings unrelated to modules and modprobe should be ignored and not
appear in the output of "modprobe -c".
This adds a test for the fix provided in aa87854 ("libkmod-config: Only
match dot before '=' in /proc/cmdline").
We are not only checking if those options are correctly parsed from
kcmdline, but if in fact they are being passed to the final
(f)init_module call. This is why we use 'modprobe --show-depends'
instead of the simpler 'modprobe -c'.
Use "modprobe -c" to dump the configuration. Since we configure our
rootfs to have only a /proc/cmdline file, this should dump the knowledge
we have from its parsed content.
Test if <module>.option, without any value is correctly parsed, as fixed
in commit 493dc65 ("libkmod: Fix getting param with no value from kcmdline")
Add a ->modules_loaded member to struct test, which is a comma-separated
list of modules that should be present after the test finishes. Both
missing and excess modules cause an error.
Also define noreturn w/o <stdnoreturn.h> and move it to macro.h instead
of in the testsuite.
Based on similar commit on systemd by Shawn Landden
<shawn@churchofgit.com>.
stdout and stderr are names reserved for the implementation
and musl uses them rightfully as macro - and the expansion
causes (of course) unexpected results.
rename the struct members stdout to out and stderr
to err, to be 1) compliant 2) cause compilation to
succeed.
fixes build with musl libc.
- Fix infinite loop when path is relative
- Fix not considering EEXIST as a success
- General refactor to mkdir_p so it never calls mkdir for an existing
dir (given no one creates it from outside)
Instead of linking dynamically with libkmod, use libkmod-private.la. We
disallow creating a static libkmod because we can't hide symbols there
and it cause problems with external programs. However this should not
prevent users that are only interested in the tools we provide not being
able to ship only them keeping the library alone.
Other projects also do this to allow our tools to use certain functions
that should not be used outside of the project.
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
Use an if instead of a case statemente. If __NR_finit_module is not
defined in system headers we define it to -1, causing a "duplicate case
value" error. Yet, we don't want to actually call our finit_module()
function if -1 is passed.
This also fix errno being set with negative value.
When we don't have finit_module() in libc (most likely because as of
today glibc didn't add it yet), we end up using
syscall(__NR_finit_module, ...). In this case we would not wrap the
function in the testsuite and thus having some tests failing:
TESTSUITE: ERR: could not insert module: Operation not permitted
This implementation relies on the fact that this is the only caller of
syscall(2), because we can't call libc's syscall(). There's an abort()
in place to be future safe: as soon as we need more calls to syscall(),
we can detect (and decide what to do).
Now we have all tests passing in the testsuite again.
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
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.
Put this one /etc/modprobe.d/bougs.conf:
alias psmouse deaddood
`modprobe --show-depends --quiet psmouse` explodes in an assertion
(unless you have a module named deaddood). Some people and initrd's use
"alias psmouse off" to disable a module instead of blacklisting it or
adding a install rule.
Add a test with expected_fail == true before fixing this.
This gives the test cases the ability to supply files that must be
checked after the test is run, rather than just checking stdout/stderr.
This is intended to be used with tools that generate files, like depmod.
It includes a poor's man implementation of a "check for differences in
files". Not really optimized, but it's simple enough and does what it
proposes to.
Instead of replicating the same code several times, define and use macros for
the various types of wrapped functions in the testsuite's path.c LD_PRELOAD
wrapper.
Add various __xstat() variants and open64(), which are being used when enabling
large file support.
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.
We need to cope with the case in which a 32 bits machine is opening a 64
bits kernel module and vice-versa. The offset in `struct module' are
different and do not depend on the architecture we are running, but
rather on the architecture they were created for.
This fixes `make check' in 32 bits machines (since we are shipping 64
bits modules for testing)
Autofoo make the dist dir as readonly. If we copy it, tools needing to
create sysfs entries will not be able to do so, because they can't
create the needed directories/files.
It would be much better if autofoo allowed to let the files as is
instead of converting them to read-only.
This loop is similar to the one that comes with install rules of
alsa-utils package. It can be easily verified by reverting commit
abd5557 and running the testsuite.
Each test must run under 2 seconds. Ideally they should run in much less
than this; just give an arbitrary number so we don't wait forever in
case we reached an infinite loop somewhere.
