On Thu, Nov 10, 2016 at 04:48:33PM +0100, Miroslav Benes wrote: > 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. Yes, the gcc folks I've talked to seem to agree. > > 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. I have some doubts about whether it would noticeably impact performance. As far as I can tell these optimizations are quite rare. FWIW, I've asked some gcc folks about the feasibility of something like a '-fpreserve-function-abi' option. But I'm not holding my breath. It seems like a hard problem. > > 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. Great, thanks! I think your experiences with the gcc optimizations and with the various patch building tools make you a great candidate for this. -- Josh -- 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
