On Thu, 10 Nov 2016, Josh Poimboeuf wrote: > On Thu, Oct 27, 2016 at 09:35:48AM -0500, Josh Poimboeuf wrote: > > So here's my proposal: use the existing kernel build infrastructure. If > > klp relocations are needed, manually specify them with a new > > klp_module_reloc struct and corresponding KLP_MODULE_RELOC macro. Then > > run a post-processing tool called klp-convert which converts those > > klp_module_reloc structs into the sections, relocations, and symbols > > needed by the klp runtime code. > > I think the biggest blocker for this approach is detecting gcc > optimizations which break function ABI, i.e. Miroslav's presentation: > > http://www.linuxplumbersconf.org/2016/ocw//system/presentations/3573/original/pres_gcc.pdf > > Right now we have no way of finding all such cases. > > I think our options are: > > 1) Find a way for gcc to report when function ABI has been broken; This is the one I'd like to pursue in parallel to 3). But it is going to be long way I imagine. > 2) Disable all gcc optimizations which can break function ABI. Not sure > if this is even possible, but if so, we'd need to quantify the > performance impact. (Note we might be able to leave some options > enabled if they result in a function name change (e.g., > -fpartial-inlining, -fipa-sra, -fipa-cp)); or I don't think this is possible. I mean technically possible, because I'm almost sure some optimizations cannot be disabled easily. And also performance-wise. It could have a serious impact on the kernel with CONFIG_LIVEPATCH enabled. I consider this option a last resort. > 3) Stay with the status quo (kpatch-build?), since it has detection of > such optimizations "built in". Also possible. We could explore the usability of Joerg's asmtool for the purpose. https://github.com/joergroedel/asmtool It could be useful even if for the detection of changed functions. > Does anybody want to take ownership of this patch set and/or try to > explore the options further? I don't have any more bandwidth right now > (mainly due to the consistency model and porting objtool to DWARF). Sure. I can take it. I tried to write a similar tool, I saw kpatch-build sources and have a clue how it all works. On the other hand, no promises about a timeline. Miroslav -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
