The printks in the integration tests aren't very useful and annoyingly
fill up the dmesg buffer. Remove them by making them contingent on
unlikely conditions.
The current approach of trying to include the tracepoint-related
sections doesn't work at all. The new tracepoints don't show up in
"perf list".
And also, with one patch (issue #219) I've seen a panic in
jump_label_del_module(). I suspect it's because the kernel is confused
by dynamic relocations' changing of the jump table after it was
registered with the jump table code.
I think the best approach for now is to just always exclude these
sections. It should be harmless, with the only consequence being that
tracepoints and jump labels can't be enabled in patched functions (which
is already the case with the current code anyway).
Fixes#221.
Combine all the patch modules into a single kpatch-COMBINED.ko for a
much quicker test which still gives 95% or so of the coverage compared
to the full test suite. Use "make quick" for use this new option.
One of the tests is now failing:
ERROR: smp-locks-section: kpatch replace failed
I suspect the issue is the vmlinux mismatch problem. Fix for that
coming soon.
No need to accumulate errors if the load or unload fails. Leaving the
testprog failure non-fatal so that the test will then call unload to
clean up after itself.
This is a basic integration test framework for kpatch, which tests
building, loading, and unloading patches, as well as any other related
custom tests.
The kpatch-test script looks for test input files in the
tests/integration directory. It expects certain file naming
conventions:
- foo.patch - patch that should build successfully
- bar-FAIL.patch - patch that should fail to build
- foo-LOADED.test - executable which tests whether the foo.patch module
is loaded. It will be used to test that loading/unloading the patch
module works as expected.
Any other *.test files will be executed after all the patch modules have
been built from the *.patch files. They can be used for more custom
tests above and beyond the simple loading and unloading tests.
I just have one test here, but many more to come eventually. I'm
constantly doing manual testing of patches and am planning on automating
them with this framework.
