On 04/26/2019 09:04 AM, Joe Lawrence wrote:
> On 4/26/19 11:40 AM, Mario Smarduch wrote:
>>
>>
>> On 04/26/2019 06:32 AM, Joe Lawrence wrote:
>>> On 4/26/19 3:51 AM, Mario Smarduch wrote:
>>>> Hello,
>>>> I noticed that with livepatch the old and new functions can
>>>> run in parallel, but with kpatch the kpatch module load fails on
>>>> "activeness safety check".
>>>
>>> Hi Mario,
>>>
>>> I think you are referring to kpatch's use of stop_machine() to quiesce
>>> the system before patching vs. livepatch's consistency model[1] and its
>>> convergence on a patched state?
>>>
>>>> Am I missing something with livepatch? Is there another way to
>>>> build and run it?
>>>
>>> AFAIK there is no way around the consistency model with livepatch. What
>>> you might be able to do is hack the kpatch-build to utilize the kpatch
>>> support module instead of the livepatch API. (Look for the
>>> $KPATCH_MODULE code in the kpatch-build script.) I don't think this use
>>> case is very well tested and in fact, the kpatch.ko will be deprecated
>>> eventually.
>>
>>
>>>
>>> Do you have a particular case in mind which the livepatch consistency
>>> model does not support?
>> The use case is replacing a function that's sleeping somewhere in
>> uninterruptible mode. With livepatch the function is patched anyway
>> with new and old functions sharing data. Eventually the old function
>> wakes up and can result in problems as two have different view of the
>> shared data (i.e. data field interpretation).
>>
>> With kpatch it works fine.
>
> Ah yes, I can see how kpatch stop_machine() model makes this 10x easier
> to handle.
>
> You may be able to continue using kpatch.ko (with the mentioned
> kpatch-build changes), or to make a livepatch version safer:
>
> - Shadow variables: check out the second sample "In-flight parent
> objects" in Documentation/livepatch/shadow-vars.txt. It shows how to
> translate 1d147bfa6429 ("mac80211: fix AP powersave TX vs. wakeup race")
> into a livepatch that will safely operate on "new" and "old"
> ieee80211_tx_latency_stat structures.
>
> In your case, if it is only the interpretation of existing data that
> needs to change, I think you may be able to get away with an empty
> shadow variable -- this idea is mentioned in the 'Other use-cases'
> section of shadow-vars.txt.
>
>
> Alternatively, if you want a giant throw-switch of sorts:
>
> - Post-patch callbacks: See Documentation/livepatch/callbacks.txt for
> details on livepatching callbacks. Of particular interest would be the
> 'post-patch' callback, which only runs once *all* tasks have been
> migrated to running new code. You may be able to employ a post-patch
> callback that sets an indicator to the new code that patching is complete.
>
>
> If you can share the source .patch or upstream commit id, that would be
> helpful, but I can understand if that needs to remain confidential for
> security reasons.
>
> Hope this helps,
Yep sure does thanks.
>
> -- Joe
_______________________________________________
kpatch mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/kpatch
