On RHEL I'm seeing issues with putting the core module in the "extra"
path. On the next depmod run, it gets added to modules.dep, and on a
subsequent kpatch install I see the following errors:
/usr/lib/dracut/modules.d/50drm/module-setup.sh: line 26: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh: line 14: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
modinfo: ERROR: Module /lib/modules/3.10.0-123.4.4.el7.x86_64/weak-updates/kpatch/kpatch.ko not found.
Until the core module gets merged into Linux, I think we can put it in
/usr/lib/kpatch, which is also where the patch modules are going to be
delivered in the RHEL RPM.
Making sure the other options still work with the kpatch utility for
now, so as to keep backwards compatibility between a newer kpatch
utility and older core modules. We can break this compatibility for
kpatch 0.2.0.
Right now, the test patch unnecessarily includes hrtimer_nanosleep()
because the call to do_nanosleep() generates a rela the references the
unbundled .sched.text section. This section symbol is not currently
replaced by kpatch_replace_sections_syms() as it only replaces bundled
sections symbols.
This commit adds logic to kpatch_replace_sections_syms() to replace
unbundled section symbols as well by scanning the symbol table for
symbols that start at the rela entry's offset within the matching
section.
This allows for properly rela section correlation when the functions
have moved from an unbundled section to a bundled section.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This macro is for ignoring sections that may change as a side effect of
another change or might be a non-bundlable section; that is one that
does not honor -ffunction-section and create a one-to-one relation from
function symbol to section.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Right now, in the case that the mcount sections have changed, we get a
"changed section not included" error on them. Since we rebuild them
from scratch, just mark them as SAME even if they are different so that
we don't cause an error.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This sh_link line currently has a bug with both operands being sec1; the
second should be sec2. However the bug is masking a logical flaw; that
is that the sh_link is the index of either the symtab or the strtab and
that can change if sections have been added or removed by the patch.
This commit removes the comparison.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
gcc renames static local variables by appending a period and a number.
For example, __key could be renamed to __key.31452. Unfortunately this
number can arbitrarily change. Try to rename the patched version of the
symbol to match the base version and then correlate them.
Fixes#313.
The correlation logic could get confused if it compares two relas whose
symbols haven't been converted from section symbols to object or
function symbols. So we should replace section symbols for both the
base and the patched object before correlating, so that it can compare
the function and object symbols rather than the section symbols.
This is also a prerequisite for dealing properly with gcc's renaming of
static local variables, because relas which reference static locals
usually use section symbols.
Now that we use the vmlinux from the distro debug package we don't need
to do any build runs without -ffunction-sections -fdata-sections.
Old:
Build orig in objdir
Build patched in objdir
Build orig w/ flags in objdir2
Copy orig .o's into orig
Build patched w/ flags in objdir2
Copy patched .o's into patched
New:
Build orig w/ flags in objdir
Build patched w/ flags in objdir
Copy patched .o's into patched
Build orig w/ flags in objdir
Copy orig .o's into orig
This commit also does try to build each change object singularly since
there are cases in the kernel tree where the Makefile does not reside in
the same directory as the changed object.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This may end up being useful in the distro patch module upgrade path.
If the core module also needs updating, we can first do "kpatch unload
--all" and "rmmod kpatch" before doing "kpatch load" of the new patch
module.
This commit adds the KPATCH_IGNORE_FUNC() macro for ignoring functions
that may change as a side effect of a change in another function. The
WARN class of macros, for example, embed the line number in an
instruction, which will cause the function to be detected as changed
when, in fact, there has been no functional change.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
When patching a module, I ran into a "can't set ftrace filter at
address" error. The root cause was due to the fact that
mod->module_core + old_offset is apparently not a reliable way to
determine the function's address.
Instead, just get the address from kallsyms like we do for module
dynrelas.
User reported cases where libraries are in lib32/64 directories, not
lib.
Allow the user to override by setting LIBDIR.
Fixes#167
Signed-off-by: Seth Jennings <sjenning@redhat.com>
There are more reasons besides mentry support for 3.9 being the
minimum supported kernel version. There are also API changes that
happened in 3.9 that make the core module incompatible with previous
versions.
Rather than spelling all that out, just simply state the minimum
version.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Some of the kernel APIs that are used by the core kernel module where
updated in 3.9 and are incompatible with previous kernel versions.
Update the README to reflect this.
Fixes#257
Signed-off-by: Seth Jennings <sjenning@redhat.com>
