Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1369322

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

From Petr Mladek <pmladek@suse.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model
Date 2016-04-01 15:40 +0200
Message-ID <rj7sR-4YN-7@gated-at.bofh.it> (permalink)
References <rgFKp-6zA-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> These patches are still a work in progress, but Jiri asked that I share
> them before I go on vacation next week.  Based on origin/master because
> it has CONFIG_STACK_VALIDATION.

I have to follow Mirek and say that it is a great work.

> There's also a func->immediate flag which allows users to specify that
> certain functions in the patch can be applied without per-task
> consistency.  This might be useful if you want to patch a common
> function like schedule(), and the function change doesn't need
> consistency but the rest of the patch does.

I like the possibility to immediately patch some functions or objects.
Just note that this is not yet completely implemented and it is not
on the TODO list.

We probably should not set func->transition flag when func->immediate
is set or when the related func->object is set. It currently happens
only when patch->immediate is set.

Also we should ignore immediate functions and objects when the stack
is checked.


> Still have a lot of TODOs, some of them are listed here.  If you see
> something objectionable, it might be a good idea to make sure it's not
> already on the TODO list :-)
> 
> TODO:
> - come up with a better name than universe?  KLP_STATE_PREV/NEXT?
>   KLP_UNPATCHED/PATCHED?  there were some objections to the name in v1.

The name "universe" has an advantage if we later allow to
enable/disable more patches in parallel. The integer might hold
an identifier of the last applied patch. I have been playing with
this for kGraft one year ago and it was really challenging.
We should avoid it if possible. It is not really needed
if we are able to complete any transition in a reasonable time.

If we support only one transition at a time, a simple boolean
or even bit should be enough. The most descriptive name would
be klp_transition_patch_applied but it is quite long.

Note that similar information is provided by TIF_KLP_NEED_UPDATE
flag. We use only this bit in kGraft. It saves some space in
task_struct but it brings other challenges. We need to prevent
migration using a global "kgr_immutable" flag until ftrace handlers
for all patched functions are in place. We need to set the flag
back when the ftrace handler is called and the global "kgr_immutable"
flag is set.

> - update documentation for sysfs, proc, livepatch

Also we should publish somewhere the information about TIF_KLP_NEED_UPDATE
flag, e.g. /proc/<pid>/klp_need_update. It is handy to see what
process blocks the transition. We have something similar in
kGraft, see in_progress_show() at
https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/commit/?h=kgraft-4.4&id=1c82fbd7b1fe240f4ed178a6506a93033f6a4bed


I am still shaking my head around the patches.

Best Regards,
Petr

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 03/14] x86/asm/head: standardize the bottom of the stack for idle tasks Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 09/14] livepatch: remove unnecessary object loaded check Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 11/14] livepatch: store function sizes Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 13/14] livepatch: add /proc/<pid>/patch_status Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
    Re: [RFC PATCH v1.9 13/14] livepatch: add /proc/<pid>/patch_status Jiri Slaby <jslaby@suse.cz> - 2016-03-31 11:40 +0200
      Re: [RFC PATCH v1.9 13/14] livepatch: add /proc/<pid>/patch_status Jiri Slaby <jslaby@suse.cz> - 2016-03-31 11:50 +0200
  [RFC PATCH v1.9 02/14] x86/asm/head: use a common function for starting CPUs Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting reliable stack traces Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
    Re: [RFC PATCH v1.9 07/14] x86/stacktrace: add function for detecting  reliable stack traces Miroslav Benes <mbenes@suse.cz> - 2016-03-31 15:10 +0200
  [RFC PATCH v1.9 12/14] livepatch: create per-task consistency model Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
    Re: [RFC PATCH v1.9 12/14] livepatch: create per-task consistency  model Miroslav Benes <mbenes@suse.cz> - 2016-03-31 15:20 +0200
  [RFC PATCH v1.9 08/14] livepatch: separate enabled and patched states Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  [RFC PATCH v1.9 04/14] x86: move _stext marker before head code Josh Poimboeuf <jpoimboe@redhat.com> - 2016-03-25 20:40 +0100
  Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Miroslav Benes <mbenes@suse.cz> - 2016-03-31 15:00 +0200
  Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Petr Mladek <pmladek@suse.com> - 2016-04-01 15:40 +0200
    Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Petr Mladek <pmladek@suse.com> - 2016-04-01 17:40 +0200
  Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Miroslav Benes <mbenes@suse.cz> - 2016-04-01 15:40 +0200

csiph-web