GCC Compiler Picks Up New Option To Help With Live Kernel Patching
Adding to the list of new features for GCC 9 due out early next year is a new -flive-patching= flag to help with scenarios like live Linux kernel patching.
This GCC live-patching support addition was done by Oracle and is about controlling the optimizations/behavior when wanting to compile code for the context of applying it as a live patch. In particular, for Linux kernel live patching to avoid system reboots when applying security/maintenance updates. With Oracle the focus is on their own Ksplice live kernel patching to avoid reboots but this work should also be relevant to the likes of SUSE's kGraft and Red Hat's Kpatch kernel live patching.
The -flive-patching= flag allows a value of inline-clone to only enable inlining and cloning optimizations or inline-only-static for only enable inlining of static functions. Of course, by default this flag is not relevant. The newly added documentation explains the importance of compiler optimization behavior on live-patching:
More details via this commit from Thursday introducing the new functionality for the upcoming GCC 9.1 stable release.
This GCC live-patching support addition was done by Oracle and is about controlling the optimizations/behavior when wanting to compile code for the context of applying it as a live patch. In particular, for Linux kernel live patching to avoid system reboots when applying security/maintenance updates. With Oracle the focus is on their own Ksplice live kernel patching to avoid reboots but this work should also be relevant to the likes of SUSE's kGraft and Red Hat's Kpatch kernel live patching.
The -flive-patching= flag allows a value of inline-clone to only enable inlining and cloning optimizations or inline-only-static for only enable inlining of static functions. Of course, by default this flag is not relevant. The newly added documentation explains the importance of compiler optimization behavior on live-patching:
If the compiler's optimization uses a function's body or information extracted from its body to optimize/change another function, the latter is called an impacted function of the former. If a function is patched, its impacted functions should be patched too.
The impacted functions are decided by the compiler's interprocedural optimizations. For example, inlining a function into its caller, cloning a function and changing its caller to call this new clone, or extracting a function's pureness/constness information to optimize its direct or indirect callers, etc.
Usually, the more IPA optimizations enabled, the larger the number of impacted functions for each function. In order to control the number of impacted functions and computed the list of impacted function easily, we provide control to partially enable IPA optimizations on two different levels.
More details via this commit from Thursday introducing the new functionality for the upcoming GCC 9.1 stable release.
Add A Comment