Fixes the following warning:
kpatch-patch-hook.c:71:2: warning: initialization from incompatible pointer type [enabled by default]
__ATTR(enabled, 0644, patch_enabled_show, patch_enabled_store);
^
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Make kpatch_funs truly internal by:
Defining it in core.c
Adding a struct kpatch_internal, declared in kpatch.h and defined in
core.c, that contains per patch module internal data.
Adding an "internal" field to struct kpatch_modules.
Allocating internal and funcs data in core.c, not in the patch module,
since the patch module has no knowledge of kpatch_func anymore.
Adding a "patch" field to kpatch_func that points directly to the
kpatch_patch provided by the module (rather than a field-by-field copy)
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Add the null symbol to in inventory files. Before the linked-link
change, the null symbol wasn't included in the inventory. However,
it is required to be a valid ELF file and should be inventoried and
check for in the test.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
The error likes:
make -C /lib/modules/3.11.0-12-generic/build M=/home/ryan/kpatch/kmod/core kpatch.ko
make[3]: Entering directory `/usr/src/linux-headers-3.11.0-12-generic'
CC [M] /home/ryan/kpatch/kmod/core/core.o
/home/ryan/kpatch/kmod/core/core.c:42:32: fatal error: linux/preempt_mask.h: No such file or directory
#include <linux/preempt_mask.h>
I feel sorry to introduce this problem from my laster commit 6c2d6444.
Some old kernel doesn't have header file preempt_mask.h, and the safe
way is using hardirq.h to find in_nmi().
Signed-off-by: Jincheng Miao <jincheng.miao@gmail.com>
Having a '.' in the kmod name confuses lsmod, which prints "Size" and
"Used by" values of -2. Prevent any special characters other than '_'
and '-', so that our patch module names will be consistent with typical
kmod names.
It's probably cleaner to just return -EINVAL if the kpmod isn't enabled,
instead of warning and continuing, which would be dangerous.
I think the reason I had it WARN before is because this condition
shouldn't be possible given the source for the patch module. But the
core module can't necessarily assume that it's our trustworthy patch
module code on the other side.
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.
In prepraration for "kpatch load --replace", reformat the usage message
to give more room for the command descriptions. Also move the
formatting logic to its own function.
