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.
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>
I found a bad bug:
- Module A is loaded, and registers function foo() with
KPATCH_FORCE_UNSAFE.
- Module A is unloaded. The new version of foo() is on the backtrace of
a task, but the core module ignores it because of the force flag, so
the unloading succeeds.
- The task returns to the new version of foo() which no longer exists.
- BOOM.
The only way I can think of to prevent this scenario is to prevent
forced modules from being unloaded (but still allow them to be
disabled).
An annoying side effect of this approach is that forced modules stay
loaded and in memory forever. And that after "kpatch unload" of a
forced module, you can't ever load it again because the previous
instance of it is still loaded (but permanently disabled).
This is ugly but I can't really think of a better way to handle it. If
necessary we could create a workqueue and periodically check to see if
we can safely call module_put() so that the module could be eventually
removed.
WARN macros are problematic because they embed the line number in an
instruction. As a result, when a function is changed higher in a file,
the line numbers for any WARN calls below that function in the file can
result in unnecessarily changed functions.
These macros allow a patch author to hard code the line numbers in WARN
macros to prevent functions from otherwise changing and getting pulled
into a patch module unnecessarily.
When running kpatch-build with -d, I was getting a seg fault. It was
faulting in kpatch_dump_kelf() when trying to print sec->secsym->name
for the .smp_locks section. It turns out that the section was included
but its section symbol wasn't included, so sec->secsym pointed to freed
memory.
This fixes the following issue for a patch which changes a module:
kpatch_create_mcount_sections: 1968: bad first rela in .rela.text.e_show
The first rela is "bad" because the real first rela was converted to a
dynrela and then removed from the rela list.
This is a temporary fix. The more permanent fix should be to allow
lookups in vmlinux for patched modules so we don't create any
unnecessary dynrelas.
