Like unsupported jump labels and static call sites, batch report all
unsupported sibling calls so the kpatch developer doesn't need to
iteratively find them all.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Kernel v6.2+ commits 00abd3840812 ("objtool: Add .call_sites section")
and e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking") added .call_sites sections to object files. These are filled
with an array of s32 values.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Kernel v6.1+ commit 2df8220cc511 ("kbuild: build init/built-in.a just
once") split init_uts_ns and linux_banner out to
init/version-timestamp.c from init/version.c
Add init/version-timestamp.o to the list of object files that kpatch-cc
won't add to its changed_objs list.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Architectures like ppc64le may set CONFIG_PARAVIRT=y but do not
necessarily implement via struct paravirt_patch_site.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The term "dynrela" was invented before klp relocations ever existed.
They're basically the same thing: special livepatch-specific relocations
which get applied when the patched object gets loaded or patched.
They're necessary due to a) the need to access unexported symbols; and
b) late module patching.
The different names are confusing. Consolidate them by replacing
"dynrela" with "klp_reloc" (code) or "klp relocation" (English).
Note there's still some antiquated code in the kpatch core module and in
the pre-4.7 klp patch template which still use the "dynrela" naming.
That code is mostly dead anyway so I've just left it alone.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
For some reason the github version of 'make check' just started
complaining about these:
shellcheck kpatch/kpatch kpatch-build/kpatch-build kpatch-build/kpatch-cc
In kpatch-build/kpatch-build line 455:
while [[ "${filedir#$common/}" = "$filedir" ]]; do
^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
while [[ "${filedir#"$common"/}" = "$filedir" ]]; do
In kpatch-build/kpatch-build line 460:
result="${result}${filedir#$common/}"
^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
result="${result}${filedir#"$common"/}"
In kpatch-build/kpatch-cc line 26:
relobj=${obj##$KPATCH_GCC_SRCDIR/}
^----------------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
relobj=${obj##"$KPATCH_GCC_SRCDIR"/}
For more information:
https://www.shellcheck.net/wiki/SC2295 -- Expansions inside ${..} need to b...
make: *** [Makefile:70: check] Error 1
Error: Process completed with exit code 2.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Otherwise on recent distros it appends the errno to the error message,
like:
create-diff-object: ERROR: x86.o: kpatch_regenerate_special_section: 2633: Found 1 unsupported static call(s) in the patched code. Use KPATCH_STATIC_CALL() instead.: Success
which is not what we want in most cases.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Similar to jump labels, static calls aren't supported when the static
call key was originally defined in a module rather than in vmlinux.
Detect those cases and either remove them (in the case of tracepoints)
or error out.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Convert the hard-coded should_keep_jump_label() to a proper callback,
since static calls will need a similar filter.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Align the s390 special_section initializers to improve readability and
for consistency with the rest.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
kpatch_mangled_strcmp() only ignores the digits after the period, but in
the case of __UNIQUE_ID(), the symbol names have random digits before
the period due to the use of `__COUNTER__`. Make sure such symbols are
properly correlated.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Rewrite kobj_find() to deal with Linux 5.19, where the .cmd files use
object file paths relative to the .cmd file rather than relative to the
root of the kernel tree.
While at it, add several performance enhancements to prevent all
currently known deep finds.
This is all quite fiddly. But it works.
Fixes#1277.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
When patching an OOT module, the parent object is always the OOT module.
Hard-code that to prevent the need for any further special casing in
find_kobj() (e.g., commit 9143e88f16 ("kpatch-build: fix
find_parent_obj")).
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Fix build error seen on gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1):
g++ -MMD -MP -I../kmod/patch -Iinsn -Wall -Wsign-compare -Wno-sign-conversion -g -Werror -shared -I/usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include -Igcc-plugins -fPIC -fno-rtti -O2 -Wall gcc-plugins/ppc64le-plugin.c -o gcc-plugins/ppc64le-plugin.so
In file included from /usr/include/features.h:490,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from /usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include/system.h:46,
from /usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include/gcc-plugin.h:28,
from gcc-plugins/gcc-common.h:6,
from gcc-plugins/ppc64le-plugin.c:1:
/usr/include/bits/error-ldbl.h:23:1: error: type of ‘error’ is unknown
23 | __LDBL_REDIR_DECL (error)
| ^~~~~~~~~~~~~~~~~
/usr/include/bits/error-ldbl.h:23:1: error: ‘int error’ redeclared as different kind of entity
23 | __LDBL_REDIR_DECL (error)
| ^~~~~~~~~~~~~~~~~
In file included from gcc-plugins/ppc64le-plugin.c:2:
/usr/include/error.h:31:13: note: previous declaration ‘void error(int, int, const char*, ...)’
31 | extern void error (int __status, int __errnum, const char *__format, ...)
| ^~~~~
make[1]: *** [Makefile:39: gcc-plugins/ppc64le-plugin.so] Error 1
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Clang FDO adds a new, ignorable ELF section, .llvm.call-graph-profile
Generalize to ignore all .llvm.*
Signed-off-by: Pete Swain <swine@google.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> [subject line]
While gcc puts strings in .strtab and .shstrtab sections,
llvm toolchain just uses .strtab.
Adapt kpatch to handle both styles.
Signed-off-by: Pete Swain <swine@google.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> [small changes]
If two sections want to be the same, they need to satisfy
two conditions:
1) the result of memcmp is zero, which means they
have the same content.
2) they have the same relocation entries.
In one specific situation, two sections have the same content.
But one section has relocation entries while the other one has
no relocation entries. For example, in X86, consider the
following code:
original code
```
__noreturn noinline int kpatch_func(void)
{
while(1) {};
}
```
patched code
```
__noreturn notrace noinline int kpatch_func(void)
{
asm(".byte 0xe8, 0x00, 0x00, 0x00, 0x00");
while(1){};
}
```
Since the original code has a fentry call, these two functions have
the same compile result. But obviously, they are different functions.
Currently, kpatch would not find their differences since the patched
code has no relocation entries.
For the situation that one section has relocation entries while the
other one doesn't have, it should be set to be changed directly.
Cooperated-by: Zongwu Li <lizongwu@huawei.com>
Signed-off-by: Longjun Luo <luolongjuna@gmail.com>
After patched, rela information for some sections could
disappear. For example, a function like the following:
"
notrace noinline static int version_proc_show(struct seq_file *m,
void *v)
{
return 0;
}
"
Apart from common rela entries, trace and return thunk mechanism
will generate rela information. Use `notrace` to remove the
effect of trace. Make CONFIG_RETHUNK=n can remove the effect of
return thunk.
Discovered-by: Zongwu Li <lizongwu@huawei.com>
Signed-off-by: Longjun Luo <luolongjuna@gmail.com>
For consistency with what the kernel does (and what we already do for
in-tree modules), if the file has any dashes ('-'), replace them with
underscores in the objname (aka KBUILD_MODNAME).
Fixes#1286.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
To support building out-of-tree kernel modules, the source tree prefix
is attempted to be stripped from change object file paths to make them
relative. However, if the path is already relative, the change can
strip a substring instead, resulting in build errors.
Ensure just the prefix is stripped instead of any substring.
Fixes: #1282
Fixes: 51a8fad34f ("Add support for building out-of-tree modules")
Recent toolchains only create a section symbol if it's needed, i.e. if
there's a reference to it. If there's a missing section symbol in
kpatch_create_intermediate_sections(), create one instead of erroring
out.
Fixes#1272.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
* Add s390 specific checks
* Identify patchable functions.
* Dont mark expolines as dynrelas. These expolines are always included
in final kernel module. This ensures that expoline functions and the
kernel itself are not too far apart and avoids out of range
relocation. However, this isnt a problem for other functions, as these
relocations are performed via R_390_PLT32DBL using gcc option
-mno-pic-data-is-text-relative.
* s390 maintains expoline tables to locate the expoline thunks. If
needed, the module loader could later replace these expoline thunks
with normal indirect branch. Each element in the expoline table is of 4
bytes. If there is a changed function in rela.s390_return*, then mark
that specific rela symbol as included. This is already performed in the
processing of special sections. Hence include it.
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
1. -mno-pic-data-is-text-relative prevents relative addressing between
code and data. This is needed to avoid relocation error when klp text
and data are too far apart
2. Avoid generation of LANCHOR symbols through -fno-section-anchors.
kpatch-build does not handle it well.
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
symtab_read tries to skip '.dynsym' symbol table and only
read '.symtab' symbol table. Newer readelf from binutils 2.37
now adds section names (see the diff):
--- vmlinux.symtab 2022-02-18 02:10:06.691220932 +0100
+++ vmlinux.symtab.new 2022-02-18 01:16:06.161210458 +0100
Symbol table '.dynsym' contains 1541 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000100000 0 SECTION LOCAL DEFAULT 1 .text
2: 00000000017a3ac0 4 OBJECT GLOBAL DEFAULT 19 sclp_console_pages
Symbol table '.symtab' contains 159980 entries:
Num: Value Size Type Bind Vis Ndx Name
- 41: 0000000001a93600 0 SECTION LOCAL DEFAULT 41
- 42: 0000000001a9c678 0 SECTION LOCAL DEFAULT 42
...
+ 41: 0000000001a93600 0 SECTION LOCAL DEFAULT 41 .dynsym
+ 42: 0000000001a9c678 0 SECTION LOCAL DEFAULT 42 .rela.dyn
...
54: 0000000000000000 0 FILE LOCAL DEFAULT ABS main.c
Simple matching of ".dynsym" in the line buffer is not enough anymore,
because it hits not just
Symbol table '.dynsym' contains 1541 entries:
line, but also
41: 0000000001a93600 0 SECTION LOCAL DEFAULT 41 .dynsym
skipping the rest of the file and leading to an error:
create-diff-object: ERROR: *.o: find_local_syms: 189: couldn't find matching
*.c local symbols in vmlinux symbol table
Limit matching only to lines containing "Symbol table" header.
This works with readelf from the binutils, as well as readelf from
elfutils (its output looks slightly different).
Symbol table [41] '.dynsym' contains 1541 entries:
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
If a section reference can't be converted to a symbol reference, error
out to try to prevent unexpected behavior later on.
There are a few sections for which a symbol is optional: .rodata and
string literal sections. Don't warn about those.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
rela_insn() only cares about the base section. Convert it to take a
non-rela section as its argument instead of a relasec.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Add support for R_X86_64_NONE. With an upstream kernel, it's quite
rare, only used for a few jump labels. With older kernels it was used
for fentry hooks. Either way, it should be treated like a PC-relative
relocation.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
It doesn't make sense to disassemble a data section. That just happened
to work by accident. PC-relative offsets only need adjusting when
associated with an instruction.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Several functions have a boolean semantic, but don't actually return
bool, which is confusing. Fix that.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Several functions expect to take a ".rela" section as an argument. Make
such cases more clear by renaming "sec" -> "relasec".
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
With '--debug', most of the xtrace output shows the reading of the
.config and Module.symvers files, which isn't very useful and floods the
rest of the xtrace output. Temporarily disable xtrace before reading
the files.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
As I noticed, commit eaaced191 has added
partial support for openEuler.
This patch enables usage in openEuler like:
kpatch-build xxxx.patch
I test it in openEuler 21.09, for people who
want to use kpatch in openEuler, two more steps
are needed.
1) add repo source
source rpm package of openEuler kernel are put in
two places. One is
https://repo.openeuler.org/openEuler-21.09/source/
Another one is
https://repo.openeuler.org/openEuler-21.09/update/source/
The latter one is not inclued in rpm repo lists by default.
2) compile kernel with CONFIG_LIVEPATCH_PER_TASK_CONSISTENCY enabled
openEuler has its own strategy when trying to apply patches.
We can use the klp_enable_patch function only when
CONFIG_LIVEPATCH_PER_TASK_CONSISTENCY is enabled.
Signed-off-by: anatasluo <luolongjuna@gmail.com>
The two versions are not the same (4.18.0-240.el8 vs. 4.18.0-284.el8).
But I am not quite sure which one is accurate. Remove the first one as the
second one is being used before this change.
Signed-off-by: Song Liu <song@kernel.org>
Debug sections are intended to refer to the patch module only. And in
fact, any debug section references to non-included symbols are stripped
in kpatch_include_debug_sections(). So there's no need for
need_dynrela() to even think about it.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
A seg fault was reported:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f18c8e in __strcmp_avx2 () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install elfutils-libelf-0.186-1.fc34.x86_64 zlib-1.2.11-26.fc34.x86_64
(gdb) bt
#0 0x00007ffff7f18c8e in __strcmp_avx2 () from /lib64/libc.so.6
#1 0x000000000040a0f7 in kpatch_is_core_module_symbol (name=0x0) at create-diff-object.c:3060
#2 0x000000000040a267 in need_dynrela (kelf=0x4669a0, table=0x92af30, sec=0x6d6b20, rela=0x8c7fd0) at create-diff-object.c:3117
#3 0x000000000040a4cc in kpatch_create_intermediate_sections (kelf=0x4669a0, table=0x92af30, objname=0x7fffffffcfc6 "vmlinux", pmod_name=0x7fffffffd020 "livepatch_a") at create-diff-object.c:3281
#4 0x000000000040c7c5 in main (argc=8, argv=0x7fffffffca48) at create-diff-object.c:3931
It happened because 'rela->sym->name' was NULL, and
kpatch_is_core_module_symbol() tried to dereference it.
Here's the corresponding relocation:
Relocation section [455] '.rela.debug_loclists' for section [454] '.debug_loclists' at offset 0xd0478 contains 2432 entries:
Offset Type Value Addend Name
...
0x000000000000aad6 X86_64_64 000000000000000000 +32 .LC55
...
That '.LC55' symbol lives in the following section:
[104] .rodata.btf_show_end_aggr_type.str1.8 PROGBITS 0000000000000000 00003ef0 00000021 1 AMS 0 0 8
The problem is that the symbol wasn't included in the output file
(though its corresponding section was). So it got zeroed by
kpatch_elf_teardown(), which was designed to trigger seg faults to help
find bugs like this.
The string literal sections which hold the '.LCx' string symbols are
already being included. Include their symbols as well.
Fixes#1257.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
The __LINE__ detection code looks for "printk", which on newer kernels
has been renamed to "_printk". Fix the check for newer kernels.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
For x86, we already check arg2 and arg3 for `__LINE__` immediate load
detection. For parity, do the same thing for the other two arches.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Previously, the name length was limited to 48 chars. This was then
prepended with "kpatch-" and a trailing NUL terminator to get to the 56
char limit for kernel module names. After some code rearrangement, the
48 char restriction was applied to the name after being prefixed with
kpatch-/livepatch-, limiting the length more than necessary. Increase
the name length limit back to 55 chars to restore the original limit.
Fixes: c0105ea467 ("kpatch-build: set default module prefix accordingly")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Technically we don't support s390 yet, but it's coming soon and there's
no harm in merging this one early. In fact this came in handy for
testing my endian fixes with #1203.
Note it doesn't actually do anything since 'kelf->arch' can't actually
get set to 'S390' yet. But it should work nicely with #1203 as it
evolves.
This is based on the patch from C. Erastus Toe in #1243, though there
may still be a few outstanding issues to look at in that PR, based on
some of the code review comments.
Originally-by: C. Erastus Toe <ctoe@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
With s390 support coming, we'll soon have to worry about endianness
issues when doing cross-compiles and cross-arch unit tests. Make
insn_is_load_immediate() endian-agnostic.
Suggested-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Using -a/--archversion to explicitly set target kernel version was not
allowed if the kernel source directory and/or path to vmlinux with debug
info were set. This seems too strict, however.
vmlinux with debug info is used during the build to get symbol data, the
size of special structures, GCC version used to build the kernel, and the
target kernel version. As it turned out, some kernels, e.g. the ones from
OpenSUSE and derivatives, contain all that data except the Linux version
string in the file with debug info for vmlinux. Instead, that string is
present in vmlinux itself but that file does not contain debug info.
A simple workaround is to allow specifying the target kernel version
explicitly using -a/--archversion even if --sourcedir and/or --vmlinux are
set. If vmlinux with debug info does contain the Linux version string and
the version is different, kpatch-build will report an error.
Signed-off-by: Evgenii Shatokhin <evgenii.shatokhin@openvz.org>
For ppc64le, if a rela goes through the .toc, it requires an extra level
of indirection. Use toc_rela() here to ensure it gets the rela we care
about. This will be needed for the upcoming patch which checks for
`__func__`.
For non-ppc64le arches, and for ppc64le relas which don't go through the
.toc, toc_rela() is a no-op which just returns the rela. So this is
harmless for non-.toc cases.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
The arch-specific versions of kpatch_line_macro_change_only() are mostly
duplicate code. Unify them into a single implementation.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
If the only reference to the `__dyndbg` section is through a jump table
entry, the section doesn't get included and the jump table relocations
end up with a dangling reference to an UNDEF section symbol.
Make sure jump table referenced dynamic debug symbols get their sections
included.
Fixes#1253.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Symbol indexes over 64k don't fit into st_shndx and are stored in
extended symbol table. Make sure we properly handle these cases. It is
not normally useful during kpatch builds but will come up if we start
diffing linked objects.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
libelf can read and write various architecture ELF files that may
differ from the host system. Instead of using preprocessor directives
to build architecture-specific code as per the current host, detect the
intended target architecture from the input ELF files.
Based-on: https://github.com/dynup/kpatch/pull/1179
Signed-off-by: Bill Wendling <morbo@google.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> [small tweaks]
The last part of kpatch_elf_open() calls kpatch_find_func_profiling_calls() to
find and set sym->has_func_profiling. However, only create-diff-object.c
requires sym->has_func_profiling, so remove the call from
kpatch_elf_open() and let the lone user, create-diff-object, provide and
call it as needed.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Ignore distro-specific checks if kernel source directory is supplied as a
command line argument to remove the distro-specific tunings during
cross-compilation.
Signed-off-by: Ruslan Bilovol <rbilovol@cisco.com>
Signed-off-by: Oleh Matiusha <oleh.matiusha@globallogic.com>
Introduce the ability to pick a CROSS_COMPILE environment variable for
specifying toolchain prefix for all gcc and binutils. To facilitate its
use, do not set the DISTRO variable when USERSRCDIR is specified.
Signed-off-by: Ruslan Bilovol <rbilovol@cisco.com>
Signed-off-by: Oleh Matiusha <oleh.matiusha@globallogic.com>
Commit 134ab5bd1883 ("objtool,x86: Replace alternatives with .retpoline_sites")
in the kernel starts keeping track of retpoline thunk call sites in a
dedicated section rather than via the alternatives mechanism.
The .retpoline_sites section needs to have its entries and relocations
for changed symbols included in the patch ELF when building for kernel
5.16+ with CONFIG_RETPOLINE=y.
Signed-off-by: Markus Boehme <markubo@amazon.com>
In kpatch-build, there are a number of places where a dynamic allocation
is performed, but the allocation is not checked for a failure. The
common pattern in kpatch-build is to check whether the returned pointer
is NULL, and if so, invoke the ERROR() macro to print a message and
abort the program.
kpatch_create_mcount_sections(), CORRELATE_ELEMENT(), and
create_klp_arch_sections() all had dynamic allocations without failure
checks. This diff adjusts those callsites to properly check for a failed
allocation, and ERROR() accordingly.
Signed-off-by: David Vernet <void@manifault.com>
find_special_section_data() and find_special_section_data_ppc64le() are
almost identical. Refactor the code so that a single function serves
both (and future) architectures without all the code duplication.
The inline awk script algorithm remains the same, only flip the "skip_x"
logic to "check_x" logic for readability.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Rather than individually (re)grepping the kernel configuration for
CONFIG_ options, source the entire file to import all the settings in
one shot.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
KPATCH_BUILD is used in kpatch-module build to specify the kernel
directory and thus needs to be set to KERNEL_SRCDIR, not BUILDDIR.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
kpatch-build currently initializes KBUILD_EXTRA_SYMBOLS to "", denying
users ability to set it themselves.
Fixes: #1238
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Previously OOT-module builds used `--sourcedir` to specify oot-module
source directory which was a bit confusing and also denied users ability
to build kpatches agains oot modules built against non-distro kernels.
This patch adds `-p/--oot-module-src` option to specify source dir for
oot module while keeping `--sourcedir` for kernel source directory
specification.
I also tried to disambiguate `SRCDIR` in kpatch-build a bit. Now there
are 3 variables:
- `KERNEL_SRCDIR` - contains path to kernel source directory
- `OOT_MODULEL_SRCDIR` - contains path to out-of-tree module source directory
- `BUILDDIR` - can be set to either of the above and is used for
patch-related actions
Another attempt at this was done by @omatiusha in #1234
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Upstream v5.14+ kernel change a358f40600b3 ("once: implement
DO_ONCE_LITE for non-fast-path "do once" functionality") consolidated a
bunch of do-once macros into a common macro:
#define DO_ONCE_LITE_IF(condition, func, ...) \
({ \
static bool __section(".data.once") __already_done; \
...
which replaced static local variable __warned with __already_done.
Update any __warned static local checks to also look for the new
__already_done variable as well.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The kpatch-build script sets and exports a bunch of environment varibles
like KCFLAGS as well as data structure sizes in <STRUCT>_SIZE.
Dump the current environment to $CACHEDIR/tmp/kpatch-build.env so these
values can be more easily reused later:
% source <PATH>/kpatch-build.env && <command>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
RHEL-9 integration tests revealed that the kernel now makes use of
R_PPC64_REL64 relocations in the jump table, but need_dynrela() contains
code to specifically skip any R_PPC64_REL64 type when determining if a
relocation should be turned into dynrela.
Kamalesh Babulal explains:
I tried digging a little deeper and the upstream Kernel commit
b0b3b2c78ec (powerpc: Switch to relative jump labels) in v5.13,
introduced the change of generating relocation entries of type
R_PPC64_REL64, instead of absolute relocation type R_PPC64_ADDR64:
Relocation section '.rela__jump_table' at offset 0x1a87d8 contains 303 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
...
00000000000003c8 000007910000002c R_PPC64_REL64 0000000000000000 __tracepoint_netif_receive_skb + 8
...
Relax the existing check in need_dynrela() for .rela__jump_table
R_PPC64_REL64 relocations in case we need dynrelas for them.
Fixes: #1212
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
create-klp-module could error out and in this case ensure that
kpatch-build does not proceed further.
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Building data-read-mostly.patch on rhel-9.0-beta for ppc64le leads to a
segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
kpatch_check_relocations (kelf=0x10040490) at create-diff-object.c:2571
2571 sdata = rela->sym->sec->data;
(gdb) bt
(gdb) p rela->sym->sec->data
Cannot access memory at address 0x160000007e
Valgrind narrows the problem down to invalid reads through rela->sym in
kpatch-check-relocations().
The culprits are kpatch_create_intermediate_sections(), which marks
symbols referenced by rela sections that are now dynrelas to be
stripped, and kpatch_strip_unneeded_syms(), which removes and frees
them.
The problem with the symbol stripping is that multiple relas may
reference the same ELF symbol. If any remaining relocation references a
shared symbol, we must keep it.
Replace the symbol->strip boolean with an enumeration:
SYMBOL_DEFAULT - initial value, symbol usage unknown
SYMBOL_USED - symbol is definitely used by a rela
SYMBOL_STRIP - symbol was only referenced by dynrela(s)
Allow transitions from SYMBOL_DEFAULT to SYMBOL_* and SYMBOL_STRIP to
SYMBOL_USED, but _not_ SYMBOL_USED to SYMBOL_*.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
After commit 17dcebf077 ("kpatch-build: enable klp with replace option by default"),
building the old-style (kpatch.ko-based) patches fails with the following
error:
"kpatch core module (kpatch.ko) does not support replace, please add -R|--non-replace"
kpatch.ko actually supports atomic replacement of patches but KLP_REPLACE
has nothing to do with that. Let us not break such builds and remove that check.
Fixes: 17dcebf077 ("kpatch-build: enable klp with replace option by default")
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
While theoretically most of these functions can work both ways right now
all calls follow the same pattern: first argument is orig element and
second is patched element. Rename the arguments so that these functions
are used in the same fashion going forward. This allows us to cut some
corners such as removing the elseif statement in kpatch_correlate_symbol().
Signed-off-by: Artem Savkov <asavkov@redhat.com>
