This is useful if ~/.kpatch is a symlink or a tmpfs mount.
- move SRCDIR/OBJDIR/OBJDIR2 initialization to the top
- create new VERSIONFILE variable
- create new clean_cache function which doesn't remove ~/.kpatch
Fixes#261.
Right now, if there is a failure in patch_make_dynrelas_list(),
patch_free_objects() is called twice; once in the error section of
patch_make_dynrelas_list() and again in the err_objects section of
patch_init().
This fixes this and cleans up the error handling a bit.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
In my experience this is a much more useful implementation of the
"--sourcedir" option:
- use the source tree in-place rather than first copying it to
~/.kpatch/src. In my case this avoids a 5GB copy, including the
entire .git subdirectory, and allows ccache to be reused.
- find the vmlinux and .config files in the sourcedir
- autodetect the ARCHVERSION
Add -d option to create-diff-object when DEBUG is set. That way for
weird kpatch-build issues we can just tell people to use the -d flag and
then provide the build log.
- replace the old low-level video with the new high-level one, and place
it with screenshot prominently at the top
- increase default ccache size
- remove obsolete NOTEs
- add blurb about patching modules and -t
- "trampoline" -> "handler"
- more details about ftrace, perf, tracepoints compatibility
- add recommended practice re: single cumulative module vs multiple
independent modules
When patching module A, if one of the new function's relas reference a
symbol in module B, we currently just leave it as a normal rela. But if
module B hasn't been loaded yet, the patch module will fail to load due
to the rela's reference to an undefined symbol.
The fix is to convert these relas to dynrelas, which can be resolved
later in the module notifier when A is loaded.
Also added support for the R_X86_64_NONE relocation type, needed for
dynrelas which reference __fentry__.
This commit adds basic debuginfo support. It is "basic" in as much as
it does not try to parse the DWARF data to figure out which parts
pertain to the changed code. It simply includes all .debug_ and
.rela.debug_ section and strips out any rela entries that reference
unchanged symbols. This corrupts the debuginfo for unchanged symbols
but since they are not going to be included anyway, there should be no
way to reference that information.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
The recent module patching code has exposed some problems with our data
structures. We currently patch the funcs and dynrelas individually,
which is kind of scary now that different objects can be patched at
different times. Instead it's cleaner and safer to group them by
patched object.
This patch implements per-object patching and relocations by refactoring
the interfaces:
- Completely separate the create-diff-object <-> patch module interface
from the patch module <-> core module interface. create-diff-object
will include "kpatch-patch.h" but not "kpatch.h". Thus,
create-diff-object has no knowledge about the core module's
interfaces, and the core module has no knowledge about the patch
module's special sections.
- Newly added kpatch-patch.h defines the format of the patch module
special sections. It's used by create-diff-object to create the
special sections and used by the patch module to read them.
- kpatch.h still defines the core module interfaces. Each kpatch_module
has a list of kpatch_objects for each module object to be patched.
Each kpatch_object has a list of kpatch_funcs and a list of
kpatch_dynrelas. The patch module creates these lists when populating
kpatch_module.
This way of structuring the data allows us to patch funcs and dynrelas
on a per patched object basis, which will allow us to catch more error
scenarios and make the code easier to manage going forward. It also
allows the use of much more common code between kpatch_register() and
kpatch_module_notify().
This adds support to kpatch-build for patching modules. It builds the
entire kernel tree, vmlinux and modules, in a single pass and then
detects which modules need to be patched. This is the easiest case
(since the user doesn't need to care about which binaries are affected)
and the safest (since the user could be wrong).
The first build with no ccache takes a long time, but after the cache is
populated, it only takes about two minutes on my laptop. It does take
up a TON of space in the cache now though (~/.kpatch/obj is now 8GB).
Next we can add the '-t' cmdline option for advanced users to specify
build targets.
Revert the previous kpatch-build module building interface commits to
prepare for a completely different approach which builds vmlinux and all
the modules in a single pass.
This reverts commit fac9d70612.
This reverts commit d166fb4379.
This allows a patch module to contain patched functions for modules
which haven't been loaded yet. If/when the module is loaded later, it
will be patched from the module notifier function.
In the replace case, stop calling module_put on a patch module before
we're potentially done with it.
This will also be needed for future module patching if we want to
properly replace a patch module which only patches a future loaded
module (that's a mouthful).
Fixes#165.
Create a list of registered patch modules, which will be used in the
module notifier to patch future loaded modules. It will also be used to
fix the kpatch replace race condition where it calls module_put too
early.
The kpatch_internal struct is a good idea, in that it documents which
parts of kpatch_module shouldn't be used by the patch module. But it
creates extra code and will require more extra code if we want to keep a
list of kpmods, which is needed to create a module notifier for module
patching of future loaded modules.
Embedding the private data directly in the public struct allows the code
to be simpler: no extra kmallocs/kfrees, no need to store pointers
between the public and private structs. I think the simpler code is
worth the tradeoff (exposing implementation detail). Kernel code
usually doesn't bother with hiding a internal struct data from other
kernel code anyway. For example, see ftrace_ops or struct kprobe.
The private fields are documented with a "private" comment.
