Previously OOT-module builds used `--sourcedir` to specify oot-module
source directory which was a bit confusing and also denied users ability
to build kpatches agains oot modules built against non-distro kernels.
This patch adds `-p/--oot-module-src` option to specify source dir for
oot module while keeping `--sourcedir` for kernel source directory
specification.
I also tried to disambiguate `SRCDIR` in kpatch-build a bit. Now there
are 3 variables:
- `KERNEL_SRCDIR` - contains path to kernel source directory
- `OOT_MODULEL_SRCDIR` - contains path to out-of-tree module source directory
- `BUILDDIR` - can be set to either of the above and is used for
patch-related actions
Another attempt at this was done by @omatiusha in #1234
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Add support for clang-built kernels. This is completely automatic, we
check if the kernel was built with clang by looking for
CONFIG_CC_IS_CLANG in config.
This has almost no effect on non-clang built kernels with one exception:
we now do compliler checks _after_ we download kernel sources which is a
waste of resources in case when compilers don't match.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
From Linux-5.1 onward, the sysfs interface to send signals to
processes stalling livepatch transitions is replace by a peridical
signal sent by the kernel.
On such systems, the kpatch signal subcommand does nothing. Just
let the user know they don't need to worry about it.
Fixes: #1151
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Added option signal to man page, under commands, based on usage function in
kpatch/kpatch usage()
Signed-off-by: Sanskriti sharma <sansharm@redhat.com>
The man page earlier said that kpatch-build only works for Fedora, but now it
works for most distros to I deleted that line.
Signed-off-by: Sanskriti Sharma <sansharm@redhat.com>
Kpatch no longer uses initrd to make sure the patch modules are loaded
at boot. The users could either install the provided systemd service
for that or come up with some other solution.
The messages mentioning initrd could confuse the users.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
"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
Right now, unless the entire gcc version string, including build date
and package version, matches the distro kernel exactly, kpatch-build
won't proceed.
For some distros, it is very difficult to rollback to a previous
version of gcc and keep that version pinned on the system so that the
package manager doesn't update it.
For these user, add a --skip-gcc-check flag to kpatch-build to allow the
version check to be skipped. If the user does this, it is assumed they
know what they are doing. This flag is documented as "not recommended".
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.
The user-installed vs system-installed dichotomy is confusing. Let's
just have "installed". RPM-installed modules can just call "kpatch
install" in their post-install step.
Allow the user to atomically replace all existing modules with a new
"kpatch replace" command. This provides a safe way to do atomic
upgrades for cumulative patch module updates.
A user may want to load a module without having to install it to the
initrd. In fact, 99% of the time I think that will be the typical usage
of "kpatch load", with a given file as an argument rather than a DB
module.
Have "kpatch load" and other commands take a file as input. If the file
is not found, then check the DB.
Try to be more consistent with the terminology. In various places we
call it a "hotpatch module", "hot patch module", or "patch module". How
about we just call it a "patch module" everywhere?
After removing the distinction between 'enabled' modules and 'applied'
modules in 022e42bc, we can change the 'apply' and 'remove' subcommands,
to more intuitive 'load' and 'unload' subcommands.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
