Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions in
the DWARF metadata.
Fixes#517.
Fixes#523.
-ffunction-sections and -fdata-sections are needed when building the
original and the patched kernels.
It is not necessary, however, to use these options when building a
patch module itself, its functions and data are OK in the sections they
are.
Let us remove these options from KCGLAGS after the kernels have been
built.
If a source RPM is used to obtain the kernel sources, kpatch-build
executes rpmdev-setuptree to prepare ~/rpmbuild directory tree, installs
the source RPM there. Then it calls 'rpmbuild -bp' to prepare the
kernel source tree.
All this, however, may clobber the existing contents of ~/rpmbuild,
which is very inconvenient if one uses rpmbuild to build other packages.
To avoid that, I could not find a better way than to specify a fake home
directory (~/.kpatch/tempsrc) for that portion of kpatch-build. It seems,
neither rpmdev-setuptree nor rpm have appropriate options for that.
I put the affected commands into a subshell so that the changes in $HOME
could not propagate to other parts of kpatch-build.
If kpatch core module is packaged in an RPM and the package is installed,
the likely location of the module and its symvers file is
/lib/modules/<kernel_version>/extra/kpatch/.
kpatch-build checks this location too now when looking for the .symvers
file. This is convenient for distributing the Kpatch tools as RPMs and
the like.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
Before this fix, kpatch-build looked for Module.symvers for the core
module built for the currently running kernel. So, if one tried to build
a patch module for a kernel, different from the current one, an error
would occur. This patch fixed the problem.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
Before this patch, if changed function is weak symbol, it is not
be allowed to create live patch, and it will trigger the following
error:
/usr/local/libexec/kpatch/create-diff-object: ERROR: ***.o:
kpatch_create_patches_sections: 2294: lookup_global_symbol ***
And if the changed function reference the weak symbol, when loading
the patch module will trigger the following error:
module kpatch-***: overflow in relocation type *** val 0
insmod: can't insert 'kpatch-***.ko': invalid module format
This patch fix it and add support for patching weak function.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
kpatch_verify_patchability can detect the change of .bss or .data or
.init section, but it must be processed before verify num_changed.
Otherwise, for example, if only .init section changed, it will fail
with 'no changed functions were found', but not 'unsupported section
change(s)'.
With this patch,
for .init section: .init section will not a bundled section, so if
the section changed, not sync the function status, kpatch_verify_patchability
will give 'changed section <secname> not selected for inclusion' and
'unsupported section change(s)' error.
for .bss/.data section: kpatch_verify_patchability will ensure not
including .data or .bss section, otherwise it will give 'data section
<secname> selected for inclusion' and 'unsupported section change(s)'
error.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
If a static variable is a pointer, it has rela section.
Example:
static int *p = &a;
changed to:
static int *p = &b;
so its rela section has changed.
Then this change of data should be found and report error.
But if we don't correlate its rela section, we won't
find this change.
Signed-off-by: Zhou ChengMing <zhouchengming1@outlook.com>
kpatch-build was failing on centos7 with
mv: cannot stat '/home/vagrant/rpmbuild/BUILD/kernel-*/linux-3.10.0-229.el7.x86_64': No such file or directory
in the error log. This was due to the actual directory being named
linux-3.10.0-229.el7.centos.x86_64. This patch avoids this failure by
adding a wildcard before the arch.
Signed-off-by: Louis Taylor <louis@kragniz.eu>
Bash doesn't correctly format the version string which causes the source
package to not be downloaded correctly.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
The current WARN detection logic catches the majority of cases, but
there are still a lot of outliers which it doesn't catch (thanks, gcc).
I looked at a much larger sample of WARN calls and came up with a more
generic algorithm.
The _rs variable is used for printk ratelimiting, similar to __warned,
which makes it a logical candidate to be "special": don't correlate it,
yet don't mark a function as changed just because it references it.
When patching a kernel module, if we can't find a needed dynrela symbol,
we currently assume it's exported. However, it's also possible that
it's provided by another .o in the patch module. Add support for that.
Fixes#445.
Currently unbundled section references are only replaced if the start of
the symbol is referenced. It's also useful to support replacement of
references which point to inside the symbol.
Improve the static local variable correlation logic, for the case where
a static local is used by multiple functions. For each usage of the
variable, look for a corresponding usage in the base object. If we find
at least one matching usage, consider it a twin.
Allow static locals to be used by two functions. This is possible if
the static's containing function is inlined. We only need to find one
of them to do the correlation.
The __func__ static local variable should be deemed "special", because
it doesn't need to be correlated and should be included when needed by
an include function.
I don't have a test case for F20, but this fixes the following types of
issues when doing a full-tree recompile on RHEL 7:
ERROR: cifssmb.o: object size mismatch: __func__.49322
ERROR: btmrvl_main.o: kpatch_correlate_static_local_variables: 982: static local variable __func__.44657 not used
ERROR: iwch_qp.o: .rodata.__func__.46024 section header details differ
Fixes an issue where attempting to call the shadow functions from a
module results in modpost failures:
ERROR: "kpatch_shadow_get" [net/mac80211/mac80211.ko] undefined!
ERROR: "kpatch_shadow_alloc" [net/mac80211/mac80211.ko] undefined!
LDFLAGS_MODULE is apparently not really needed.
