[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 5 May 2016 12:21:59 +0200
From: Petr Mladek <pmladek@...e.com>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Jessica Yu <jeyu@...hat.com>, Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Michael Ellerman <mpe@...erman.id.au>,
Heiko Carstens <heiko.carstens@...ibm.com>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, linuxppc-dev@...ts.ozlabs.org,
linux-s390@...r.kernel.org, Vojtech Pavlik <vojtech@...e.com>,
Jiri Slaby <jslaby@...e.cz>,
Chris J Arges <chris.j.arges@...onical.com>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: barriers: was: [RFC PATCH v2 17/18] livepatch: change to a
per-task consistency model
On Wed 2016-05-04 12:02:36, Josh Poimboeuf wrote:
> On Wed, May 04, 2016 at 02:39:40PM +0200, Petr Mladek wrote:
> > On Thu 2016-04-28 15:44:48, Josh Poimboeuf wrote:
> > > Change livepatch to use a basic per-task consistency model. This is the
> > > foundation which will eventually enable us to patch those ~10% of
> > > security patches which change function or data semantics. This is the
> > > biggest remaining piece needed to make livepatch more generally useful.
> >
> > I spent a lot of time with checking the memory barriers. It seems that
> > they are basically correct. Let me use my own words to show how
> > I understand it. I hope that it will help others with review.
>
> [...snip a ton of useful comments...]
>
> Thanks, this will help a lot! I'll try to incorporate your barrier
> comments into the code.
Thanks a lot.
> I also agree that kpatch_patch_task() is poorly named. I was trying to
> make it clear to external callers that "hey, the task is getting patched
> now!", but it's internally inconsistent with livepatch code because we
> make a distinction between patching and unpatching.
>
> Maybe I'll do:
>
> klp_update_task_patch_state()
I like it. It is long but it well describes the purpose.
Livepatch is using many state variables:
+ global: klp_transition_patch, klp_target_state
+ per task specific: TIF_PENDING_PATCH, patch_state
+ per each new function: transition, patched
+ per old function: func_stack
+ per object: patched, loaded
+ per patch: enabled
The dependency between them and the workflow is important to
create a mental picture about the Livepatching. Good names
help with it.
Best Regards,
Petr
Powered by blists - more mailing lists