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

[Jiri Kosina]

[ 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.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/