If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

SUSE Posts kGraft, Red Hat Posts Kpatch Patches

Phoronix: SUSE Posts kGraft, Red Hat Posts Kpatch Patches

SUSE developers yesterday posted their sixteen patches for implementing their kGraft live kernel patching mechanism in the mainline Linux kernel as an alternative to Ksplice. Red Hat has immediately followed-up by posting their kernel patches to Kpatch, their new approach to live patching a running Linux kernel...

Kpatch seems to be superior to kGraft thanks to the "Keep it Simple Stupid" philosophy. Use that.

I'd like to ear both sides (obviously who write Kpatch think it's superior), but I can agree with that. A separate module with (almost) no need for edits in the kernel seems superior.
I also like that it pretty much stop every function and upgrade them. Better to upgrade everything and fail than having a mix of old/new stuff and failing randomly after a while.

Why is it a problem that there is a small ms pause when you update the kernel? The kernel is updated about every 3 months or so?

Normally, you wouldn't have a problem just updating and rebooting rather than live updating the kernel. The people who do want to live update are those who cannot afford to have any downtime at all and some of these systems are very sensitive to latency. Ex: systems that perform financial transactions. It is a small but very important niche

Normally, you wouldn't have a problem just updating and rebooting rather than live updating the kernel. The people who do want to live update are those who cannot afford to have any downtime at all and some of these systems are very sensitive to latency. Ex: systems that perform financial transactions. It is a small but very important niche

The systems for which downtime is unacceptable are indeed few and do indeed tend to be important. However, there are many systems where some downtime may be acceptable, just *not right this very minute*. If a kernel patch addresses a critical security vulnerability, the need to schedule downtime in advance (or wait until the next scheduled downtime) is in conflict with the need to apply the patch immediately. I think that is a common conflict, and my impression is that's what these live patching projects are really motivated by.