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>
module-call-external.patch and new-function.patch fail to build on
ppc64le with "Found an unsupported sibling call". Add
fno-optimize-sibling-calls attributes to functions in question.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Depending on environment, "Permission denied" error may occur
when /sys/kernel/debug/dynamic_debug/control setting.
Signed-off-by: Keiya Nobuta <nobuta.keiya@fujitsu.com>
Updating version in preparation for rhel9 support.
Changes since v0.9.4:
- openEuler support
- kpatch-build: Do not check KLP_REPLACE for kpatch.ko-based patches
- create-diff-object: fix use after free in kpatch-check-relocations()
- kpatch-build: Handle error in create-klp-module
- create-diff-object: support ppc64le relative jump labels
- kmod/patch: clean only rebuildable objs
- kpatch-build: save environment varibles to file
Signed-off-by: Artem Savkov <asavkov@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>
Relax the clean target to leave the kpatch-build generated output.o file.
This is helpful after invoking kpatch-build in debug mode and rebuilding
$CACHEDIR/tmp/patch in a debugging session.
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>
Interesting changes since v0.9.3:
- Support for multiple source files
- Makefile tweaks for handling non-replace kpatch building
- Support CONFIG_PRINTK_INDEX
- kpatch-build: set EXTRAVERSION and not localversion for RH kernels
- Make sure section symbols exist
- create-diff-object: Check that the section has a secsym
- kpatch: rmmod module of the same name before loading a module
- kpatch-build: enable option -R|--replace to build replace klp
- kpatch: use /sys/kernel/kpatch/ to check whether core module is loaded
- kpatch: Sync signal subcmd usage output with manpage
- fixes for the out-of-range relocation check
Signed-off-by: Yannick Cote <ycote@redhat.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>
Rename "base" to "orig" when referencing object files and their contents
to be consistent with temporary directory structure.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
So far create-diff-object worked only with objectfiles built from a
single source file. To support object-files built from multiple sources
such as linked vmlinux.o, we call locals_match() for each of STT_FILE
symbols and store the pointer to the beginning of appropriate symbol
block in lookup table in each symbol.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
At the moment lookup_symbol() takes symbol name as an argument which
might not be enough in some cases (e.g. for objectfiles built from
multiple source files). Make it accept full symbol structure.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
gcc-static-local-var-4.patch is disabled on this distribution, disable
the test as well as it will always fail during 'slow' integration test
runs.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
For each printk() call site, CONFIG_PRINTK_INDEX makes a static local
struct named `_entry`, and then adds a pointer to it in the
`.printk_index` section.
When regenerating the `.printk_index` section for the patch module, we
only need to include those entries which are referenced by included
functions. Luckily this is a common pattern already used by several
other "special" sections. Add `.printk_index` to the special section
handling logic.
Fixes: #1206
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
CONFIG_PRINTK_INDEX creates a static local struct variable named
`_entry` for every call site to printk(). The initializer for that
struct assigns the `__LINE__` macro to one of its fields.
Similarly to the WARN macro's usage [1] of `__LINE__`, it causes
problems because it results in the line number getting directly embedded
in the struct. If a line is added or removed higher up in the source
file, the `_entry` struct changes accordingly due to a change in the
printk() call site line number.
`_entry` is similar to other "special" static locals, in that we don't
need to correlate the patched version with the original version. We can
instead just ignore any changes to it.
Any substantial (non-line-number) change to the `_entry` struct would be
a second-order (dependent) effect of a first-order code change, which
would be detected using other means. In that case the patched version
of `_entry` will be included, due to being referenced by the changed
function.
Fixes: #1206
[1] See kpatch_line_macro_change_only()
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Oleh Matiusha
Markus Boehme
Joe Lawrence
David Vernet
Artem Savkov
Keiya Nobuta
Sumanth Korikkar
Evgenii Shatokhin
gouhao
Yannick Cote
Yannick Cote
Josh Poimboeuf