Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

This is a backported version of the patch from
dynup#946.

Done in the scope of https://jira.sw.ru/browse/PSBM-90264.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

This reverts commit f21efed.

https://jira.sw.ru/browse/PSBM-91809

This reverts commit 3addad0.

https://jira.sw.ru/browse/PSBM-91809

This reverts commit 190e287.

https://jira.sw.ru/browse/PSBM-91809

Add support for jump labels, also known as static jumps, static keys,
static branches, and jump tables.  Luckily,
kpatch_process_special_sections() is already generic enough to make this
an easy fix.

Fixes: dynup#931

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

https://jira.sw.ru/browse/PSBM-90264

Backported upstream commit 87c6451.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Clean up the special section array a bit, to make it a little more
readable.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

While adding proper linker script option my previous patch left the
linker script in the list of source files (on pre-4.20 kernels) for
ld somehow breaking kpatch callback sections. For this to work
properly kpatch.lds needs to be added to 'extra-y' instead of objs. And
for kbuild to process this option properly we need to call make without
the .ko target, i.e. let kbuild decide what to build.

Fixes: 17a97b4 ("kmod/patch: fix patch linking with 4.20")
Signed-off-by: Artem Savkov <asavkov@redhat.com>

Upstream: b2f40b0

eshatokhin@: adjusted the patch to work with VZ-specific version of
kmod/patch/Makefile.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

4.20 includes commit 69ea912fda74 "kbuild: remove unneeded link_multi_deps"
which changes kbuild so that only '.o' files are given to ld as targets
for linking, leaving out our linker script. Even before this commit we
were still doing this wrong and were succeeding just because ld is smart
enough to detect the script, it even throws a warning:

ld: warning: kpatch.lds contains output sections; did you forget -T?

The right thing to do is to add the script to ldflags either through
kbuilds 'ldflags-y' or by adding it to LDFLAGS/KPATCH_LDFLAGS directly.

Signed-off-by: Artem Savkov <asavkov@redhat.com>

Kernel commit 7290d5809571 "module: use relative references for
__ksymtab entries" changed kernel_symbol structure on some
architectures. Adjust kmod/core/core.c accordingly.

Signed-off-by: Artem Savkov <asavkov@redhat.com>

With dynup#755, we started using dynrelas for function pointers.  However,
this behavior only makes sense for function pointers to existing
functions.  For function pointers to *new* functions, just use a normal
rela.

The 'function-ptr-new' unit test is from the following patch:

  https://github.com/dynup/kpatch/files/1927198/new-static-callback.patch.txt

Fixes dynup#834.

Fixes: 495e619 ("kpatch-build, x86: do not use the patched functions as callbacks directly")
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

Added in the scope of https://jira.sw.ru/browse/PSBM-87678 but it fixes
a different issue in the same code of create-diff-object.

dynup#834

From the description of the issue:
--------------
If a source patch adds a global function foo() that takes a callback as
an argument, and a static function bar() that is used as such callback,
create-diff-object may fail to find bar() in some cases. Namely, - if foo()
is defined in one source file, but called in another source file where bar()
is defined.

create-diff-object complains as follows:

    base.o: new function: foo
    meminfo.o: changed function: meminfo_proc_open
    meminfo.o: new function: bar
    /usr/libexec/kpatch/create-diff-object: ERROR: meminfo.o
      kpatch_create_intermediate_sections: 2485: lookup_local_symbol bar needed
      for .text.meminfo_proc_open
    ERROR: 1 error(s) encountered.
--------------

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

It was observed by Evgenii Shatokhin in PR#755, that when the RCU
callback was called on the patched function, from unloaded livepatch
module triggered a kernel crash.

This patch implements the approach on PowerPC outlined in PR#755.
With -mcmodel=large, like any other data, function pointers are also
loaded relative to the current TOC base and are populated as
relocation entries in .toc section. Every function passing a function
pointer as the argument need to load the function address through
.toc section + offset. Convert such .toc + offset relocation into
a dynamic rela, which resolves to original function address, during
module load.

Also move the comment related to nested function check, into
may_need_dynrela().

Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Cc: Joe Lawrence <jdl1291@gmail.com>
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

https://jira.sw.ru/browse/PSBM-87678

The patch was intended for PowerPC but it did change how
create-diff-object works on x86 as well, and that should help fix
PSBM-87678.

The patch added a condition
'(rela_toc->addend == rela_toc->sym->sym.st_value)' in
function_ptr_rela(), which results in normal rela created for such
references, rather than dynrela. On x86, rela_toc->sym->sym.st_value
should be 0, because each symbol is at the offset 0 in its own section.
So function_ptr_rela() will return 0 if the a function refers to somewhere
inside this or another local function rather than to a start of a function.
Dynrelas are not meant for such relocations in the first place, normal
relas should be used. And they will be used after this patch.

