Message-ID: <20141118185836.GA3844@treble.redhat.com>
Date:	Tue, 18 Nov 2014 12:58:36 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Petr Mladek <pmladek@...e.cz>
Cc:	Vojtech Pavlik <vojtech@...e.cz>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Christoph Hellwig <hch@...radead.org>,
	Seth Jennings <sjenning@...hat.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	live-patching@...r.kernel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Kernel Live Patching

On Tue, Nov 18, 2014 at 01:47:46PM +0100, Petr Mladek wrote:
> On Thu 2014-11-13 17:38:04, Vojtech Pavlik wrote:
> > On Fri, Nov 14, 2014 at 12:56:38AM +0900, Masami Hiramatsu wrote:
> > > > It'd be mostly based on your refcounting code, including stack
> > > > checking (when a process sleeps, counter gets set based on number of
> > > > patched functions on the stack), possibly including setting the counter
> > > > to 0 on syscall entry/exit, but it'd make the switch per-thread like
> > > > kGraft does, not for the whole system, when the respective counters
> > > > reach zero.
> > > 
> > > I'm not sure what happens if a process sleeps on the patched-set?
> > 
> > Then the patching process will be stuck until it is woken up somehow.
> > But it's still much better to only have to care about processes sleeping
> > on the patched-set than about processes sleeping anywhere (kGraft).
> > 
> > > If we switch the other threads, when this sleeping thread wakes up
> > > that will see the old functions (and old data).
> > 
> > Yes, until the patching process is complete, data must be kept in the
> > old format, even by new functions.
> 
> I am not sure if I am able to follow all the ideas. Anyway,
> the above sentence triggered some warning bells in my head ;-)
> 
> Would it mean waiting for two safe switch points, please? One to switch
> functions and the second to switch the data structures?

Yes, though the first switch "point" doesn't have to be instantaneous.
When changing data, new functions must be able to understand both old
and new data.  The transition to the new functions can happen gradually,
as long as you don't start creating new data (or migrating existing
data) until after the patching is complete.  That way you'll never have
an old function trying to access new data.

> The later condition looks pretty complicated to me. It would mean to
> make sure that the old structures won't be stored anywhere and nobody
> would want to use them later. It won't be enough to check the stack
> because some function might be called later that would access a saved
> pointer pointing to the old structure.

We don't need to necessarily get rid of all old data, because new
functions can handle both old and new data.

> 
> 
> > > So I think we need both SWITCH_THREAD and SWITCH_KERNEL options in
> > > that case.
> > 
> > With data shadowing that's not required. It still may be worth having
> > it.
> 
> I am not 100% sure what the shadowing means. If it means that the new
> function will be able to read and write both versions of the
> structure, it looks more easily doable to me.

Shadowing is a way of adding virtual fields to existing data structures
at runtime.  That enables the new functions to easily determine whether
they're dealing with v1 or v2 of a given data structure, as well as
access any new fields in v2.


-- 
Josh
--
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