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 live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
