Messages in this thread | | | Date | Thu, 10 Nov 2016 16:48:33 +0100 (CET) | From | Miroslav Benes <> | Subject | Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal |
| |
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
| |