Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1369322
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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