We recently disabled building kmod by default, make sure fedora-27 (and
others before fc30) integration tests still build that.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
These patches cause the following error on ppc64le on both 7.7 and 7.6:
create-diff-object: ERROR: export.o: kpatch_no_sibling_calls_ppc64le: 3290: Found an unsupported sibling call at e_show()+0x100. Add __attribute__((optimize("-fno-optimize-sibling-calls"))) to e_show() definition.
Adding -fno-optimize-sibling-calls breaks build on x86_64, so limit it
to ppc64le only.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
ccache version in epel updates from time to time so instead of
using a direct link install epel repo and install ccache without
specifying the version.
Suggested-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Skip building insn/* on x86 and gcc-plugin on Power with -Wconversion,
-Wno-sign-converion flags.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Add -Wconversion and -Wno-sign-conversion to CFLAGS. The first flag
should catch any implicit conversions like the one seen with #1065 and
the second flag suppress the warnings between signed and unsigned
integers.
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
On x86_64, GCC generates the following instruction to compute
'empty_zero_page - __START_KERNEL_map' (__phys_addr_nodebug(), used in
the implementation of ZERO_PAGE()):
48 ba 00 00 00 00 00 00 00 00 movabs $0x0,%rdx
R_X86_64_64 empty_zero_page+0x80000000
__START_KERNEL_map is 0xffffffff80000000.
However, the relocation addend becomes wrong in the patch module:
48 ba 00 00 00 00 00 00 00 00 movabs $0x0,%rdx
R_X86_64_64 empty_zero_page-0x80000000
Note the sign of the addend.
As a result, ZERO_PAGE(0) returns a wrong value in any function touched
by the patch, which may lead to memory corruption and difficult-to-debug
kernel crashes.
The cause is that 'struct rela' uses 'int' for the addend, which is not
enough to store such values. r_addend from Elf64_Rela is int64_t
(Elf64_Sxword) for that.
Let us use 'long' instead of 'int' for the addend in 'struct rela'.
v2:
* Moved 'addend' field after 'offset' in struct rela to facilitate
structure packing (suggested by Kamalesh Babulal).
Fixes https://github.com/dynup/kpatch/issues/1064.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
When patching kernel module dm-persistent-data, I found
that the KOBJFILE_NAME is incorrectly replaced to
dm_persistent-data while the module name in kernel is
dm_persistent_data.
Signed-off-by: Zhipeng Xie <xiezhipeng1@huawei.com>
The kpatch.ko support module is no longer needed by modern upstream and
recent distribution kernels, so update the patch author guide
accordingly.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
kpatch-build doesn't support GCC's sibling call optimizations in patched
functions to avoid potentially dangerous generated code. Explain the
error message that may result and link to the commit which provided
detailed explanation of why we disabled support for this in kpatch.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The kernel's definition of "inline" implies "notrace" and that may lead
to unexpected kpatch-build errors. Explain why that is and how to work
around the issue.
Fixes#983.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The current code to find the twin of a local static variable allows two
variables of the same name to be wrongly matched with the other's twin.
While there isn't a magic formula to avoid this, make stricter
requirements for twining static local from the original object with
a symbol from the patched object. This reduces the risk of erroneous
matches.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Referenced kernel documentation has moved from txt file to rst. Update
the hyperlink to point to the correct file.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Process the debug sections only after all the other inclusion logic has
finished, since it makes decisions based on what else has already been
included.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
new-function test fails on ppc64le with the following message:
create-diff-object: ERROR: n_tty.o: kpatch_no_sibling_calls_ppc64le: 3445: Found an unsupported sibling call at n_tty_write()+0x20. Add __attribute__((optimize("-fno-optimize-sibling-calls"))) to n_tty_write() definition.
Add the suggested attribute, as was done for rhel-7.[5-7] versions of
the test.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
On ppcle64, test gcc-static-local-var-4 impacts a jump label reference
which is currently unsupported.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Jump labels are unsupported, so tests modifying functions using them are
expected to fail. So disable them, for now...
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Rebase the integration test cases on top of RHEL 8.0 kernel version
4.18.0-80.el8.
Suggested-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
[JT: adapt data-new-LOADED to new meminfo format,
use common template for multiple.test]
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Disabled patches won't trigger a build, but the combined load test
will still attempt to run their associated LOADED.test script. The
combined test will fail due to voluntarily disabled tests.
Do not run tests scripts associated with disabled tests.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Simplify static local variable correlation and renaming code by using
the newly introduced helpers for section and symbol correlation.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Change 935f199875 ('create-diff-object: simplify mangled function
correlation') simplified the way symbols are correlated and got rid of
symbol section renaming.
As a result a symbol/section can now have a CHANGED status, being
correlated to an element that doesn't have the exact same name. This
will cause lookups to the original object fail when creating the new
patch object.
So lets bring back the symbol/section renaming, but only once they
have actually been correlated.
Fixes: 935f199875 ('create-diff-object: simplify mangled function
correlation')
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Elements from the original object and the patched object can be
correlated using their mangled names. In case an elements (section or
symbol) could be matched with more than one object through mangling,
make sure all elements related to a section are correlated with the
corresponding elements of the twin section.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
When freeing a kpatch_elf, another object might have symbols and
sections twined with elements that are getting freed.
Clear the twin references, so if they are used after the object they
reference is freed, the program will crash.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Kernel commit cb9b55d21fe0 modpost: add support for symbol namespaces
adds a new namespace column to Module.symvers file which can be blank.
fscanf is no longer a viable solution to parse that. Switch to the way
scripts/mod/modpost.c handles this and try to support both versions with
and without namespace column.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Currently, only rela section get freed. This seems like a simple
scope mistake.
Free all sections regardless of their nature in kpatch_elf_teardown()
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The unload_all() function in kpatch-test script is out dated and
does not unload patches loaded through livepatching.
Luckily, "kpatch unload --all" should support both kpatch unloading
kpatch patches and livepatch patches.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Some versions of Linux livepatching require patches to be unloaded
in the opposite order than the order they were loaded. Currently
kpatch simply goes through the list of sysfs livepatch directories
and tries to disable them one by one. This makes the following fail:
$ kpatch load a.ko
$ kpatch load b.ko
$ kpatch unload --all
kpatch: failed to unload module b
Since kpatch is not bound to a version of Linux, cater for those version
that do not support random unloading order, even for patches that do not
depend on one another.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
If an error occurs while loading a module or one of the tests,
multiple.test will exit leaving the working modules loaded. This leaves
the system in an unwanted state and causes the test that previously pass
to fail (succeeding before being loaded for multiple.test's point of
view).
Cleanup the loaded modules before exiting due to errors.
Also take this opportunity to factorize the test for the different
distros.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The stacktrace internal interface has been updated for v5.2. On x86,
among others, this means that stack_trace_save_tsk* is to be used
instead of instantiating a stack_trace struct. Those routines are
currently not exported for module use.
See linux kernel: <25e39e32b0a3> (livepatch: Simplify stack trace retrieval)
for more info about the stacktrace interface changes.
The kernel/livepatch subsystem is the way forward for using kpatch and
there are plans to phase out 'kmod' altogether in the near future.
It is still possible to build and use kmod by doing something like:
$ env BUILDMOD="yes" make
Closes#966
Signed-off-by: Yannick Cote <ycote@redhat.com>
The RHEL powerpc kernel is compiled with -O3, which triggers some
"interesting" new optimizations. One of them, which seems to be
relatively common, is the replacing of a function with two separate
"constprop" functions.
Previously we only ever saw a single constprop clone, so we just renamed
the patched version of the function to match the original version. Now
that we can have two such clones, that no longer makes sense.
Instead of renaming functions, just improve the correlation logic such
that they can be correlated despite having slightly different symbol
names. The first clone in the original object is correlated with the
first clone in the patched object; the second clone is correlated with
the second clone; and so on.
This assumes that the order of the symbols and sections doesn't change,
which seems to be a reasonable assumption based on past experience with
the compiler. Otherwise it will just unnecessarily mark the cloned
constprop functions as changed, which is annoying but harmless, and
noticeable by a human anyway.
Fixes#935.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
