Message-ID: <54733FF6.7080301@hitachi.com>
Date:	Mon, 24 Nov 2014 23:25:58 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Vojtech Pavlik <vojtech@...e.cz>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Kosina <jkosina@...e.cz>,
	Seth Jennings <sjenning@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Christoph Hellwig <hch@...radead.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 2/3] kernel: add support for live patching

(2014/11/24 22:31), Vojtech Pavlik wrote:
> On Mon, Nov 24, 2014 at 02:26:08PM +0100, Thomas Gleixner wrote:
>> On Mon, 24 Nov 2014, Jiri Kosina wrote:
>>> On Mon, 24 Nov 2014, Thomas Gleixner wrote:
>>>> How is determined whether a change can be applied w/o a consistency
>>>> mechanism or not?
>>>
>>> By a human being producing the "live patch" code.
>>>
>>> If the semantics of the patch requires consistency mechanism to be applied 
>>> (such as "old and new function must not run in parallel, because locking 
>>> rules would be violated", or "return value from a function that is being 
>>> called in a loop is changing its meaning", etc.), then this first naive 
>>> implementation simply can't be used.
>>>
>>> For simple things though, such as "add a missing bounds check to sys_foo() 
>>> prologue and return -EINVAL if out-of-bounds", this is sufficient.
>>>
>>> It's being designed in a way that more advanced consistency models (such 
>>> as the ones kgraft and kpatch are currently implementing) can be built on 
>>> top of it.
>>>
>>> The person writing the patch would always need to understand what he is 
>>> doing to be able to pick correct consistency model to be used. I 
>>> personally think this is a good thing -- this is nothing where we should 
>>> be relying on any kinds of tools.
>>
>> But why want we to provide a mechanism which has no consistency
>> enforcement at all?
>>
>> Surely you can argue that the person who is doing that is supposed to
>> know what he's doing, but what's the downside of enforcing consistency
>> mechanisms on all live code changes?
> 
> The consistency engine implementing the consistency model is the most
> complex part of the live patching technology. We want to have something
> small, easy to understand pushed out first, to build on top of that.

I think we'd better incubate this live patching in another tree
until those consistency engines/models are enough prepared.

> 
> Plus we're still discussing which exact consistency model to use for
> upstream live patching (there are many considerations) and whether one
> is enough, or whether an engine that can do more than one is required.
> 
> The consistency models of kpatch and kGraft aren't directly compatible.

It maybe not compatible, but complementary. This patch series clarifies
the common patch module format, I think we just need consistency engines
and selector flag for each patch module.

Thank you,

> 
> I think we're on a good way towards a single model, but we'll see when
> it's implemented within the live patching framework just posted.
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists