On Tue, 6 May 2014, Ingo Molnar wrote: > So what I'm curious about, what is the actual 'in the field' distro > experience, about the type of live-patches that get pushed with > urgency?
This is of course a very good question. We've done some very light preparatory analysis and went through patches which would make most sense to be shipped as hot/live patches without enough time for proper downtime scheduling (i.e. CVE severity high enough (local root), etc). Most of the time, these turn out to be a one-or-few liners, mostly adding extra check, fixing bounds, etc. There were just one or two in a few years history where some extra care would be needed. Of course, I guess that most valuable input regarding this could be coming from kSplice guys, as they have the biggest in-field experience with this, and are shipping a lot of non-trivial patches this way, not just the "super-critical" ones. But I am not really sure whether we can expect any input from them, unfortunately. > My guess would be that the overwhelming majority of live-patches don't > change data structures - and hence the right initial model would be to > ensure (via tooling, and via review) that 'v1' and 'v2' data is exactly > the same. I fully agree ... that's why we are not pro-actively dealing with that in kGraft, for the sake of keeping it stupid at simple (at least in the early stages). > The most abstract way to 'live patch' a kernel is to do a checkpoint > save on all application state, to reboot the kernel, boot into the > patched kernel and then restore all application state seemlessly. In some sense yes, but it seems to still be rather costly operation (especially checkpointing on a HUGE machine might take some time, if I understand the technology correctly) compared to just flipping a few bytes (while maintaining overall correctness, of course) in the kernel memory. Basically, CR might be the best solution for very complex and large kernel updates. What I am currently most concerned about though, are scenarios where datacenter owners need to urgently apply a local root one-liner fix with as little hassle as possible. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
