Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

[Richard Biener <richard.guenther@gmail.com>]

On October 2, 2018 7:13:13 PM GMT+02:00, "Martin Liška" <mliska@suse.cz> wrote:
>On 10/2/18 5:12 PM, Qing Zhao wrote:
>> 
>>> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@suse.cz
><mailto: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?
>
>No, the tool does not list callers of affected functions. But function
>call ABI is reasonable
>live-patching boundary.
>
>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.
>
>That was promised to be done by Honza Hubička. He's very skilled in IPA
>optimizations and he's aware
>of optimizations that cause troubles for live-patching.

One could also compute the list of possibly affected functions from such semantic changes. 

Richard. 

>Martin
>
>> 
>> thanks.
>> 
>> Qing
>>