Your Linux hosts take kernel live patches. Does that remove the need to reboot?

## What live patching is Kernel live patching replaces the behaviour of individual functions inside a kernel that is already running. The patched function is compiled and loaded as a module, and the kernel's function-entry redirection machinery makes future calls to the original symbol land on the replacement instead. Calls that are already in flight finish on the old code; the kernel waits until no task is executing inside the affected functions before it flips them, which is why a live patch can occasionally take a while to become fully active on a busy machine. The attraction is obvious for the hosts this leaf is about: a virtualisation host carrying guests that cannot pause, a management appliance inside a change freeze, a node in a cloud control plane whose drain is expensive. Live patching is the honest answer to "we cannot take the downtime" - as long as you know exactly what it does not cover. ## The four limits **1. Only function-shaped fixes.** A live patch substitutes code. If the fix changes the layout of a structure, adds a field, alters the meaning of an existing field, or depends on initialisation that already ran at boot, there is no safe way to convert the live state that thousands of existing objects are already using. Vendors classify those as reboot-only. So the set of live-patchable fixes is a subset of kernel fixes, chosen by the vendor, and it is not you who decides. **2. Only the kernel.** This is the limit that catches people in review. A live-patched host is still running whatever userspace it started: a replaced shared library is still mapped into every daemon that loaded it before the install, and those daemons need to restart independently. Live patching gives you a current kernel and says nothing about the rest of the address spaces on the box. **3. Nothing below the kernel.** Device and platform firmware, and the out-of-band management controller, are on their own cadence. The controller in particular runs its own software on its own processor and stays powered when the host is off, so no amount of kernel live patching moves it. **4. The stream expires.** A live-patch stream is built against a specific base kernel. Vendors maintain it for a bounded period, after which fixes are only shipped for a newer base, and the only way onto that base is a boot. There is also a practical ceiling: patches accumulate on the running kernel, and the further the running state drifts from any shipped kernel, the more you are operating a configuration nobody else has. ## The state trap One detail worth knowing because it inverts the intuition of the whole leaf: the live patch lives in memory. Depending on how the estate is set up, a host that boots without the live patch being reapplied - or that boots an on-disk kernel image which was never updated - comes back up *less* patched than it was before the reboot. The usual arrangement reapplies patches early at boot and updates the on-disk kernel too, but this is a real failure mode and you should say it out loud rather than assume it. ## How to answer in an interview Do not answer "yes" or "no" flatly. Say what live patching moves - self-contained kernel function fixes, applied without downtime, which is genuinely valuable for hosts that cannot restart. Then name the three things it leaves behind: reboot-only kernel changes, all of userspace, and everything below the kernel. Then name the clock: the stream is bounded, so the reboot is deferred, not cancelled. A good closing line is that live patching converts an urgent, unplanned reboot into a scheduled one, and the value of that is real - but if the estate treats live patching as permission never to plan a reboot at all, it has quietly recreated the population that never completes a cycle.