This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)
- From: Qing Zhao <qing dot zhao at oracle dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Martin Jambor <mjambor at suse dot cz>, live-patching at vger dot kernel dot org, gcc Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Oct 2018 10:12:56 -0500
- Subject: Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)
- References: <AEAA5E48-127A-41B7-8082-274948F4BE96@oracle.com> <CADzB+2m7fJ08MPpND9gzn2jf=vLKBxTOV5QJPMKQYcOwhw+pCg@mail.gmail.com> <alpine.LSU.2.20.1809261520360.16707@zhemvz.fhfr.qr> <CADzB+2=OzZ8t67=nD4-FmWWQdrYj2C5_nieaFKNvfTTvSwAERg@mail.gmail.com> <5263e463-96d1-7fc5-ddff-26efa82df25f@redhat.com> <CADzB+2kgoG8iySkLPDhLpinRAseHRX2c_VOtyh8uf01e0qPoQg@mail.gmail.com> <20180926150649.GD61973@kam.mff.cuni.cz> <C1E77C40-5983-4D5D-A57F-525993B1C8F2@oracle.com> <20180926171642.GG61973@kam.mff.cuni.cz> <131EB12C-DC35-4B3C-9F89-40EBA5317261@oracle.com> <20180927085829.GJ61973@kam.mff.cuni.cz> <ri6sh1vdte8.fsf@suse.cz> <817E4C4A-F81B-4E09-9645-04E38A1B9E74@oracle.com> <ri6d0ssu4rt.fsf@suse.cz> <5CB6BDBE-3F49-4BFE-AF10-5E8181C49181@oracle.com> <1a023bdc-28a6-eb41-b449-4d096f12064f@suse.cz> <048D9997-B7AF-444A-BF7E-79944DE8F174@oracle.com> <add5773e-0cea-58c9-b458-bf256f81d057@suse.cz>
> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@suse.cz> wrote:
>>>>
>>>> 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.
>>
>> So, for cloned functions, you have to analyze them case by case manually to see their callers?
>
> No, the tool should provide complete list of affected functions.
So, the tool will provide the callers of the cloned routine? then we will patch the callers of the cloned routine, Not the cloned routine itself?
>
>> why not just disable ipa-cp or ipa-sra completely?
>
> Because the optimizations create function clones, which are trackable with my tool
> and one knows then all affected functions.
Okay. I see.
>
> You can disable the optimizations, but you'll miss some performance benefit provide
> by compiler.
>
> Note that as Martin Jambor mentioned in point 2) there are also IPA optimizations that
> do not create clones. These should be listed and eventually disabled for kernel live
> patching.
Yes, such IPA analyzes should be disabled. we need to identify a complete list of such analyzes.
thanks.
Qing