Re: [PATCH 0/2] Kernel Live Patching

[Petr Mladek]

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?

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.


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


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