It turns out there is a stretch of time in kernel's history when
CONFIG_DEBUG_INFO_BTF was already added, but Makefile.modfinal wasn't
split off yet. To address those we need to either check the file's
existance or, as @liu-song-6 suggested initially, check config for
CONFIG_DEBUG_INFO_BTF_MODULES=y.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
With CONFIG_DEBUG_INFO_BTF_MODULES, the kernel build process adds BTF to
each in-tree modules. However, this process is broken with kpatch, with
error message like:
Failed to parse base BTF 'vmlinux': -4001
Unblock build with CONFIG_DEBUG_INFO_BTF_MODULES with similar workaround
as the one for CONFIG_DEBUG_INFO_BTF.
Signed-off-by: Song Liu <songliubraving@fb.com>
On module installation kpatch utility creates a directory with kernel
version as a name in /var/lib/kpatch which is never removed. To address
this check if any files are left in this directory after each
'uninstall' call and if not - remove it.
Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
Make kpatch_mangled_strcmp treat two strings as the same in case when
one has a digit tail and the other one doesn't.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
gcc-generated static variables always have a numbered suffix, while
clang-generated static variables are always prepended with a function
name. Change is_special_static() so that it detects both cases.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Add patches rebased on top of upstream 5.10.11 tarball. Integration
tests for these can be ran as this:
make PATCH_DIR="linux-5.10.11" KPATCHBUILD_OPTS="-s /path/to/src/linux-5.10.11" integration-slow
Signed-off-by: Artem Savkov <asavkov@redhat.com>
clang does not always use __UNIQUE_ID as prefix and can generate symbols
with names like this:
trace_nfsd_exp_get_by_name.__UNIQUE_ID___addressable___SCK__tp_func_nfsd_exp_get_by_name645
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Clang adds .L.str* symbols to .rodata.str sections which are used for
__FILE__ references. These are discarded during linking so add them to
maybe_discarded_sym().
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Add support for clang-built kernels. This is completely automatic, we
check if the kernel was built with clang by looking for
CONFIG_CC_IS_CLANG in config.
This has almost no effect on non-clang built kernels with one exception:
we now do compliler checks _after_ we download kernel sources which is a
waste of resources in case when compilers don't match.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Be robust and use "cp -f". Finish with "|| die" to be dead serious
about it.
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
kpatch-build requires gcc flags -f[function|data]-sections when building
original and patched targets. These flags result in an ELF binary with
many sections, potentially requiring special extended ELF header
processing to parse correctly.
CONFIG_DEBUG_INFO_BTF invokes pahole as part of the kernel build and
unfortunately pahole cannot iterate through more than 65535 section
headers. As result, the pahole program segfaults and fails the build
like so:
...
BTF .btf.vmlinux.bin.o
scripts/link-vmlinux.sh: line 127: 718345 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
objcopy: --change-section-vma .BTF=0x0000000000000000 never used
objcopy: --change-section-lma .BTF=0x0000000000000000 never used
objcopy: error: the input file '.btf.vmlinux.bin' is empty
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make: *** [Makefile:1050: vmlinux] Error 1
Workaround this limitation by disabling CONFIG_DEBUG_INFO_BTF code in
scripts/vmlinux-link.sh during kpatch-build. This leaves
CONFIG_DEBUG_INFO_BTF contingent kernel code in place, but skips the
problematic pahole .BTF typeinfo generation step (for which kpatch
doesn't care about anyway).
Link: https://lore.kernel.org/dwarves/20210119231718.GA3173@redhat.com/T/
Link: https://lore.kernel.org/dwarves/20210121202203.9346-1-jolsa@kernel.org/T/
Link: https://lore.kernel.org/dwarves/20210122163920.59177-1-jolsa@kernel.org/T/
Link: https://lore.kernel.org/dwarves/b1469725-d462-9a6d-3329-f77c9eb6b43f@redhat.com/T/Fixes: #1153
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Starting v5.11-rc, kpatch-build fails on powerpc with the error:
ERROR: invalid ancestor arch/powerpc/kernel/vdso64/vdso64.so.dbg for arch/powerpc/kernel/vdso64/vgettimeofday.o
the upstream commit ab037dd87a2f(powerpc/vdso: Switch VDSO to generic
implementation) introduced this breakage, lets skip vdso files. They are
not compatible with kpatch.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
From Linux-5.1 onward, the sysfs interface to send signals to
processes stalling livepatch transitions is replace by a peridical
signal sent by the kernel.
On such systems, the kpatch signal subcommand does nothing. Just
let the user know they don't need to worry about it.
Fixes: #1151
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Starting with v5.10 kbuild no longer builds built-in targets for
external modules (including extra-y). Further it wasn't guaranteed that
extra-y targets were going to be built before linking.
Do a proper thing and add kpatch.lds as a dependency for $(KPATCH_NAME).o.
Upstream discussion for reference: https://lore.kernel.org/linux-kbuild/20201103054425.59251-1-chao.wang@ucloud.cn/Fixes: #1148
Signed-off-by: Artem Savkov <asavkov@redhat.com>
There exists a very small timing window in which "kpatch unload" gets to
its "rmmod" step before the kpatch-patch module's reference count has
cleared and the "rmmod" fails.
This is only a transient problem, but we can adopt code from upstream
livepatch kselftests which wait for the module refcounts to settle
before moving onto "rmmod".
A small wrinkle is that this is not supported by the older kpatch.ko
core. The price for circumventing the activeness safety check via
KPATCH_FORCE_UNSAFE is that it must leave the kpatch patch modules in
place (see e1890e627a ("prevent rmmod of forced modules")).
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Convert __section to __kpatch_section to fix compile errors since
Linux 5.10, commit 33def8498fdd ("treewide: Convert macro and uses of
__section(foo) to __section("foo")").
Signed-off-by: WANG Chao <chao.wang@ucloud.cn>
__verbose has renamed to __dyndbg since Linux 5.9, commit e5ebffe18e5a
("dyndbg: rename __verbose section to __dyndbg")
Signed-off-by: WANG Chao <chao.wang@ucloud.cn>
Currently all the callers of kpatch_write_output_elf() are creating
.o object files or .ko kernel modules. Neither of these filetypes are
executable on their own, so enhance kpatch_write_output_elf() to accept
file creation mode and update its callers to pass 0664 to match
the expected permissions.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Interesting changes since v0.9.1:
- Integration test support for rhel-{7.8,7.9,8.1,8.2}, centos-8
- Better support for gcc child functions
- Batch jump label errors to report all instances
- Dynrela code cleanup
- Remove .klp.arch and add support for jump labels in v5.8+ kernels
- Mark ignored sections earlier to support functions missing ftrace hook
- Minor README.md improvements
- Add ppc64le mcount support to patched functions
- Show additional stalled process information in kpatch script
- Increased shellcheck coverage and fixes
- ppc64le plugin fixes for gcc v10
- Ignore __UNIQUE_ID_ symbol from tristate config objects
- Don't clear dmesg during integration tests
- Detect and report MODVERSIONS symbol version CRC changes
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
User disaster123 reports the following build errors:
create-diff-object.c: In function 'kpatch_process_special_sections':
create-diff-object.c:2215:41: error: 'key' may be used uninitialized in this function [-Werror=maybe-uninitialized]
code->sym->name, code->addend, key->sym->name);
^~
create-diff-object.c:2138:22: note: 'key' was declared here
struct rela *code, *key, *rela;
^~~
In file included from kpatch-elf.h:26,
from create-diff-object.c:53:
log.h:20:3: error: 'code' may be used uninitialized in this function [-Werror=maybe-uninitialized]
printf(format, ##__VA_ARGS__); \
^~~~~~
create-diff-object.c:2138:15: note: 'code' was declared here
struct rela *code, *key, *rela;
^~~~
cc1: all warnings being treated as errors
These are reproducible when building with 9.3.1 and 8.3.1 when building
with optimization level > 2 ( CFLAGS=-O2 make ). Fix them by
initializing the reported variables to NULL and verifying that they are
infact non-NULL after processing the __jump_table.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Rebased against kernel-3.10.0-1160.el7.
data-read-mostly.patch.disabled remains disabled as we hit several build
errors like:
"Found a jump label at __netif_receive_skb_core()+0x50, using key
netstamp_needed. Jump labels aren't supported with this kernel. Use
static_key_enabled() instead."
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Explain MODVERSIONS in enough detail for a kpatch author:
- What is it
- How does a kpatch interact with it
- How does kpatch-build report problems
- How to fix / avoid CRC mismatches
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Add a RHEL reproducer that causes a kpatch-build to fail when the final
module references a symbol with a different CRC than the original
kernel.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
If the final module has a reference in its symbol table to a kernel
symbol and the symbol version differs from the kernel symbol version,
the module will be unloadable.
Have kpatch-build emit a clear error and die in such a case instead
of providing an unusable module.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The CRCs of exported symbols Module.symvers can differ between the
original build and the patched build.
In such a case, it is probably wise to rework the patch to avoid such
modifications.
Warn when a symbol changes version in the exported symbol list.
Fixes issue #1084
Signed-off-by: Julien Thierry <jthierry@redhat.com>
When patching an OOT module, the symbol version file is obtained by
combining the file from the module build and the Module.symvers file
provided with kernel headers. This is done for each modified .o in the
OOT build.
Create the final Module.symvers file once for the whole OOT module.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
we remove the pre_patch_callback/post_unpatch_callback from the
stop_machine context. If a schedule/sleep happend in callbacks while the
process to be scheuded later will send IPI, because all interrupts
are disabled, the machine will trap into a deadlock in such situation.
So we remove the pre_patch_callback and post_unpatch_callback from
the stop_machine to avoid such situation. On the other hand, to avoid
the race between the patched code and post-patch/pre-unpatch callbacks when
run in parallel, we didn't remove the post_patch_callback and
pre_unpatch_callback from stop_machine.
