Re: live kernel upgrades (was: live kernel patching design)

From: Jiri Kosina
Date: Sun Feb 22 2015 - 14:13:50 EST

[ added live-patching@ ML as well, in consistency with Josh ]

On Sun, 22 Feb 2015, Ingo Molnar wrote:

> It's all still tons of work to pull off a 'live kernel upgrade' on
> native hardware, but IMHO it's tons of very useful work that helps a
> dozen non-competing projects, literally.

Yes, I agree, it might be nice-to-have feature. The only issue with that
is that it's solving a completely different problem than live patching.

Guys working on criu have made quite a few steps in that direction of
already course; modulo bugs and current implementation limitations, you
should be able to checkpoint your userspace, kexec to a new kernel, and
restart your userspace.

But if you ask the folks who are hungry for live bug patching, they
wouldn't care.

You mentioned "10 seconds", that's more or less equal to infinity to them.
And frankly, even "10 seconds" is something we can't really guarantee. We
could optimize the kernel the craziest way we can, but hardware takes its
time to reinitialize. And in most cases, you'd really need to reinitalize
it; I don't see a way how you could safely suspend it somehow in the old
kernel and resume it in a new one, because the driver suspending the
device might be completely different than the driver resuming the device.
How are you able to provide hard guarantees that this is going to work?

So all in all, if you ask me -- yes, live kernel upgrades from v3.20 to
v3.21, pretty cool feature. Is it related to the problem we are after with
live bug patching? I very much don't think so.


Jiri Kosina
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at