Re: Re: [PATCH 0/2] Kernel Live Patching

[Masami Hiramatsu]

Hi,

(2014/11/08 6:27), Vojtech Pavlik wrote:
> On Fri, Nov 07, 2014 at 09:45:00AM -0600, Josh Poimboeuf wrote:
> 
>>> 	LEAVE_FUNCTION
>>> 	LEAVE_PATCHED_SET
>>> 	LEAVE_KERNEL
>>>
>>> 	SWITCH_FUNCTION
>>> 	SWITCH_THREAD
>>> 	SWITCH_KERNEL
>>>
>>> Now with those definitions:
>>>
>>> 	livepatch (null model), as is, is LEAVE_FUNCTION and SWITCH_FUNCTION
>>>
>>> 	kpatch, masami-refcounting and Ksplice are LEAVE_PATCHED_SET and SWITCH_KERNEL
>>>
>>> 	kGraft is LEAVE_KERNEL and SWITCH_THREAD
>>>
>>> 	CRIU/kexec is LEAVE_KERNEL and SWITCH_KERNEL
>>
>> Thanks, nice analysis!

Hmm, I doubt this can cover all. what I'm thinking is a combination of
LEAVE_KERNEL and SWITCH_KERNEL by using my refcounting and kGraft's
per-thread "new universe" flagging(*). It switches all threads but not
change entire kernel as kexec does.

So, I think the patch may be classified by following four types

PATCH_FUNCTION - Patching per function. This ignores context, just
               change the function.
               User must ensure that the new function can co-exist
               with old functions on the same context (e.g. recursive
               call can cause inconsistency).

PATCH_THREAD - Patching per thread. If a thread leave the kernel,
               changes are applied for that thread.
               User must ensure that the new functions can co-exist
               with old functions per-thread. Inter-thread shared
               data acquisition(locks) should not be involved.

PATCH_KERNEL - Patching all threads. This wait for all threads leave the
               all target functions.
               User must ensure that the new functions can co-exist
               with old functions on a thread (note that if there is a
               loop, old one can be called first n times, and new one
               can be called afterwords).(**)

RENEW_KERNEL - Renew entire kernel and reset internally. No patch limitation,
               but involving kernel resetting. This may take a time.

(*) Instead of checking stacks, at first, wait for all threads leaving
the kernel once, after that, wait for refcount becomes zero and switch
all the patched functions.

(**) For the loops, if it is a simple loop or some simple lock calls,
we can wait for all threads leave the caller function to avoid inconsistency
by using refcounting.


>>> By blending kGraft and masami-refcounting, we could create a consistency
>>> engine capable of almost any combination of these properties and thus
>>> all the consistency models.
>>
>> Can you elaborate on what this would look like?
> 
> There would be the refcounting engine, counting entries/exits of the
> area of interest (nothing for LEAVE_FUNCTION, patched functions for
> LEAVE_PATCHED_SET - same as Masami's work now, or syscall entry/exit for
> LEAVE_KERNEL), and it'd do the counting either per thread, flagging a
> thread as 'new universe' when the count goes to zero, or flipping a
> 'new universe' switch for the whole kernel when the count goes down to zero.

Ah, that's similar thing what I'd like to try next :)

Sorry, here is an off-topic talk.
I think a problem of kGraft's LEAVE_KERNEL work is that the sleeping
processes. To ensure all the threads are changing to new universe,
we need to wakeup all the threads, or we need stack-dumping to find
someone is sleeping on the target functions. What would the kGraft do
for this issue?

> A patch would have flags which specify a combination of the above
> properties that are needed for successful patching of that specific
> patch.

Agreed.

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


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