Hi all, On IRC, Peter expressed some concern about -flive-patching, specifically that the flag isn't compatible with LTO. The upstream kernel currently doesn't support LTO, but Android is using it with LLVM: https://source.android.com/devices/tech/debug/kcfi And there seems to be progress being made in that direction for upstream. Live patching has at least the following issues with LTO: - For source-based patch generation (klp-convert and friends), the GCC manual says that -flive-patching is incompatible with LTO. Does anybody know if that's a hard incompatibility, or can it be fixed? Also, what about the performance implications of this flag with LTO? Might they become more pronounced? Also I wonder if -fdump-ipa-clones works with LTO? I also wonder about the future of source-based patch generation with LLVM. Will it also have -flive-patching and -fdump-ipa-clones flags? - For binary-based patch generation (kpatch-build), we currently diff objects at a per-compilation-unit level. That would have to be changed to work on vmlinux.o instead. - Objtool would also have to be changed to work on vmlinux.o. It's currently not optimized for large files, and the per-.o whitelisting would need to be fixed. And there may be other issues lurking. Also, thinking about objtool in this context has given me another idea, which might allow us to get rid of the use of -flive-patching and -fdump-ipa-clones altogether (which are both nasty and way too compiler-dependent): Since objtool is already reading every function in the kernel, it could create a checksum associated with each function, based on all the instructions (both within the function and any alternatives or other special sections it relies on). The function checksums could be written to a file. Then, when a patch file is applied and the kernel rebuilt, the checksum files could be compared to determine exactly which functions have changed at a binary level. Thoughts? Any reasons why that wouldn't work? And, if we wanted to take the idea even further, objtool could have the ability to write the changed functions to a new object file. Voila, we now pretty much have kpatch-build :-) (Though whether this is better than source-based patch generation is certainly an open question.) -- Josh
