On Ubuntu Trusty, HWE kernels don't come with a linux-source
package. Use dget to retrieve the source package instead. This is not
the case anymore with Xenial as the linux-source package is also
provided for the HWE kernels. For Debian, backports always come with the
linux-source package.
* remove the Fedora release number
* add part of the $(uname -r) to kernel package specifications
* add patchutils as an optional package to satisfy kpatch-test
* update to the latest ccache rpm URL @ dl.fedoraproject.org
"kpatch replace" is complex, buggy, and probably unnecessary. And
upstream livepatch has nothing like it.
Remove it from the kpatch utility, but leave the infrastructure in place
in the patch module and the core module for now.
Fixes: #456
Change the supported Fedora version to F21 and add a new dependency.
For some reason, numactl-devel is needed by "rpmbuild -bp kernel", but
isn't detected by "yum-builddep kernel".
yumdownloader is problematic because it doesn't allow you to download
anything but the latest released kernel. It can also be slow at times.
Instead, for Fedora, download the RPMs from koji.
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>
- 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
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.
There's at least one case in the kernel (ddebug_proc_show) where the
compiled instructions are affected by the source file path given to gcc.
Which means that compiling the kernel with O= will result in many of the
function addresses changing. This causes a mismatch between the locally
compiled vmlinux and the original vmlinux, which is very dangerous,
since we need the addresses to be correct.
The easy fix is just to use the original vmlinux for all the function
addresses.
Other potential ways to fix it which we might want to consider in the
future:
- use a combination of the old System.map and the new vmlinux to find
the addresses. The function ordering should be the same. For
non-duplicate symbols, use System.map. For duplicate symbols, use
vmlinux to find what order the symbol comes in. e.g. the 2nd
occurrence of foo() in System.map. It adds a little complexity to the
lookup code, but seems safe and wouldn't require the kernel debuginfo
package. However, this may not help us for patching modules.
- do something similar at runtime, i.e. use kallsyms_lookup_name for
non-dups and kallsyms_on_each_symbol for dups, and look for the nth
occurrence of the symbol (value of n is decided at build time). This
has the complexity of the previous option but it's done at runtime
rather than build time, so... why? Doing it at build time is better.
- compile the kernel in place. This basically means no more caching
because recompiling with --function-sections causes everything to be
recompiled again. This is bad for kpatch developers' SSDs...