On 29.04.2019 20:18, Mario Smarduch wrote: > > > On 04/29/2019 03:03 AM, Evgenii Shatokhin wrote: >> Hi, >> >> On 26.04.2019 16:32, 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. >> >> We have been using the old-style (i.e. relying on kpatch.ko, >> non-Livepatch) binary patches in Virtuozzo for more than 2 years now. >> They still work pretty well for us. I guess, we will continue using this >> until Livepatch matures a bit more. >> >> If you are going to try this approach too, here is the branch with the >> patched kpatch and kpatch-build, might be helpful: >> >> https://github.com/euspectre/kpatch/commits/vz-test >> >> 2 patches are relevant here: >> >> * >> https://github.com/euspectre/kpatch/commit/84b9ba7392d8b79dc4c38ec244331ba61e93bf0c >> - this adds an option to kpatch-build which allows making the old-style >> patches >> >> * >> https://github.com/euspectre/kpatch/commit/5b54fe4b443573d7c7416ed861e99970ec1ce814 >> - this instructs kpatch script to look for the old-style patches first. >> Useful if the kernel has Livepatch enabled as well, which is the case >> for us. >> >> Hope this helps. >> >>> >>> Do you have a particular case in mind which the livepatch consistency >>> model does not support? >>> >>> [1] >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/livepatch/livepatch.txt?h=v5.1-rc6#n63 >>> > > I like the combination of livepatch and kpatch enabled. We have > experienced folks that have been applying trivial livepatches, > kpatch is a welcome addition. > > Just wondering what issues your ran into with livepatch, you guys > dealing with containers must have some hard use cases? > > Do you run into kpatch converging problems (failing the nativeness tets)?
We rely on the "atomic replace" feature for cumulative patches which the mainline Livepatch got only recently. Some time ago, this functionality was removed from kpatch.ko but we restored it in our version, at the cost of some limitations w.r.t. patch load/unload callbacks. I suppose we will wait at least till RedHat backports atomic replace support to their kernels and will then consider migration to livepatch once again. No rush here. Livepatch has many benefits over the old-style patches but we have not tried it in production yet, only experimented with it from time to time. > > Thanks for sharing the patches > > Best. > Mario >>> >>> Regards, >>> ou >>> -- Joe >>> >> Regards, Evgenii _______________________________________________ kpatch mailing list [email protected] https://www.redhat.com/mailman/listinfo/kpatch
