From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.cz>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/9] livepatch: consistency model
Date: Tue, 10 Feb 2015 20:16:59 +0900 [thread overview]
Message-ID: <54D9E8AB.3070800@hitachi.com> (raw)
In-Reply-To: <cover.1423499826.git.jpoimboe@redhat.com>
(2015/02/10 2:31), Josh Poimboeuf wrote:
> This patch set implements a livepatch consistency model, targeted for 3.21.
> Now that we have a solid livepatch code base, this is the biggest remaining
> missing piece.
>
> This code stems from the design proposal made by Vojtech [1] in November. It
> makes live patching safer in general. Specifically, it allows you to apply
> patches which change function prototypes. It also lays the groundwork for
> future code changes which will enable data and data semantic changes.
Interesting, How would you do that?
> It's basically a hybrid of kpatch and kGraft, combining kpatch's backtrace
> checking with kGraft's per-task consistency. When patching, tasks are
> carefully transitioned from the old universe to the new universe. A task can
> only be switched to the new universe if it's not using a function that is to be
> patched or unpatched. After all tasks have moved to the new universe, the
> patching process is complete.
>
> How it transitions various tasks to the new universe:
>
> - The stacks of all sleeping tasks are checked. Each task that is not sleeping
> on a to-be-patched function is switched.
>
> - Other user tasks are handled by do_notify_resume() (see patch 9/9). If a
> task is I/O bound, it switches universes when returning from a system call.
> If it's CPU bound, it switches when returning from an interrupt. If it's
> sleeping on a patched function, the user can send SIGSTOP and SIGCONT to
> force it to switch upon return from the signal handler.
Ah, OK. So you can handle those without hooking switch_to :)
>
> - Idle "swapper" tasks which are sleeping on a to-be-patched function can be
> switched from within the outer idle loop.
>
> - An interrupt handler will inherit the universe of the task it interrupts.
>
> - kthreads which are sleeping on to-be-patched functions are not yet handled
> (more on this below).
>
>
> I think this approach provides the best benefits of both kpatch and kGraft:
>
> advantages vs kpatch:
> - no stop machine latency
Good! :)
> - higher patch success rate (can patch in-use functions)
> - patching failures are more predictable (primary failure mode is attempting to
> patch a kthread which is sleeping forever on a patched function, more on this
> below)
>
> advantages vs kGraft:
> - less code complexity (don't have to hack up the code of all the different
> kthreads)
> - less impact to processes (don't have to signal all sleeping tasks)
>
> disadvantages vs kpatch:
> - no system-wide switch point (not really a functional limitation, just forces
> the patch author to be more careful. but that's probably a good thing anyway)
OK, we must check carefully that the old function and new function can be co-exist.
> My biggest concerns and questions related to this patch set are:
>
> 1) To safely examine the task stacks, the transition code locks each task's rq
> struct, which requires using the scheduler's internal rq locking functions.
> It seems to work well, but I'm not sure if there's a cleaner way to safely
> do stack checking without stop_machine().
We'd better ask scheduler people.
>
> 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). It's not necessarily something that needs to be
> resolved with this patch set, but it would be good to have some discussion
> about it regardless.
>
> To overcome this issue, I have 1/2 an idea: we could add some stack checking
> code to the ftrace handler itself to transition the kthread to the new
> universe after it re-enters the function it was originally sleeping on, if
> the stack doesn't already have have any other to-be-patched functions.
> Combined with the klp_transition_work_fn()'s periodic stack checking of
> sleeping tasks, that would handle most of the cases (except when trying to
> patch the high-level thread_fn itself).
It makes sense to me. (I just did similar thing)
>
> But then how do you make the kthread wake up? As far as I can tell,
> wake_up_process() doesn't seem to work on a kthread (unless I messed up my
> testing somehow). What does kGraft do in this case?
Hmm, at a glance, the code itself can work on kthread too...
Maybe you can also send you testing patch too.
Thank you,
>
>
> [1] https://lkml.org/lkml/2014/11/7/354
>
>
> Josh Poimboeuf (9):
> livepatch: simplify disable error path
> livepatch: separate enabled and patched states
> livepatch: move patching functions into patch.c
> livepatch: get function sizes
> sched: move task rq locking functions to sched.h
> livepatch: create per-task consistency model
> proc: add /proc/<pid>/universe to show livepatch status
> livepatch: allow patch modules to be removed
> livepatch: update task universe when exiting kernel
>
> arch/x86/include/asm/thread_info.h | 4 +-
> arch/x86/kernel/signal.c | 4 +
> fs/proc/base.c | 11 ++
> include/linux/livepatch.h | 38 ++--
> include/linux/sched.h | 3 +
> kernel/fork.c | 2 +
> kernel/livepatch/Makefile | 2 +-
> kernel/livepatch/core.c | 360 ++++++++++---------------------------
> kernel/livepatch/patch.c | 206 +++++++++++++++++++++
> kernel/livepatch/patch.h | 26 +++
> kernel/livepatch/transition.c | 318 ++++++++++++++++++++++++++++++++
> kernel/livepatch/transition.h | 16 ++
> kernel/sched/core.c | 34 +---
> kernel/sched/idle.c | 4 +
> kernel/sched/sched.h | 33 ++++
> 15 files changed, 747 insertions(+), 314 deletions(-)
> create mode 100644 kernel/livepatch/patch.c
> create mode 100644 kernel/livepatch/patch.h
> create mode 100644 kernel/livepatch/transition.c
> create mode 100644 kernel/livepatch/transition.h
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2015-02-10 11:17 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 17:31 [RFC PATCH 0/9] livepatch: consistency model Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 1/9] livepatch: simplify disable error path Josh Poimboeuf
2015-02-13 12:25 ` Miroslav Benes
2015-02-18 17:03 ` Petr Mladek
2015-02-18 20:07 ` Jiri Kosina
2015-02-09 17:31 ` [RFC PATCH 2/9] livepatch: separate enabled and patched states Josh Poimboeuf
2015-02-10 16:44 ` Jiri Slaby
2015-02-10 17:21 ` Josh Poimboeuf
2015-02-13 12:57 ` Miroslav Benes
2015-02-13 14:39 ` Josh Poimboeuf
2015-02-13 14:46 ` Miroslav Benes
2015-02-09 17:31 ` [RFC PATCH 3/9] livepatch: move patching functions into patch.c Josh Poimboeuf
2015-02-10 18:27 ` Jiri Slaby
2015-02-10 18:50 ` Josh Poimboeuf
2015-02-13 14:28 ` Miroslav Benes
2015-02-13 15:09 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 4/9] livepatch: get function sizes Josh Poimboeuf
2015-02-10 18:30 ` Jiri Slaby
2015-02-10 18:53 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 5/9] sched: move task rq locking functions to sched.h Josh Poimboeuf
2015-02-10 10:48 ` Masami Hiramatsu
2015-02-10 14:54 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 6/9] livepatch: create per-task consistency model Josh Poimboeuf
2015-02-10 10:58 ` Masami Hiramatsu
2015-02-10 14:59 ` Josh Poimboeuf
2015-02-10 15:59 ` Miroslav Benes
2015-02-10 16:56 ` Josh Poimboeuf
2015-02-11 16:28 ` Miroslav Benes
2015-02-11 20:23 ` Josh Poimboeuf
2015-02-10 19:27 ` Seth Jennings
2015-02-10 19:32 ` Josh Poimboeuf
2015-02-11 10:21 ` Miroslav Benes
2015-02-11 20:19 ` Josh Poimboeuf
2015-02-12 10:45 ` Miroslav Benes
2015-02-12 3:21 ` Josh Poimboeuf
2015-02-12 11:56 ` Peter Zijlstra
2015-02-12 12:25 ` Jiri Kosina
2015-02-12 12:36 ` Peter Zijlstra
2015-02-12 12:39 ` Jiri Kosina
2015-02-12 12:39 ` Peter Zijlstra
2015-02-12 12:42 ` Jiri Kosina
2015-02-12 13:01 ` Josh Poimboeuf
2015-02-12 12:51 ` Josh Poimboeuf
2015-02-12 13:08 ` Peter Zijlstra
2015-02-12 13:16 ` Jiri Kosina
2015-02-12 14:20 ` Josh Poimboeuf
2015-02-12 14:27 ` Jiri Kosina
2015-02-12 13:16 ` Jiri Slaby
2015-02-12 13:35 ` Peter Zijlstra
2015-02-12 14:08 ` Jiri Kosina
2015-02-12 15:24 ` Josh Poimboeuf
2015-02-12 14:20 ` Jiri Slaby
2015-02-12 14:32 ` Jiri Kosina
2015-02-18 20:17 ` Ingo Molnar
2015-02-18 20:44 ` Vojtech Pavlik
2015-02-19 9:52 ` Peter Zijlstra
2015-02-19 10:11 ` Vojtech Pavlik
2015-02-19 10:51 ` Peter Zijlstra
2015-02-12 13:26 ` Jiri Slaby
2015-02-12 15:48 ` Josh Poimboeuf
2015-02-14 11:40 ` Jiri Slaby
2015-02-17 14:59 ` Josh Poimboeuf
2015-02-16 14:19 ` Miroslav Benes
2015-02-17 15:10 ` Josh Poimboeuf
2015-02-17 15:48 ` Miroslav Benes
2015-02-17 16:01 ` Josh Poimboeuf
2015-02-18 12:42 ` Miroslav Benes
2015-02-18 13:15 ` Josh Poimboeuf
2015-02-18 13:42 ` Miroslav Benes
2015-02-09 17:31 ` [RFC PATCH 7/9] proc: add /proc/<pid>/universe to show livepatch status Josh Poimboeuf
2015-02-10 18:47 ` Jiri Slaby
2015-02-10 18:57 ` Josh Poimboeuf
2015-02-09 17:31 ` [RFC PATCH 8/9] livepatch: allow patch modules to be removed Josh Poimboeuf
2015-02-10 19:02 ` Jiri Slaby
2015-02-10 19:57 ` Josh Poimboeuf
2015-02-11 10:55 ` Jiri Slaby
2015-02-11 18:39 ` Josh Poimboeuf
2015-02-12 15:22 ` Miroslav Benes
2015-02-13 12:44 ` Josh Poimboeuf
2015-02-13 16:04 ` Josh Poimboeuf
2015-02-13 16:17 ` Miroslav Benes
2015-02-13 20:49 ` Josh Poimboeuf
2015-02-16 16:06 ` Miroslav Benes
2015-02-17 15:55 ` Josh Poimboeuf
2015-02-17 16:38 ` Miroslav Benes
2015-02-09 17:31 ` [RFC PATCH 9/9] livepatch: update task universe when exiting kernel Josh Poimboeuf
2015-02-16 10:16 ` Jiri Slaby
2015-02-17 14:58 ` Josh Poimboeuf
2015-02-09 23:15 ` [RFC PATCH 0/9] livepatch: consistency model Jiri Kosina
2015-02-10 3:05 ` Josh Poimboeuf
2015-02-10 7:21 ` Jiri Kosina
2015-02-10 8:57 ` Jiri Kosina
2015-02-10 14:43 ` Josh Poimboeuf
2015-02-10 11:16 ` Masami Hiramatsu [this message]
2015-02-10 15:59 ` Josh Poimboeuf
2015-02-10 17:29 ` Josh Poimboeuf
2015-02-13 10:14 ` Jiri Kosina
2015-02-13 14:19 ` Josh Poimboeuf
2015-02-13 14:22 ` Jiri Kosina
2015-02-13 14:40 ` Miroslav Benes
2015-02-13 14:55 ` Josh Poimboeuf
2015-02-13 14:41 ` Josh Poimboeuf
2015-02-24 11:27 ` Masami Hiramatsu
2015-03-10 16:23 ` Josh Poimboeuf
2015-03-10 21:02 ` Jiri Kosina
2015-03-10 21:30 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D9E8AB.3070800@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=sjenning@redhat.com \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).