Keeping the rest of the patch to simplify future rebases, etc.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

A workaroud for https://jira.sw.ru/browse/PSBM-87522, not very elegant
but should work.

Kpatch service that loads the installed patches at boot recognizes boot
option "kpatch.enable=0". If it is set, the service does not load
patches automatically.

However, modprobe finds that boot option as well and interprets it as if
it should pass "enable=0" as a parameter to kpatch.ko kernel module when
it is being loaded. The module had no such parameter and loading failed.

The bug was there since the option was introduced but it went unnoticed
until https://jira.sw.ru/browse/PSBM-87497, because the fallback path
triggered in the older kernels (those w/o livepatch support). The core
module was eventually loaded with insmod there. No such luck with
the newer kernels.

The users might depend on "kpatch.enable=0" as a way to disable
autoloading of patches, so we cannot easily rename that parameter.
Reworking the script that loads the patches to avoid modprobe may be
doable but is extremely error-prone.

Let us use a simple solution for now. modprobe wants to pass "enabled=0"
to the kpatch core module, right? Let us add such parameter in that
module and just ignore it.

Anyway, we will eventually move to livepatch and get rid of the core
module for good.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

...rather than the in-kernel Livepatch subsystem. RedHat enabled
(limited) Livepatch support in RHEL 7.5 and that messed things up with
our old-style but reliable kpatch-based patches.

Done in the scope of https://jira.sw.ru/browse/PSBM-87497.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Or, to be exact, for the kernels with CONFIG_LIVEPATCH=y.

Until Livepatch matures, it may be needed to prepare Kpatch-compatible
rather than Livepatch-compatible binary patches for the kernels where
Livepatch is available.

Currently, kpatch-build always creates Livepatch-compatible patch modules
if Livepatch is available.

This patch adds '--patch-format' option to kpatch-build, so that
"kpatch-build --patch-format=kpatch <...>" will generate
Kpatch-compatible patches unconditionally.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Currently, neither the patch modules nor Kpatch core module are able
to remove all added shadow variables when these modules are unloaded.

That is, they rely on the patched code to free the shadow variables -
however, this is not always possible/easy/safe.

Similar to livepatch in the mainline kernel, I added
kpatch_shadow_free_all() that frees all shadow variables with the given
ID ("char *var" in Kpatch API for shadow variables). It can be used when
unpatching the kernel, for example, to properly clean up the shadow
variables.

