From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934827AbcKJQK5 (ORCPT ); Thu, 10 Nov 2016 11:10:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50546 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934554AbcKJQKz (ORCPT ); Thu, 10 Nov 2016 11:10:55 -0500 Date: Thu, 10 Nov 2016 10:10:53 -0600 From: Josh Poimboeuf To: Miroslav Benes Cc: live-patching@vger.kernel.org, Linux Kernel Mailing List , Joerg Roedel , jkosina@suse.cz, jeyu@redhat.com, pmladek@suse.cz Subject: Re: [PATCH RFC 0/2] livepatch: patch creation tooling proposal Message-ID: <20161110161053.heua3abuaekz4yy7@treble> References: <20161110153608.jsxlygej4r3ux42g@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 10 Nov 2016 16:10:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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