The modinfo command can show information about builtin modules. Make
sure that it functions correctly.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/136
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
In some tests we expect zero modules to be loaded. In those cases, skip
the sorting - qsort is annotated as non-null(1,2) so we shouldn't
provide null as expected/loaded modules.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/144
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Apply same logic as in delete_module.c, i.e. pass a reference to a
pointer instead of the pointer value, otherwise we cannot update
the linked list and added entries are lost.
Spotted with ASAN while running testsuite.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/141
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Currently we check the function is resolved at link time. Although what
we really care is if the headers are silently transposing any of our stat
calls to __xstat{,64}. If so, we'd want to wrap the latter functions.
As the now-removed comment says, glibc 2.33 was the first release to no
longer have static inline wrappers that do the transposition. See the
glibc commit 8ed005daf0ab ("Remove stat wrapper functions, move them to
exported symbols") for more details.
So change the checking to check_decl/has_header_symbol and keep them for
distributions with older glibc.
NOTE: to summarise/contrast this wrt the previous open64, etc
- here: we had inline wrappers and declarations (as below)
- others: no inline wrappers and optionally declarations
glibc 2.32
extern ... __xstat(); extern inline stat(...) { return __xstat(...); }
glibc 2.33
extern stat(...);
Note we group the 64 variant as well, since the codepath has been
identical (wrt core logic) to the normal __xstat().
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Having learned from prior LFS64 experience the glibc developers have
implemented stat in (albeit varying but) neater way:
- declaration with asm linkage to __stat64_time64
- or, `#define stat __stat64_time64`
- or, `#define stat stat64; #define stat64 __stat64_time64`
In all cases __stat64_time64 lacks an explicit declaration, unlike
open64, stat64, fopen64 mentioned earlier.
Since we lack declaration, we have no other option but to check if a
program with reference to __stat64_time64 can link, so we use the
check/has function.
For more details glibc commit aa03f722f3 ("linux: Add {f}stat{at} y2038
support") added internal.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The exact struct varies across the build-options, but in practise is
never __stat64_t64 - this is the internal name used within glibc.
When the fstat declaration with __fstat64_time64 asm linkage is used, we
have "struct stat". Whenever the `#define stat __stat64_time64` kicks
in, both function and struct get redefined/renamed.
Since we don't care about it (apart from the pointer part) just use void.
For more details glibc commit aa03f722f3 ("linux: Add {f}stat{at} y2038
support") added internal.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
... and use behind the respective ifdef HAVE_FOO guards instead of the
HAVE_DECL___GLIBC__ currently.
Since day one, glibc has declarations for the functions, which was
forwarding the normal functions to them, via asm linkage, et al.
Aka `extern int open(....) asm_linkage("open64").
In addition, a lot of libraries have grown to depend on the declarations
being available and functions being statically exposed via libc.so.
Whereas musl pre 1.2.4 (circa 2023) have exposed the symbols
statically, without a declaration for well over a decade. Newer musl,
no longer expose the symbol in their runtime but have retained the
define trick, stating it will be removed in the future.
Looking at the bionic front things are somewhat similar. Newer bionic
(circa 2019) have a declaration and an inline wrapper open64 function
forwarding to open. Throughout 2019, open64 did forward to misc other
internal functions thought.
Older pre 2019 bionic had a declaration alongside plug exposing the
symbol statically in their C runtime.... since 2014. Not sure what they
did prior to 2014, it's a target out of scope for us.
Considering the above, the most robust approach is to do a check/has
function checking.
With that, we no longer need the __GLIBC__ guard for the respective
functions.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Our test does access + stat, where stat is sufficient. In addition, the
kmod codebase never used access (afaict), so we're safe to remove the
access() part.
Alongside it we can drop the LD_PRELOAD wrapper.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The majority of these were initially introduced with commit 123e827
("testsuite preload: Factorize into macros, add more stat and open
variants").
The commit itself was meant to refactor existing wrappers and add new
_xstat (aka stat) variants. The lstat variants were never used in kmod
directly nor indirectly via header macros.
The rest were added to mimic the original, without much testing it
seems.
They are all dead code - remove them.
In theory one could have a macro/helper that calls `lstat` for `stat`
itself, although that isn't a practical solution for a few reasons.
The functionality across the two varies, where if the path provided is
a symlink `stat` follows it, while `lstat` gets the details for the link
itself. To fix this, the wrapper would need second syscall to resolve
the symlink, which will cause notable performance regression wrt using
using the `stat`/`stat64` syscall alone.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/131
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
KDIR is not related to the what we configure in kmod's build. It's only
used in kmod to locate where the distro's kernel source/headers is,
which may be different from what we are configuring the (under
development) kmod with.
Remove the setting from meson/autotools and figure it out inside the
module-playground Makefile what should be used. For advanced use cases,
KDIR= can be passed to override the location.
For our own tests, which includes testing with a different module_directory,
scripts/setup-rootfs.sh will copy the module to the desired location
according to the map defined in the script.
Fixes: 27ff727326 ("testsuite: correct the default KDIR")
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/125
Currently it's only possible to test the tools by using the symlink.
However, differently from autotools, the symlink is created inside the
testsuite dir, and only if build-tests=true. Move it to the same
directory that kmod is so it's possible to test without the testsuite.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/120
We recently updated the API, but forgot to update the tests.
Fixes: 38943b2 ("shared: use size_t for strbuf")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/115
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
For some arrays, clang-format does far than ideal jobs reformatting. Do
so manually and ban clang-format from interfering.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/118
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Reformat a bunch of the args blocks and freeze them as-is. The remaining
instances clang-format handles correctly. The format is:
progname,
'--list', 'of', '--arguments',
'modname',
NULL
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/118
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The .needspawn = false is the default so just remove them. Tall the
other tests don't set it, so remove the test-util.c instances.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/118
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The last user was removed in 2013 with commit d96ca9c ("Use C11's
noreturn")
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/114
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The double ';;' were clearly a mistake and clang-format only makes it
worse if we try running it. Remove the mistake before mass-converting
the source code.
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/114
... otherwise the upcoming clang-format will try to fold them on single
line, making the end result far from ideal.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/114
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Since musl v1.2.4 and Alpine 3.18, circa May 2023, the LFS64 variants
are no longer exported by libc.so.
In addition musl headers provide relevant "#define foo64 foo" macros,
when _LARGEFILE64_SOURCE is defined and symbol resolution is deferred to
the runtime linker. See musl commit 246f1c811448 ("remove LFS64 symbol
aliases; replace with dynamic linker remapping") more details.
Earlier versions of musl had the symbols exposed by libc, although the
^^ macros were also available when _GNU_SOURCE is set, as our build
does.
Most importantly, we do not explicitly use the 64 variants and musl
doesn't implicitly pull them either. So in practise building with musl,
the binaries do not have any 64 references, thus there is no need to
wrap them.
AFAICT there is no obvious way of detecting musl, apart from the lack of
of __GLIBC__, so pull features.h (which defines it) and check on that.
There is a small chance the __GLIBC__ check will miss-fire on other
implementations like bionic, dietlibc or ulibc(-ng). We don't run the
tests on those platforms (although we could) so it should be fine.
With that we can install tar (for make distcheck) and enable the tests
in CI \o/
Closes: https://github.com/kmod-project/kmod/issues/65
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/97
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Currently the stale tracking of modules/rootfs is non-existent and I
cannot quite find a way to fix that.
In addition, there is a long standing meson bug where the tests and by
extension their dependencies are always build even when annotated as
`build_by_default : false`. To workaround that, a new option is
introduced `build-tests`, defaulting to false.
Apart from that, all tests run and pass \o/
v2:
- split from top-level meson.build to subdir one
- add to EXTRA_DIST
- scripts are in scripts/
- add option to enable building tests
- error out if building without tools
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
There will be a few more scripts incoming, so let's give them a
dedicated location.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Instead of doing the exact same search twice and using sub-shells, find
once and -exec the patterns.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
... as highlighted by shellcheck.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Honor the user-provided module directory. At the moment things work,
because distros have compatibility /lib -> /usr/lib symlink.
While in there, avoid the use of deprecated backtick (shell) notation.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The former is used by the kernel build system, while the latter is our
convenience wrapper. Split the two to indicate the distinction and make
things easier to parse.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Drop the manual (and partial) module cleanup in favour of the clean
target. Similarly - explicitly use the modules target for the build.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The idea behind the test is that modinfo should work with foreign
modules - be that CPU architecture, endianess, bit width or otherwise.
On the other hand, having binary modules baked into the repo isn't great
since they can may be outdated wrt their in-tree source code, may
trigger warnings by various tools (the Debian linter flags them as
"source-not-available") and in general it's better if they're actually
generated via the in-tree Makefile.arch file.
Remove the binaries and temporarily drop the tests. We'll add proper
cross-compilation and re-enable them at a later stage.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
All the remaining instances are used to track the tools directory (aka
the local symlinks to kmod). Rename accordingly and include the tools
sub-directory.
Similar to the OVERRIDE_LIBDIR change earlier, this is build system
specific layout, which shouldn't be in the tests.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Our expectation is that the (full) rootpath is present, otherwise we
prepend it ourselves. Drop the ABS_TOP_BUILDDIR instance.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The path is build-system specific, so set it there. Shortly we'll be
adding a meson build, where the value will be different.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
... just like the other 5 args passed to the script.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
As far as I can see, nothing ever used the variable - be that within
kmod itself, or the Kbuild itself.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The option was added for distributions/maintainers lacking the linux
headers, while running the test-suite. It also aimed to resolve
licensing and "source-not-included" issues around the cached modules.
At a glance, it seems like only Debian is using the option these days,
Arch is using "any" linux headers available, while Fedora and Gentoo do
not run `make check` all together.
Debian's linter is complaining about "source-is-missing" and
"source-contains-prebuilt-binary", where the maintainer had to disable
those.
Removing the cache will make ^^ obsolete, while also simplifying the
check target. A nice side effect is making the (compressed) release
tarball 20% smaller.
Distributions are welcome to do something like Arch or not run the
target all together.
We are already running it in CI for Arch, Debian, Fedora and Ubuntu,
where more can be added as needed.
Effectively this reverts commit 23603f1f83
Lintian overrides:
8d6fc9e90b
Arch reference:
b2d37d2bcc
The autopkgtest's copy of lsmod, ideally should use SPDX license
identifiers like we did in kmod v33.
Autopkgtest lsmod:
11793a49f6
Cc: Marco d'Itri <md@linux.it>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/86
[ Fixup flag being passed in CI ]
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
First version of the patches implementing weakdep called them "user
dep", hence the name of the test. That doesn't make sense anymore after
the rename. Rename the test accordingly.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/75
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
- Make sure that SIZE_MAX boundaries are never crossed
- Clear pointer address in struct during array_free_array
- Do nothing if array_pop is called with empty array
Also added test case for pop behavior and extended tests with
more checks.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://github.com/kmod-project/kmod/pull/68
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
... as this just does not find its paths.
Closes: https://github.com/kmod-project/kmod/issues/69
Fixes: 9d1fb31 ("libkmod, depmod, modprobe: Make directory for kernel modules configurable")
Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Typos found with codespell.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Drop the lengthy license from each file and just use SPDX like most
projects nowadays. This doesn't have any change to license, just how
they are recorded in each file.
This follows the kernel approach: header files use '/*' for comments
while .c files use '//'. For .m4, use "#".
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240723185921.1005569-2-lucas.de.marchi@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The following tests to verify weak dependencies have been implemented:
1) modprobe test to check that related weakdep modules are not loaded
due to being a weakdep.
2) depmod test to check weakdep output.
3) user test to check that configuration files with weakdep are parsed
correctly and related weakdep modules can be read correctly from user
applications.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Link: https://lore.kernel.org/r/20240530070836.9438-1-jtornosm@redhat.com
[ Minor whitespace issues and define MODULE_WEAKDEP if it's not defined
already ]
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
basename() moved to missing.h when the libc doesn't provide it, but
testsuite is not including it. Add missing include.
Fixes: 11eb9bc67c ("Use portable implementation for basename API")
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
Fix building with -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 on 32bit arch.
Closes: https://github.com/kmod-project/kmod/issues/37
Bug: https://bugs.debian.org/1065973
Co-authored-by: Jochen Sprickerhof <github@jochen.sprickerhof.de>
Signed-off-by: Shengjing Zhu <shengjing.zhu@canonical.com>
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
The kmod insert/remove tools were introduced back in 2015. Since then
they have recieved zero attention, unlike the insmod/rmmod variants.
Glancing around - neither of the following distributions (Arch, Fedora,
Gentoo, Debian) build them, so we're safe to say they have no users.
Remove them and alongside it the --enable-experimental toggle, which no
longer controls anything.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://lore.kernel.org/r/20240212-rm-experimental-v1-1-b97ab3004ae3@gmail.com
Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
