Commit Graph

4 Commits

Author SHA1 Message Date
Josh Poimboeuf
84c34ff584 implement per-object patching/relocations
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().
2014-06-17 10:03:08 -05:00
Seth Jennings
681a6e80b9 refactor core <-> patch interface
Make kpatch_funs truly internal by:
Defining it in core.c
Adding a struct kpatch_internal, declared in kpatch.h and defined in
 core.c, that contains per patch module internal data.
Adding an "internal" field to struct kpatch_modules.
Allocating internal and funcs data in core.c, not in the patch module,
 since the patch module has no knowledge of kpatch_func anymore.
Adding a "patch" field to kpatch_func that points directly to the
 kpatch_patch provided by the module (rather than a field-by-field copy)

Signed-off-by: Seth Jennings <sjenning@redhat.com>
2014-05-12 14:58:29 -05:00
Josh Poimboeuf
f3f39c0587 fix activeness safety check when unpatching
When unpatching, the activeness safety logic should check for the new
function on the stack, not the old one.

Fixes #64.
2014-04-23 14:37:35 -05:00
Josh Poimboeuf
bfad3b1880 kmod/core: update API and use hash table
My apologies for the size of this commit.  I combined these two features
(updating API and using a hash table) into a single commit because their
implementations are tightly coupled and I didn't want to have to add
support for the old kpatch_funcs array with the new API just for the
sake of splitting up the commit :-)

- Update the core module API to get a more clear separation between core
  module and patch module.  This is cleaner and will help our case for
  getting the core module merged upstream into the kernel.
- Convert the old kpatch_funcs array into a hash table.  This is so much
  nicer performance-wise and everything-else-wise than that ugly old
  array.
- Do the incremental patching in stop machine.  This ensures that the
  funcs hash is up to date and we don't miss anything.
- Disable preemption in the ftrace handler when accessing the func hash.
  That way we don't get conflicts with the stop_machine handler updating
  the hash.
2014-03-18 13:34:15 -05:00