From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62028 invoked by alias); 2 Oct 2018 14:02:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62015 invoked by uid 89); 2 Oct 2018 14:02:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 14:02:20 +0000 Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3B10AAE52; Tue, 2 Oct 2018 14:02:18 +0000 (UTC) Subject: Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions) To: Qing Zhao , Martin Jambor Cc: live-patching@vger.kernel.org, gcc Patches References: <5263e463-96d1-7fc5-ddff-26efa82df25f@redhat.com> <20180926150649.GD61973@kam.mff.cuni.cz> <20180926171642.GG61973@kam.mff.cuni.cz> <131EB12C-DC35-4B3C-9F89-40EBA5317261@oracle.com> <20180927085829.GJ61973@kam.mff.cuni.cz> <817E4C4A-F81B-4E09-9645-04E38A1B9E74@oracle.com> <5CB6BDBE-3F49-4BFE-AF10-5E8181C49181@oracle.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <1a023bdc-28a6-eb41-b449-4d096f12064f@suse.cz> Date: Tue, 02 Oct 2018 14:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <5CB6BDBE-3F49-4BFE-AF10-5E8181C49181@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00090.txt.bz2 On 10/2/18 3:28 PM, Qing Zhao wrote: > >> On Oct 2, 2018, at 3:33 AM, Martin Jambor wrote: >> >> Hi, >> >> my apologies for being terse, I'm in a meeting. >> >> On Mon, Oct 01 2018, Qing Zhao wrote: >>> Hi, Martin, >>> >>> I have studied a little more on >>> >>> https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md >>> >>> in the Section “Usages”, from the example, we can see: >>> >>> the tool will report a list of affected functions for a function that will be patched. >>> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. >>> >>> My question: >>> >>> what’s the current action to handle the cloned functions from the >>> patched function due to ipa const-proposation or ipa sra, etc? >> >> If we want to patch an inlined, cloned, or IPA-SRAed function, we also >> patch all of its callers. > > take the example from the link: > > $ gcc /home/marxin/Programming/linux/aesni-intel_glue.i -O2 -fdump-ipa-clones -c > $ ./kgraft-ipa-analysis.py aesni-intel_glue.i.000i.ipa-clones > > [..skipped..] > Function: fls64/63 (./arch/x86/include/asm/bitops.h:479:90) > inlining to: __ilog2_u64/132 (include/linux/log2.h:40:5) > inlining to: ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82) > constprop: ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82) > inlining to: helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12) > inlining to: helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12) > > Affected functions: 5 > __ilog2_u64/132 (include/linux/log2.h:40:5) > ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82) > ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82) > helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12) > helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12) > [..skipped..] > > > if we want to patch the function “fls64/63”, what else functions we need to patch, too? my guess is: Hi. Yes, 'Affected functions' is exactly the list of functions you want to patch. > > **all the callers: > __ilog2_u64/132 > ablkcipher_request_alloc/1639 > helper_rfc4106_decrypt/3007 > helper_rfc4106_encrypt/3006 > **and: > ablkcipher_request_alloc.constprop.8/3198 > is the above correct? > > how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code? Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages. In this particular case there's no such caller function, so you're fine. Martin > > Qing > >> >>> >>> since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after >>> the patched function is changed, the same ipa const-propogation or ipa >>> sra will still happened? >> >> You don't. >> >> Martin >> >>> >