1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

SUSE Posts kGraft, Red Hat Posts Kpatch Patches

Linux Kernel

Published on 01 May 2014 12:22 PM EDT
Written by Michael Larabel in Linux Kernel
5 Comments

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.

SUSE announced kGraft back in February as a new way of live-patching the Linux kernel to reduce downtime. In late March they then released the kGraft source code and reiterated their intention to mainline kGraft in the Linux kernel.

Red Hat in early March meanwhile announced Kpatch as their new approach to live kernel patching that was under development prior to knowing about kGraft.

Jiri Slaby of SUSE posted yesterday the kGraft kernel patches under a "request for comments" flag to seek feedback from Linux kernel developers on the work. The kGraft work is spread across 16 patches.

This morning, Red Hat's Josh Poimboeuf countered with their two kernel patches needed to implement Kpatch. Those two patches can be found via the LKML mailing list. Kpatch is served as a self-contained GPL kernel module that doesn't need any core kernel code changes. Red Hat wants to see it merged, or some combination with kGraft.

Josh Poimboeuf's explanation from the Red Hat perspective in comparing against kGraft came down to:
I think the biggest difference between kpatch and kGraft is how they ensure that the patch is applied atomically and safely.

kpatch checks the backtraces of all tasks in stop_machine() to ensure that no instances of the old function are running when the new function is applied. I think the biggest downside of this approach is that stop_machine() has to idle all other CPUs during the patching process, so it inserts a small amount of latency (a few ms on an idle system).

Instead, kGraft uses per-task consistency: each task either sees the old version or the new version of the function. This gives a consistent view with respect to functions, but _not_ data, because the old and new functions are allowed to run simultaneously and share data. This could be dangerous if a patch changes how a function uses a data structure. The new function could make a data change that the old function wasn't expecting.

With kpatch, that's not an issue because all the functions are patched at the same time. So kpatch is safer with respect to data interactions.

Other advantages of the kpatch stop_machine() approach:

- IMO, the kpatch code is much simpler than kGraft. The implementation is very straightforward and is completely self-contained. It requires zero changes to the kernel.

(However a new TAINT_KPATCH flag would be a good idea, and we do anticipate some minor changes to kprobes and ftrace for better compatibility.)

- The use of stop_machine() will enable an important not-yet-implemented feature to call a user-supplied callback function at loading time which can be used to atomically update data structures when applying a patch. I don't see how such a feature would be possible with the kGraft approach.

- kpatch applies patches immediately without having to send signals to sleeping processes, and without having to hope that those processes handle the signal appropriately.

- kpatch's patching behavior is more deterministic because stop_machine() ensures that all tasks are sleeping and interrupts are disabled when the patching occurs.

- kpatch already supports other cool features like:
- removing patches and rolling back to the original functions
- atomically replacing existing patches
- incremental patching
- loading multiple patch modules
We should see soon enough on the kernel mailing list whether kGraft or Kpatch will prevail, otherwise how well the two will work together.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. 17-Way Linux Graphics Card Comparison With Civilization Beyond Earth
  2. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  3. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  4. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
Latest Linux News
  1. Intel 2.99.917 X.Org Driver Released, 3.0 Release Finally Near
  2. Server-Side XCB Is Being Discussed For The X.Org Server
  3. Adreno A4xx Rendering With Freedreno Takes Shape
  4. Linux 3.19-rc1 Kernel Released Ahead Of Schedule
  5. Civilization: Beyond Earth Linux GPU/Driver Benchmarks
  6. X.Org Server 1.16.3 Released To Fix Security Issues
  7. Linux 3.19 Merge Window Closes Ahead Of Schedule
  8. MIPS R6 Architecture Now Supported By GCC
  9. LowRISC To Feature Tagged Memory & Minion Cores
  10. Intel Skylake Audio Support For Linux 3.19
Latest Forum Discussions
  1. Speeding up systemd networking service
  2. Major Performance Breakthrough Discovered For Intel's Mesa Driver
  3. Looking for an nVidia GPU, but not sure how well they are supported.
  4. Need some hand holding with upgrading xserver
  5. FPS capped on Linux (AMD fglrx drivers)
  6. Are there an app using HSA ?
  7. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems
  8. XLennart: A Game For Systemd Haters With Nothing Better To Do