Increment version to 0.6.0 due to 926e4e0c7d ("kmod: add support for
in-kernel livepatch hooks"), which removed the kpatch (un)load hook API
support and converted to livepatch-style hooks.
Additional changes include:
* Lots of misc bugfixes and cleanups
* Manpage, README.md fixups
* More PPC64 work
* "Undefined reference" build failure rework
* Livepatch disable retries
* New unit testing framework
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
I loaded a livepatch on an idle 112 CPU system, and it took over three
seconds for the patch transition to complete:
[1561551.584871] livepatch: 'livepatch_foo': starting patching transition
[1561554.867486] livepatch: 'livepatch_foo: patching complete
Presumably this is because more CPUS == more kthreads and idle tasks,
which are more likely to be running at any given time.
Currently the kpatch script will start signaling tasks if the transition
takes more than five seconds. Increase that timeout a bit to 15
seconds, to give big/busy systems more time before we start signaling.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
I placed the library in the top-level test directory, as the same
assertions could also be used by the integration tests once we rework
them a bit.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
As an extra sanity check, ensure the number of patched functions never
changes.
Also added a test for convert-global-local to ensure the global symbol
is converted to a local.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cleaning house a bit. Now that we have unit tests, a lot of these tests
aren't very useful anymore.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Update the `__LINE__` macro detection heuristics based on recent kernel
changes:
- __warn_printk(), used in the WARN macros, which put the line number in
%edx
- __might_fault(), used in the usercopy macros
- lockdep_rcu_suspicious(), used in the RCU_LOCKDEP_WARN macro
- printk(), used in the ASSERT_RTNL macro
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Broaden the impact of the 'clean' target so that output objects will
still get cleaned when when old tests get removed or renamed.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
After doing some research, I've discovered that most of these tests no
longer test what they were originally intended to test.
An exception here is the 'macro-hooks' test, which is probably better
suited as an integration test, so I removed its unit test and kept its
integration test.
Really, most of these tests weren't all that useful to begin with, so
it's not a big loss. The one exception is 'gcc-static-local-var-2',
which was originally meant to test multiple static local variables with
the same name in the name function. That's a good thing, so I'll try to
come up with another test for that which works with Linux 4.16.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
With #755, we started using dynrelas for function pointers. However,
this behavior only makes sense for function pointers to existing
functions. For function pointers to *new* functions, just use a normal
rela.
The 'function-ptr-new' unit test is from the following patch:
https://github.com/dynup/kpatch/files/1927198/new-static-callback.patch.txtFixes#834.
Fixes: 495e619750 ("kpatch-build, x86: do not use the patched functions as callbacks directly")
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Because $PLUGIN variable is a part of $TARGETS we are trying to install
gcc-plugins twice which is treated as an error by install command:
/usr/bin/install create-diff-object create-klp-module create-kpatch-module gcc-plugins/ppc64le-plugin.so kpatch-gcc gcc-plugins/ppc64le-plugin.so /usr/local/libexec/kpatch
/usr/bin/install: will not overwrite just-created '/usr/local/libexec/kpatch/ppc64le-plugin.so' with 'gcc-plugins/ppc64le-plugin.so'
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Don't suppress stderr in the non-fail unit tests so that
create-diff-object error messages will be printed.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Since commit 926e4e0c7d ("kmod: add support
for in-kernel livepatch hooks") livepatch-patch-hook.c unconditionally
creates callbacks. This causes build error for kernels older than 4.15:
make -C /home/rppt/git/linux M=/home/rppt/.kpatch/tmp/patch livepatch-proc-vmalloc-live.ko
make[1]: Entering directory '/home/rppt/git/linux'
CC [M] /home/rppt/.kpatch/tmp/patch/patch-hook.o
In file included from /home/rppt/.kpatch/tmp/patch/patch-hook.c:21:0:
/home/rppt/.kpatch/tmp/patch/livepatch-patch-hook.c:82:23: error: field ‘callbacks’ has incomplete type
struct klp_callbacks callbacks;
^
/home/rppt/.kpatch/tmp/patch/livepatch-patch-hook.c: In function ‘patch_init’:
/home/rppt/.kpatch/tmp/patch/livepatch-patch-hook.c:395:10: error: ‘struct klp_object’ has no member named ‘callbacks’
lobject->callbacks = object->callbacks;
^
scripts/Makefile.build:302: recipe for target '/home/rppt/.kpatch/tmp/patch/patch-hook.o' failed
make[2]: *** [/home/rppt/.kpatch/tmp/patch/patch-hook.o] Error 1
Makefile:1687: recipe for target 'livepatch-proc-vmalloc-live.ko' failed
make[1]: *** [livepatch-proc-vmalloc-live.ko] Error 2
make[1]: Leaving directory '/home/rppt/git/linux'
Makefile:20: recipe for target 'livepatch-proc-vmalloc-live.ko' failed
make: *** [livepatch-proc-vmalloc-live.ko] Error 2
Introduce HAVE_CALLBACKS to allow conditional compilation of the callbacks
addition.
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Elaborate on the difficulties in using locks/mutexes from the kpatch
callback routines and suggest a few workarounds.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Add a simple unittest framework for create-diff-object implemented in
GNU Make.
It will automatically scan the kpatch-unit-objs/$(uname -m) directory
for specifically named files running one of 3 tests:
- creating diff object with expected success
- creating diff object with expected failure
- creating diff object and running a shell script on it with expected
success
Signed-off-by: Artem Savkov <asavkov@redhat.com>
- convert section/symbol indexes and rela->offset to unsigned int as I
couldn't find any way for them to become negative.
- cast a number of rela->addend comparisons to int (assuming an 64bit
system this should be enough)
- a number of simple for-loop counter conversions to the type it
compares against
Signed-off-by: Artem Savkov <asavkov@redhat.com>
If a patch failed a first time, kpatch-build is using the previous
cache directory on subsequent builds. The UBUNTU_KERNEL=1 variable is
not set in this case. Therefore, utsrelease.h is not updated correctly
and the appropriate structures are not used. Just check if distro is
Ubuntu and we didn't request our own specific directory.
Signed-off-by: Vincent Bernat <vincent@bernat.im>
Because of signedness difference kpatch_check_relocations() would trigger
an error on any negative addend.
Fix by casting Elf_Data->d_size from size_t to int.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Check that none of the relocations are out-of-range of their
corresponding sections before writing the output elf.
Fixes: #618
Signed-off-by: Artem Savkov <asavkov@redhat.com>
The module notifier currently only handles newly loaded modules in the
MODULE_STATE_COMING state. If target modules need to be unloaded, the
any kpatch module that patches it must first be disabled, releasing
module references held against the target module. When the kpatch
modules are disabled, the target module is unpatched and the kpatch
core's data structures updated accordingly.
If a loading module happens to fail its init routine (missing hardware
for example), that module will not complete loading. The kpatch core
doesn't properly account for this "phantom" target module, so when the
kpatch patch module is removed, it spews out an ugly warning when
attempting to remove a non-existing ftrace filter on the target module.
Register an additional module notifier (first in the list) to handle the
MODULE_STATE_GOING case. This handler needs to do the inverse of the
MODULE_STATE_COMING handler.
Fixes#699.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
