Messages in this thread | | | Date | Thu, 10 Nov 2016 10:10:53 -0600 | From | Josh Poimboeuf <> | Subject | Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal |
| |
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
| |