On Wed, May 07, 2014 at 02:24:44PM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
Ah this reminds me when we chased kprobes dangerous spots and we
tried to declare __kprobes the functions which were too dangerous
to hot patch.
We eventually gave up
On Wed, May 07, 2014 at 05:57:54PM +0200, Ingo Molnar wrote:
Live patching does not enter into this question, ever. The correctness
of a patch to the source does not depend on 'live patching'
considerations in any way, shape or form.
Any mechanism that tries to blur these lines is broken
On Thu, May 08, 2014 at 09:08:15AM +0200, Ingo Molnar wrote:
* David Lang da...@lang.hm wrote:
On Thu, 8 May 2014, Ingo Molnar wrote:
No!
A patch to the kernel source is 'safe' if it results in a correctly
patched kernel source. Full stop!
Live patching does not enter
On Tue, Jun 10, 2014 at 10:50:01AM +, Masami Hiramatsu wrote:
Hi,
Here is a pair of patches which introduces IPMODIFY flag for
ftrace_ops to detect conflicts of ftrace users who can modify
regs-ip in their handler.
Currently, only kprobes can change the regs-ip in the handler,
but
On Thu, Jun 12, 2014 at 02:44:35PM +0900, Masami Hiramatsu wrote:
(2014/06/12 1:58), Josh Poimboeuf wrote:
On Tue, Jun 10, 2014 at 10:50:01AM +, Masami Hiramatsu wrote:
Hi,
Here is a pair of patches which introduces IPMODIFY flag for
ftrace_ops to detect conflicts of ftrace users
On Thu, Jun 12, 2014 at 12:28:53PM +0900, Namhyung Kim wrote:
Hi Josh,
On Wed, 11 Jun 2014 11:58:26 -0500, Josh Poimboeuf wrote:
On Tue, Jun 10, 2014 at 10:50:01AM +, Masami Hiramatsu wrote:
Hi,
Here is a pair of patches which introduces IPMODIFY flag for
ftrace_ops to detect
On Tue, May 20, 2014 at 11:37:16AM +0200, Jiri Kosina wrote:
On Fri, 16 May 2014, Josh Poimboeuf wrote:
Consider this scenario:
void foo()
{
for (i=0; i1; i++) {
bar(i);
something_else(i
On Fri, May 16, 2014 at 06:27:27PM +0200, Jiri Kosina wrote:
On Tue, 6 May 2014, Steven Rostedt wrote:
However, I also think if users can accept such freezing wait-time,
it means they can also accept kexec based checkpoint-restart patching.
So, I think the final goal of the kpatch will
is removed.
- kretprobes removes the probed function's calling function's IP
from the stack, which could lead to a false negative in the kpatch
backtrace safety check.
[1] http://thread.gmane.org/gmane.linux.kernel/1694304
[2] https://github.com/dynup/kpatch
Josh Poimboeuf (2
(thanks to Masami
for helping with this)
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Seth Jennings sjenn...@redhat.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
Documentation/kpatch.txt | 193 +++
MAINTAINERS | 9 +
arch/Kconfig | 14
Add a TAINT_KPATCH flag to be set whenever a kpatch patch module
successfully replaces a function.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Seth Jennings sjenn...@redhat.com
---
Documentation/oops-tracing.txt | 3 +++
Documentation/sysctl/kernel.txt | 1 +
include/linux/kernel.h
On Thu, May 01, 2014 at 01:45:33PM -0700, Andi Kleen wrote:
Josh Poimboeuf jpoim...@redhat.com writes:
kpatch checks the backtraces of all tasks in stop_machine() to ensure
that no instances of the old function are running when the new function
is applied.
How does that work for tail
On Thu, May 01, 2014 at 11:06:01PM +0200, Andi Kleen wrote:
When bar returns, would it skip foo and go straight back to foo's
caller? If so, then it should be safe to patch foo after it jumps to
bar.
foo is no problem, you see it in the backtrace.
But you don't see bar.
Sorry, I missed
On Thu, May 01, 2014 at 04:27:46PM -0500, Josh Poimboeuf wrote:
On Thu, May 01, 2014 at 11:06:01PM +0200, Andi Kleen wrote:
When bar returns, would it skip foo and go straight back to foo's
caller? If so, then it should be safe to patch foo after it jumps to
bar.
foo is no problem
On Fri, May 02, 2014 at 10:37:53AM +0200, Jiri Kosina wrote:
On Thu, 1 May 2014, Josh Poimboeuf wrote:
Since Jiri posted the kGraft patches [1], I wanted to share an
alternative live patching solution called kpatch, which is something
we've been working on at Red Hat for quite a while
On Fri, May 02, 2014 at 03:10:58PM +0200, Jiri Kosina wrote:
On Thu, 1 May 2014, Josh Poimboeuf wrote:
kpatch vs kGraft
I think the biggest difference between kpatch and kGraft is how they
ensure that the patch is applied atomically and safely.
kpatch checks
On Mon, May 05, 2014 at 10:55:37AM +0200, Ingo Molnar wrote:
* Josh Poimboeuf jpoim...@redhat.com wrote:
[...]
kpatch checks the backtraces of all tasks in stop_machine() to
ensure that no instances of the old function are running when the
new function is applied. I think
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
If a kernel refuses to patch with certain threads running, that will
drive those kernel threads being fixed and such. It's a deterministic,
recoverable,
On Mon, May 05, 2014 at 06:59:29PM -0700, David Lang wrote:
On Tue, 6 May 2014, Jiri Kosina wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
function in
On Tue, May 06, 2014 at 09:32:28AM +0200, Ingo Molnar wrote:
* Jiri Kosina jkos...@suse.cz wrote:
On Mon, 5 May 2014, David Lang wrote:
how would you know that all instances of the datastructure in memory
have= been touched? just because all tasks have run and are outside the
On Tue, May 06, 2014 at 04:05:21PM +0200, Frederic Weisbecker wrote:
On Tue, May 06, 2014 at 07:12:11AM -0500, Josh Poimboeuf wrote:
On Mon, May 05, 2014 at 11:49:23PM +0200, Frederic Weisbecker wrote:
On Mon, May 05, 2014 at 08:43:04PM +0200, Ingo Molnar wrote:
If a kernel refuses
On Thu, Jul 03, 2014 at 04:07:50PM -0400, Steven Rostedt wrote:
[ NOT READY FOR INCLUSION! ]
Note, this is based off of my remove ftrace_start/stop() patch set.
I've been wanting to do this for years, and just never gotten around to it.
But with all this talk of kpatch and kgraft live
On Thu, Jul 10, 2014 at 11:44:43PM +0200, Jiri Kosina wrote:
On Thu, 10 Jul 2014, Josh Poimboeuf wrote:
I did some testing with kpatch and I found one minor issue. The dynamically
allocated trampoline seems to confuse dump_stack() somewhat.
I added a dump_stack() call in my ftrace_ops
951d2aec17885a62905df6b910dc705d99c63993 Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf jpoim...@redhat.com
Date: Fri, 11 Jul 2014 08:58:33 -0500
Subject: [PATCH] x86/dumpstack: fix stack traces for generated code
If a function in the stack trace is dynamically generated, for example an
ftrace dynamically
On Tue, Jun 17, 2014 at 11:04:36AM +, Masami Hiramatsu wrote:
Hi,
Here is the version 2 of the series of patches which introduces
IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
who can modify regs-ip in their handler.
In this version, I fixed some bugs in previous
On Thu, Jun 19, 2014 at 02:03:31PM +0900, Masami Hiramatsu wrote:
(2014/06/19 11:08), Josh Poimboeuf wrote:
On Tue, Jun 17, 2014 at 11:04:36AM +, Masami Hiramatsu wrote:
Hi,
Here is the version 2 of the series of patches which introduces
IPMODIFY flag for ftrace_ops to detect
Add a TAINT_KPATCH flag to be set whenever a kpatch patch module
successfully replaces a function.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Seth Jennings sjenn...@redhat.com
---
Documentation/oops-tracing.txt | 3 +++
Documentation/sysctl/kernel.txt | 1 +
include/linux/kernel.h
Jennings
- Masami Hiramatsu
- Jincheng Miao
- Jan Stancek
- Gaetan Trellu
[1] https://github.com/dynup/kpatch
Josh Poimboeuf (2):
kpatch: add TAINT_KPATCH flag
kpatch: add kpatch core module
Documentation/kpatch.txt| 209
Documentation/oops-tracing.txt |3
- ability to force skip the activeness safety stack check for a given function
- kpatch_[register|unregister] are properly synchronized with
kpatch_ftrace_handler() when it runs in NMI context (thanks to Masami
for helping with this)
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
Cc: Seth
On Tue, Jul 15, 2014 at 07:30:38PM +0200, Xypron wrote:
Hello Josh,
being able to patch a live kernel is very interesting feature. I looked
through you patch and some questions remained:
In Documentation/kpatch.txt I found no description on how an out of kernel
program uses the new code.
On Wed, Jul 02, 2014 at 08:30:02AM -0400, Tejun Heo wrote:
Hello,
On Wed, Jul 02, 2014 at 02:04:38PM +0200, Jiri Slaby wrote:
On 06/25/2014 01:05 PM, Jiri Slaby wrote:
...
https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/log/?h=kgraft
Stephen,
may I ask you to
On Fri, Aug 08, 2014 at 08:05:13PM +0900, Masami Hiramatsu wrote:
Ping?
For the series:
Tested-by: Josh Poimboeuf jpoim...@redhat.com
BTW, I'd like to add this testcase if ftracetest is accepted.
Thank you,
(2014/07/28 14:22), Masami Hiramatsu wrote:
Hi,
Here is the 4th version
On Tue, Oct 21, 2014 at 05:48:30PM +0200, Jiri Kosina wrote:
Add a function that allows external users (such as live patching
mechanisms) to check whether a given function (identified by symbol name)
has a kprobe installed in it.
Functions aren't uniquely identifiable by name. Perhaps it
On Tue, Oct 21, 2014 at 10:19:30PM +0200, Jiri Kosina wrote:
On Tue, 21 Oct 2014, Josh Poimboeuf wrote:
Add a function that allows external users (such as live patching
mechanisms) to check whether a given function (identified by symbol name)
has a kprobe installed
On Tue, Oct 21, 2014 at 11:25:56PM +0200, Jiri Kosina wrote:
On Tue, 21 Oct 2014, Josh Poimboeuf wrote:
This is a rather difficult call actually. I am of course aware of the
fact
that kernel fucntions can't be uniquely identified by name, but when
thinking about this, one has
On Tue, Nov 18, 2014 at 01:47:46PM +0100, Petr Mladek wrote:
On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
It'd be mostly based on your refcounting code, including stack
checking (when a process sleeps, counter gets
On Sun, Nov 16, 2014 at 07:29:23PM -0600, Seth Jennings wrote:
+static int lpc_module_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+ struct module *mod = data;
+ struct lpc_patch *patch;
+ struct lpc_object *obj;
+
+
On Thu, Nov 20, 2014 at 02:10:33PM +0100, Miroslav Benes wrote:
On Sun, 16 Nov 2014, Seth Jennings wrote:
This commit introduces code for the live patching core. It implements
an ftrace-based mechanism and kernel interface for doing live patching
of kernel and kernel module functions.
On Fri, Nov 21, 2014 at 03:44:35PM +0100, Miroslav Benes wrote:
On Fri, 21 Nov 2014, Jiri Kosina wrote:
[...]
[ ... snip ... ]
+static int klp_init_patch(struct klp_patch *patch)
+{
+ int ret;
+
+ mutex_lock(klp_mutex);
+
+ /* init */
+ patch-state = LPC_DISABLED;
On Fri, Nov 21, 2014 at 01:22:33AM +0100, Jiri Kosina wrote:
On Thu, 20 Nov 2014, Seth Jennings wrote:
--- /dev/null
+++ b/kernel/livepatch/Kconfig
@@ -0,0 +1,18 @@
+config ARCH_HAVE_LIVE_PATCHING
+ boolean
+ help
+ Arch supports kernel live patching
+
+config
On Fri, Nov 21, 2014 at 04:27:57PM +0100, Jiri Kosina wrote:
On Fri, 21 Nov 2014, Josh Poimboeuf wrote:
I think we can use depends on HAVE_FENTRY to accomplish this, since
CC_USING_FENTRY gets set by the top level kernel Makefile if
CONFIG_HAVE_FENTRY is set.
The problem
On Mon, Nov 24, 2014 at 12:13:20PM +0100, Thomas Gleixner wrote:
On Thu, 20 Nov 2014, Seth Jennings wrote:
This commit introduces code for the live patching core. It implements
an ftrace-based mechanism and kernel interface for doing live patching
of kernel and kernel module functions.
On Sat, Nov 08, 2014 at 09:07:54AM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:53PM -0600, Josh Poimboeuf wrote:
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
On Mon, Nov 10, 2014 at 11:08:00AM +0100, Jiri Kosina wrote:
On Thu, 6 Nov 2014, Seth Jennings wrote:
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
new file mode 100644
index 000..b32dbb5
--- /dev/null
+++ b/kernel/livepatch/core.c
[ ... snip ... ]
On Tue, Nov 11, 2014 at 10:05:05AM +0100, Vojtech Pavlik wrote:
On Mon, Nov 10, 2014 at 11:09:03AM -0600, Josh Poimboeuf wrote:
But there are a few (probably much less than 10%) cases like the locking
one I used above, where SWITCH_THREAD just isn't going to cut it and for
those I would
On Thu, Nov 13, 2014 at 11:16:00AM +0100, Miroslav Benes wrote:
Hi,
thank you for the first version of the united live patching core.
The patch below implements some of our review objections. Changes are
described in the commit log. It simplifies the hierarchy of data
structures,
On Tue, Dec 23, 2014 at 01:46:07AM -0800, Christoph Hellwig wrote:
On Mon, Dec 22, 2014 at 08:52:02PM +0100, Jiri Kosina wrote:
Hi Stephen,
a substantial amount of work has been invested into abstracing Live
Patching core functionality out of the already existing implementations,
so
Fix a few typos in the livepatch-sample.c usage example comments and add
some whitespace to make the comments a little more legible.
Reported-by: Udo Seidel udosei...@gmx.de
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
samples/livepatch/livepatch-sample.c | 6 +-
1 file changed, 5
On Wed, Nov 26, 2014 at 10:18:24AM +0100, Jiri Kosina wrote:
On Wed, 26 Nov 2014, Masami Hiramatsu wrote:
Note to Steve:
Masami's IPMODIFY patch is heading for -next via your tree. Once it
arrives,
I'll rebase and make the change to set IPMODIFY. Do not pull this for
-next
Hi Miroslav,
Just addressing one of your comments below. I'll let Seth respond to
the others :-)
On Wed, Nov 26, 2014 at 03:19:17PM +0100, Miroslav Benes wrote:
+/**
+ * struct klp_func - function structure for live patching
+ * @old_name: name of the function to be patched
+ *
On Wed, Nov 26, 2014 at 06:00:54PM +0900, Masami Hiramatsu wrote:
(2014/11/26 2:15), Seth Jennings wrote:
Note to Steve:
Masami's IPMODIFY patch is heading for -next via your tree. Once it
arrives,
I'll rebase and make the change to set IPMODIFY. Do not pull this for -next
yet. This
On Thu, Dec 11, 2014 at 12:17:33PM +0100, Petr Mladek wrote:
On Wed 2014-12-10 09:25:06, Josh Poimboeuf wrote:
On Wed, Dec 10, 2014 at 11:11:47AM +0100, Petr Mladek wrote:
On Tue 2014-12-09 12:32:49, Josh Poimboeuf wrote:
But livepatch isn't a module, it's part of the kernel.
Ah, I
On Fri, Dec 12, 2014 at 05:58:19PM +0100, Miroslav Benes wrote:
Hi,
I think we are really close (or I hope so). I found few suspicious things
or nitpicks though. They might have applied also to v5, but I didn't
manage to look at that. Sorry about that.
On Wed, 10 Dec 2014, Josh
On Thu, Nov 06, 2014 at 10:20:49AM -0600, Seth Jennings wrote:
On Thu, Nov 06, 2014 at 04:11:37PM +0100, Jiri Kosina wrote:
On Thu, 6 Nov 2014, Seth Jennings wrote:
+/
+ * dynamic relocations (load-time linker)
+
On Thu, Nov 06, 2014 at 10:57:48AM -0600, Seth Jennings wrote:
On Thu, Nov 06, 2014 at 04:51:02PM +0100, Jiri Slaby wrote:
On 11/06/2014, 03:39 PM, Seth Jennings wrote:
+/* must be called with lpc_mutex held */
+static int lpc_enable_patch(struct lpc_patch *patch)
The question I want
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
So there are two ways to use this live patching API: using a generated
module (e.g., using the kpatch-build
On Thu, Nov 06, 2014 at 02:49:26PM -0500, Steven Rostedt wrote:
On Thu, 6 Nov 2014 13:34:33 -0600
Josh Poimboeuf jpoim...@redhat.com wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 07:51:57PM +0100, Vojtech Pavlik wrote:
I don't think this specific example was generated.
I also don't think including the
On Thu, Nov 06, 2014 at 11:20:48PM +0100, Jiri Kosina wrote:
On Thu, 6 Nov 2014, Seth Jennings wrote:
Thanks a lot for having started the work on this!
We will be reviewing it carefully in the coming days and will getting
back
to you (I was surprised to see that that diffstat
On Fri, Nov 07, 2014 at 01:48:45PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 06:31:54AM -0600, Josh Poimboeuf wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
On Thu, Nov 06, 2014 at 10:58:57AM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014
On Thu, Nov 06, 2014 at 11:47:45PM -0800, Christoph Hellwig wrote:
On Thu, Nov 06, 2014 at 09:24:23PM +0100, Vojtech Pavlik wrote:
One reason is that there are currently at least two generators using
very different methods of generation (in addition to the option of doing
the patch module
On Fri, Nov 07, 2014 at 02:13:37PM +0100, Jiri Kosina wrote:
On Fri, 7 Nov 2014, Josh Poimboeuf wrote:
Also, lpc_create_object(), lpc_create_func(), lpc_create_patch(),
lpc_create_objects(), lpc_create_funcs(), ... they all are pretty much
alike, and are asking for some kind
On Fri, Nov 07, 2014 at 03:04:58PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 07:11:53AM -0600, Josh Poimboeuf wrote:
2. Add consistency model(s) (e.g. kpatch stop_machine, kGraft per-task
consistency, Masami's per task ref counting)
I have given some thought
On Fri, Nov 07, 2014 at 07:21:03PM +0100, Petr Mladek wrote:
On Thu 2014-11-06 10:57:48, Seth Jennings wrote:
On Thu, Nov 06, 2014 at 04:51:02PM +0100, Jiri Slaby wrote:
On 11/06/2014, 03:39 PM, Seth Jennings wrote:
+/*
+ * Core structures
+
On Fri, Nov 07, 2014 at 06:39:03PM +0100, Petr Mladek wrote:
On Thu 2014-11-06 08:39:08, Seth Jennings wrote:
This commit introduces code for the live patching core. It implements
an ftrace-based mechanism and kernel interface for doing live patching
of kernel and kernel module functions.
On Fri, Nov 07, 2014 at 10:27:35PM +0100, Vojtech Pavlik wrote:
On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
LEAVE_FUNCTION
LEAVE_PATCHED_SET
LEAVE_KERNEL
SWITCH_FUNCTION
SWITCH_THREAD
SWITCH_KERNEL
Now with those definitions
.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 0004a71..bdd99975 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -640,7
On Wed, Dec 17, 2014 at 10:21:47AM -0600, Josh Poimboeuf wrote:
On Tue, Dec 16, 2014 at 11:58:17AM -0600, Seth Jennings wrote:
Changelog:
Thanks for all the feedback!
I think that we have something that is workable for everyone now. Barring
functional defects, I think we should put
-by: Li Bin huawei.li...@huawei.com
---
arch/x86/include/asm/livepatch.h |5 +
kernel/livepatch/core.c |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
Acked-by: Josh Poimboeuf jpoim...@redhat.com
--
Josh
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Dec 22, 2014 at 06:34:09PM +0100, Petr Mladek wrote:
On Fri 2014-12-19 10:43:35, Petr Mladek wrote:
On Thu 2014-12-18 09:49:35, Josh Poimboeuf wrote:
On Thu, Dec 18, 2014 at 08:55:21PM +0900, Masami Hiramatsu wrote:
(2014/12/17 2:58), Seth Jennings wrote:
changes in v7
gathering acks so that we are in a position to go into
-next when the 3.19 window closes.
Also, I don't think patches 1/3 and 3/3 have changed since v5, so if you
reviewed
them then, they haven't changed.
For the set:
Reviewed-by: Josh Poimboeuf jpoim...@redhat.com
--
Josh
--
To unsubscribe from
On Mon, Dec 01, 2014 at 02:31:35PM +0100, Miroslav Benes wrote:
On Wed, 26 Nov 2014, Josh Poimboeuf wrote:
Hi Miroslav,
Just addressing one of your comments below. I'll let Seth respond to
the others :-)
On Wed, Nov 26, 2014 at 03:19:17PM +0100, Miroslav Benes wrote
On Fri, Dec 05, 2014 at 06:55:04PM +0100, Jiri Slaby wrote:
On 12/04/2014, 04:53 PM, Seth Jennings wrote:
...
--- /dev/null
+++ b/kernel/livepatch/core.c
@@ -0,0 +1,902 @@
...
+static struct kobj_type klp_ktype_patch = {
+ .sysfs_ops = kobj_sysfs_ops,
+ .default_attrs =
On Tue, Dec 09, 2014 at 07:05:02PM +0100, Petr Mladek wrote:
klp_patch_enable() and klp_patch_disable() should check the current state
of the patch under the klp_lock. Otherwise, it might detect that the operation
is valid but the situation might change before it takes the lock.
Hi Petr,
On Tue, Dec 09, 2014 at 07:05:07PM +0100, Petr Mladek wrote:
The situation with variables storing the address of the old and new code
is not ideal. One is called func and the other is called addr.
The one is pointer and the other is unsigned long. It makes sense
from the point of how the
On Tue, Dec 09, 2014 at 07:05:06PM +0100, Petr Mladek wrote:
This patch makes it clear what initialization and freeing steps need to be
done
when an object (module) is being loaded or removed. It will help to maintain
the module coming and going handlers. Also it will remove duplicated
code
On Wed, Dec 10, 2014 at 11:11:47AM +0100, Petr Mladek wrote:
On Tue 2014-12-09 12:32:49, Josh Poimboeuf wrote:
On Tue, Dec 09, 2014 at 07:05:02PM +0100, Petr Mladek wrote:
klp_patch_enable() and klp_patch_disable() should check the current state
of the patch under the klp_lock. Otherwise
On Wed, Dec 10, 2014 at 11:30:16AM +0100, Petr Mladek wrote:
On Tue 2014-12-09 12:51:41, Josh Poimboeuf wrote:
On Tue, Dec 09, 2014 at 07:05:06PM +0100, Petr Mladek wrote:
This patch makes it clear what initialization and freeing steps need to
be done
when an object (module) is being
On Wed, Dec 10, 2014 at 02:50:54PM +0100, Petr Mladek wrote:
On Tue 2014-12-09 13:20:09, Josh Poimboeuf wrote:
On Tue, Dec 09, 2014 at 07:05:07PM +0100, Petr Mladek wrote:
The situation with variables storing the address of the old and new code
is not ideal. One is called func
change that can not execute safely with
the old version of the function can _not_ be safely applied in this
version.
Signed-off-by: Seth Jennings sjenn...@redhat.com
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
Documentation/ABI/testing/sysfs-kernel-livepatch | 44 ++
MAINTAINERS
From: Seth Jennings sjenn...@redhat.com
This adds a new taint flag to indicate when the kernel or a kernel
module has been live patched. This will provide a clean indication in
bug reports that live patching was used.
Additionally, if the crash occurs in a live patched function, the live
patch
Thanks for all the patches and comments for v5. Seth is out this week,
so I'm sending this latest patch set in his absence.
Changelog:
changes in v6:
- add empty patch release function
- Petr's patches 2-5:
- do not quietly ignore wrong usage
- find and verify the old address in
From: Seth Jennings sjenn...@redhat.com
Add a sample live patching module.
Signed-off-by: Seth Jennings sjenn...@redhat.com
---
MAINTAINERS | 1 +
samples/Kconfig | 7 +++
samples/Makefile | 2 +-
samples/livepatch/Makefile
On Thu, Jan 22, 2015 at 05:54:23PM +0800, Li Bin wrote:
On 2015/1/22 16:39, Li Bin wrote:
On 2015/1/22 11:51, Josh Poimboeuf wrote:
On Thu, Jan 22, 2015 at 08:42:29AM +0800, Li Bin wrote:
On 2015/1/21 22:08, Jiri Kosina wrote:
On Wed, 21 Jan 2015, Li Bin wrote:
By this you limit
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 9adf86b..ff7f47d 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -211,7
Rename CONFIG_LIVE_PATCHING to CONFIG_LIVEPATCH to make the naming of
the config and the code more consistent.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
arch/x86/Kconfig | 2 +-
arch/x86/include/asm/livepatch.h | 4 ++--
arch/x86/kernel/Makefile | 2
Acked-by: Josh Poimboeuf jpoim...@redhat.com
---
arch/x86/Kconfig | 2 +-
kernel/livepatch/Kconfig | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 460b31b..29b0952 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86
On Tue, Jan 20, 2015 at 10:56:33AM +0100, Miroslav Benes wrote:
On Fri, 9 Jan 2015, Josh Poimboeuf wrote:
+struct klp_ops {
+ struct list_head node;
+ struct list_head func_stack;
+ struct ftrace_ops fops;
+};
I think it would be useful to add some comments for this structure
between function versions to happen instantaneously by
updating the klp_ops struct's func_stack list. The winner is the
klp_func at the top of the func_stack (front of the list).
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
include/linux/livepatch.h | 4 +-
kernel/livepatch/core.c
Add support for properly stacking patches. This includes enforcing patch stack
semantics and allowing functions to be repatched.
v2 changes:
- add enforce stacking semantics patch
- add documentation comments for new klp_ops struct
Josh Poimboeuf (2):
livepatch: enforce patch stacking
Only allow the topmost patch on the stack to be enabled or disabled, so
that patches can't be removed or added in an arbitrary order.
Suggested-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c | 10 ++
1 file changed, 10
On Tue, Jan 20, 2015 at 04:37:59PM +0100, Jiri Slaby wrote:
On 01/20/2015, 04:26 PM, Josh Poimboeuf wrote:
Add support for patching a function multiple times. If multiple patches
affect a function, the function in the most recently enabled patch
wins. This enables a cumulative patch
Fix a potentially uninitialized return value.
Signed-off-by: Josh Poimboeuf jpoim...@redhat.com
---
kernel/livepatch/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index bc05d39..9adf86b 100644
--- a/kernel/livepatch
On Thu, Jan 22, 2015 at 08:42:29AM +0800, Li Bin wrote:
On 2015/1/21 22:08, Jiri Kosina wrote:
On Wed, 21 Jan 2015, Li Bin wrote:
By this you limit the definition of the patch inter-dependency to just
symbols. But that's not the only way how patches can depend on it other --
the
On Fri, Jan 16, 2015 at 05:51:11PM +0100, Jiri Kosina wrote:
One thing that makes me worried here is we basically apply patches in a
'stackable' manner, but then this allows them to be removed (disabled) in
an arbitrary order. Is this really the semantics we want?
The scenario I am
On Mon, Jan 19, 2015 at 08:48:42PM +0100, Jiri Kosina wrote:
On Mon, 19 Jan 2015, Josh Poimboeuf wrote:
If this is implemented really in a fully stackable manner (i.e. you
basically would be able to disable only the function that is currently
active, i.e. on top of the stack
On Wed, Feb 11, 2015 at 11:55:05AM +0100, Jiri Slaby wrote:
On 02/10/2015, 08:57 PM, Josh Poimboeuf wrote:
On Tue, Feb 10, 2015 at 08:02:34PM +0100, Jiri Slaby wrote:
On 02/09/2015, 06:31 PM, Josh Poimboeuf wrote:
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
On Tue, Feb 10, 2015 at 07:48:17PM +0900, Masami Hiramatsu wrote:
(2015/02/10 2:31), Josh Poimboeuf wrote:
Move task_rq_lock/unlock() to sched.h so they can be used elsewhere.
The livepatch code needs to lock each task's rq in order to safely
examine its stack and switch it to a new patch
On Tue, Feb 10, 2015 at 07:58:30PM +0900, Masami Hiramatsu wrote:
(2015/02/10 2:31), Josh Poimboeuf wrote:
+/*
+ * Try to safely transition a task to the universe goal. If the task is
+ * currently running or is sleeping on a to-be-patched or to-be-unpatched
+ * function, return false
On Tue, Feb 10, 2015 at 09:57:44AM +0100, Jiri Kosina wrote:
On Mon, 9 Feb 2015, Josh Poimboeuf wrote:
2) As mentioned above, kthreads which are always sleeping on a patched
function
will never transition to the new universe. This is really a minor issue
(less than 1% of patches
1 - 100 of 7781 matches
Mail list logo