For the cases when it is needed to do something else before freeing a shadow
variable, e.g., unregister it somewhere, free some data it points to, detach
it from other lists, etc., I have also added support for destructors,
similar to the mainline commit 3b2c77d000fe ("livepatch: Allow to call a
custom callback when freeing shadow variables").

Dtors are mostly useful for kpatch_shadow_free_all(). If the patch uses
kpatch_shadow_free() to clean up an individual shadow variable, it can
call kpatch_shadow_get() and do the cleanup before free. I also added a
convenience function kpatch_shadow_free_with_dtor() for such cases.

This commit keeps the ABI of the core module backward compatible (for
ABI > 0.3).

https://jira.sw.ru/browse/PSBM-83626

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

…he patch

If a function that schedules an RCU callback is patched as well as the
callback itself, care should be taken. It might be possible that the
original function has scheduled the callback then the patch is loaded
and the patched variant of the callback gets executed. Similar problems
may arise when unloading the patch.

This inconsistency may lead to problems.

In case we have not detected this when preparing the patch, let us wait
till all pending RCU callbacks complete before trying to apply or remove
the patch.

The small race window remains though between the end of rcu_barrier() and
the activeness safety check in register/unregister, when RCU callbacks
can still be scheduled. So, this does not fix the problem but rather
makes it less likely to show up.

N.B. Why not patch the core module instead? Because we cannot reliably
update the core module once it is loaded and there are patches depending
on it.

Done in the scope of https://jira.sw.ru/browse/PSBM-83362.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

… code

Commit 7770c18 ("kpatch-build: Fix the logfile checks for
'undefined'") actually broke kpatch-build, see
dynup#783

We hit this with the fix for CVE-2016-7097, where posix_acl_update_mode()
function was added in vmlinux and used in ext4 module.

The fix is being worked on upstream and its current version seems rather
complex.

For now, let us disable these checks so that everything would work as
before (they were effectively no-ops before).

The worst that could happen is that the patch module tried to call a
non-exported non-patches function and failed to load. We always test
loading of the patch modules before shipping them, so this is not a big
deal of a problem.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

In kpatch 0.5, 'kpatch list' has a slightly different output format than
it had in v0.3: it also shows patch state (enabled/disabled/...) and the
list of stalled processes (livepatch modules only).

Example:

v0.3:
  $ kpatch list
  Loaded patch modules:
  kpatch_cumulative_45_0_r1

  Installed patch modules:
  kpatch_cumulative_45_0_r1 (3.10.0-514.26.1.vz7.33.22)
  kpatch_cumulative_45_0_r1 (3.10.0-693.11.6.vz7.40.4)

v0.5:
  $ kpatch list
  Loaded patch modules:
  kpatch_cumulative_45_0_r1 [enabled]

  Installed patch modules:
  kpatch_cumulative_45_0_r1 (3.10.0-514.26.1.vz7.33.22)
  kpatch_cumulative_45_0_r1 (3.10.0-693.11.6.vz7.40.4)

This output is actually a part of a public API now and I cannot say
which tools have come to rely on it.

Let us play safer and use the same output format as before by default.
If patch state is needed, one can now execute  'kpatch list' with
-s|--show-state option.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

If no patches are loaded, "kpatch replace" failed with weird errors,
like this:

  cat: /sys/kernel/kpatch/*/enabled: No such file or directory
  kpatch: patch module kpatch_0.5.0_1.vl7.x86_64.rpm is not loaded

The root cause is that 'for module in "$SYSFS"/*' loops still do one
iteration in that case, with module == "/sys/kernel/kpatch/*",
hence '*' in some places, etc.

I fixed it the same way as it is done in the rest of the script. While
at it, I added the same fix to get_transition_patch() as well. Not sure
if it is really needed there but won't hurt.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Fixes: 270f5f0 ("Use atomic replace only when upgrading
official cumulative patches")

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

It seems, there is a bug in atomic replace patchsets v5 - v9. If a
loaded but disabled patch is present, trying to load a new patch using
atomic replace will fail with "Device or resource busy".

https://lkml.org/lkml/2018/3/5/229

As a workaround, unload all disabled patch modules before atomic
replace.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Support for patch/unpatch callbacks was added to livepatch in the kernel
4.15 but vzkernel 4.14 has that functionality backported. Let us allow
using it here.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Upstream 4.15 kernels provide support for pre and post (un)patch
callbacks, inspired by the kpatch load hooks.  Add support for them in
the livepatch-patch-hook.

Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>

[eshatokhin@]:
* Made kpatch_*_data static. Marked them with '__used' to prevent the
compiler from optimizing them away.
* Updated kpatch_include_hook_elements() to use hook_sections[] only,
as suggested in PR dynup#780.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Atomic replacement of the binary patches results in non-obvious
behaviour w.r.t. patch/unpatch callbacks (hooks in the "old" kpatch).
That is, when patch1 is atomically replaced with patch2, the unpatch
callbacks from patch1 will not be called. It looks like this will remain
this way, see the details below:

* for the "old" kpatch: dynup#456
* for livepatch: https://lkml.org/lkml/2018/1/31/642

We do need atomic replace in ReadyKernel and we might need patch/unpatch
callbacks in some patches. Without the guarantee that unpatch callbacks
will be called, we'll have to be careful when using them. If these
callbacks are used to clean up something that other callbacks have done,
the last patch to unload must do all cleaning up. This should work if we
are only replacing our cumulative ReadyKernel patch with a newer
version and that version is aware of all previous versions, what is
needed to clean up there. However, things become rather difficult if we
try to downgrade the patch (the older patch is unlikely to know what
needs cleaning up for the newer patch) or when dealing with some
unifficial or non-cumulative patches (for the same reason as for
downgrade).

To sort out this mess somehow, I have rewritten "kpatch replace" command
so that atomic replace will only be used to replace an official
cumulative ReadyKernel patch with a newer version. This is the most
common case and if we decide to use callbacks in ReadyKernel patches, we
will be able to design these callbacks accordingly.

In all other cases, atomic replace is not used, the previous patches are
disabled first, then the new patch is loaded normally. The unpatch callbacks
will be called for the previous patches, then patch callbacks will be
called for the new patch. This should be OK.

So, "kpatch replace" now works as follows:

1. If one tries to use "kpatch replace" to load a non-official or a
non-cumulative patch  (this is currently detected by the names of
patch modules), all currently loaded patches are disabled first. Then
the new patch is loaded normally.

2. If one tries to load an official cumulative patch, all loaded patches
except the official cumulative patches with smaller version-release are
disabled first. Then atomic replace is used.

If the new patch fails to load, the previously disabled patches will
remain disabled. If it was not a patch upgrade operation, the system
would end up having no active binary patches at all. Far from ideal but
the risk seems acceptable. Downgrade and operations with non-official
patches should be rare anyway.

I reiterate: if the patch is upgraded, everything should work as
before. If "kpatch replace" succeeds, the new patch will be loaded and
active. Otherwise the older patch will remain loaded and active.

By the way, all this complexity indicates that we should consider using
callbacks in the most important fixes only and only if there is no other
acceptable way to provide a fix.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Similar to "atomic replace" support in the old Kpatch core, this commit adds
parameter "replace" to the patch modules. If the module is loaded with
"replace=1", it will ask the livepatch core to replace all enabled
patches with this patch atomically. That is, either the new patch is
loaded and active after the replace operation or the older patches remain
active (if the replacement has failed).

This relies on "atomic replace" support in the kernel. At the time of
this writing, it is not merged yet. v8 of the patches is available here:
https://lkml.org/lkml/2018/2/21/518

Once these patches get into the mainline kernel, support for replace
could be added upstream to kpatch tools as well. Let us add it now for
VZ. We can revert this commit later and add the upstream implementation
once it is available.

Note that building of a livepatch module will fail right now if the
kernel does not support "atomic replace".

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Commit c0105ea "kpatch-build: set default module prefix accordingly"
changed the prefix of livepatch-based patch modules to "livepatch-".

Our tools might still rely on the patch module names like
"kpatch_cumulative_something", so let us use "kpatch-" prefix for all
patch modules again.

A common prefix would also simplify the implementation of patch upgrade
and downgrade if we decide to parse the name of the patch there to get
the version, etc.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

…ctly

A kernel crash happened in __do_softirq() in very rare cases when the
binary patch created from mainline commit be82485fbcbb
("netlink: fix an use-after-free issue for nlk groups") was unloaded.

Investigation has shown that the kernel tried to execute an RCU
callback, deferred_put_nlk_sk(), defined in the patch module after the
module had been unloaded.

The callback was set by the patched variant of netlink_release() and
the address of the patched deferred_put_nlk_sk() was used, rather than
the address of the original function.

Similar problems occur with workqueue functions as well.

As suggested in
dynup#755 (comment),
create-diff-object was modified so that the addresses of the original
functions were used in such situations, at least for x86 systems. A
similar fix for PowerPC was added as well.

Changes in v4:

* '#ifdef __x86_64__' was removed. It is not actually needed right now
because the constants for relocation types are different on different
architectures.

Changes in v3:

* Minor refactoring and a comment explaining what this all is about.
Quite lengthy, but the dynrela-related code is really far from obvious.

Changes in v2:

* Handle the nested functions the same way as before, because they are
unlikely to be used as asynchronous callbacks. Example: cmp() in
bch_cache_show() from drivers/md/bcache/sysfs.c in the kernel 4.4.

As the nested functions are local to the functions they are defined in,
the compiler names them in a similar way to static locals: <name>.<number>.
Currently, we filter out all functions with '.' in their names. If there
are any asynchronous callbacks in the kernel that have a dot in their
names too, they could be handled in the future patches. It is unclear
though, if the callbacks with such names can appear in the kernel.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

No need to keep a copy of the original Readme.md from
https://github.com/dynup/kpatch. It may be confusing for the users of
VZ7.

Just some basic info and the link to the upstream project should be
enough.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

The following events are logged for the patches: load, replace, unload.
Each line is for a single event. Format:
{timestamp} {event} {patch_module_name} {kernel_version} {result} [message]
  timestamp: see 'date --iso-8601=seconds'
  event: LOAD|UNLOAD|REPLACE
  kernel_version: see 'uname -r'
  result: SUCCESS|FAIL
  message: optional comment message, may provide the details of what
           happened.

The fields except 'message' do not contain spaces and are
space-separated. 'message' may contain spaces.

Example records:
2016-05-10T15:55:07+0300 LOAD kpatch_cumulative_0_4_r13 3.10.0-327.10.1.vz7.12.7 SUCCESS
2016-05-10T16:19:11+0300 UNLOAD kpatch_cumulative_0_4_r12 3.10.0-327.10.1.vz7.12.7 FAIL Failed to disable patch.

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

v2:
This is a different implementation of logging than is used in kpatch 0.3.4
for VZ7. The format of the log records is the same though.

I reused die() and globals to make the patch less invasive. It
also handles failures reported not only by load_module() and
unload_module() directly but also by the functions they call.

Saving the current context in log_event_prev helps when unload_module()
is called from load_module, for example. Luckily, unload_module() cannot
call load_module() again, so a single variable log_event_prev is enough
to keep the previous context.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

This partially reverts the following commit (except the changes in Readme,
which are OK):
-----------
commit 8e8de47
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Mon Nov 16 09:38:38 2015 -0600

    kpatch: deprecate the replace command

    "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: dynup#456
-----------

'kpatch replace' is crucial when one mostly uses cumulative patches, i.e.
the patches that provide all the needed fixes in a single patch module.

It is very important to update such patches safely. That is, either the
new patch should be active after the update (if it succeeds) or the old one
should be used (if the update fails). Unloading of the old patch and then
loading the new one is more fragile because loading could fail and the
system would be left without patches at all.

The recommended workaround was to make sure the newer patch is a superset
of the old one. To be exact, the set of functions changed by the newer patch
should include all the functions changed by the older one. This is not
always possible even when one does not remove fixes from the patch.

By the way, "atomic replace" has been proposed for livepatch as well:
https://lkml.org/lkml/2018/2/6/152

The only issue with 'kpatch replace' I know about at the moment is
dynup#456:
"hook unload function doesn't run when module is replaced".

The current implementation of "atomic replace" for livepatch has the same
issue, by the way. It seems, it is difficult to resolve properly at the
kernel side. However, if the patches need load/unload hooks (callbacks),
we could probably design these callbacks in our cumulative patched according
to the current behaviour of Kpatch/livepatch core. Then, upgrade of our
patches would work properly. Downgrade (replacement with a previous version)
could be implemented as unload + load, it should be a rare operation anyway.

ReadyKernel currently uses kpatch 0.3.4 with a number of changes
compared to the upstream version of kpatch. Some of these changes affect
ABI of the core module (kpatch.ko), e.g. my commit 23038e4ea7e
"Allow for extension of Kpatch-related structures in the future".

The upstream kpatch also changed the ABI by changing the main structures
in commit 0bb5c10 "kmod: restructure kpatch sysfs tree".

The patch modules and the core module for a given kernel must be built
using the same ABI, otherwise the patch module will fail to load, at
best.

It will be needed to rebase on top of the upstream kpatch eventually.

I'd also like not to make maintenance of kpatch tools more difficult
than it should be. Keeping several variant of the tools for different
kernel versions seems to be a real path to a maintenance nightmare.

The best solution I could come up with is to make the build process of
the core module and the patches ABI-aware and keep everything necessary
to support all ABIs we need. The variants of kmod/core/core.c,
kmod/core/kpatch.h, kmod/patch/kpatch.h kmod/patch/kpatch-patch-hook.c
are kept alongside the original sources. "-0.3" is for ABI "0.3", that
is, for the cases when it is needed to be compatible with kpatch 0.3.x
from VZ7.

This scheme should also make it easier to add patches from upstream (for
kpatch with the newer ABI) when needed, because the sources have the
same names.

The makefiles for kpatch.ko and the patch modules will now replace
core.c, kpatch.h and such with the needed versions right before the build
and will restore them to the previous state after that. A downside is
that, if one needs to debug these kernel modules, one should get the
correct sources first. Not a big deal, it seems.

So,

* kpatch.ko will now be built using the newest ABI by default. To build
it for the older ABI "0.3", pass KPATCH_ABI_COMPATIBLE=0.3 to 'make'
explicitly. The spec files for kpatch-kmod packages have been updated to
do just that.

* When building the patch modules, kpatch-build will use
the KPATCH_ABI_COMPATIBLE environment variable as the desired ABI
version. If unset, the newest ABI will be used. For example, to build
the patch modules compatible with ABI "0.3", one can do the following:
  export KPATCH_ABI_COMPATIBLE=0.3
  kpatch-build <...as usual...>
-----------

Done in the scope of https://jira.sw.ru/browse/PSBM-79803.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

Two files are now created in debugfs: kpatch/fail_apply and
kpatch/fail_remove. They can be used to simulate the conditions when the
patch fails to be applied or removed, respectively, because the
functions to be patched are in use.

May be helpful for testing.

Although TAINT_LIVEPATCH and TAINT_USER are not considered errors by the
tests, add_taint() dumps the backtrace to the kernel log, which may
confuse users.

Let us not taint the kernel in kpatch.ko (livepatch is a different story).
It should be already clear from dmesg that the patch modules are loaded,
even without the taint.

Increased these to 16 (attempts) and 10 (seconds), respectively, to match
what ReadyKernel uses now for the kernels 3.10.0-x.

Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>

If kpatch fails to disable a patch, retry a few times