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

[Martin Jambor]

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 <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.

>
> 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

>
> a little confused here.
>
> thanks.
>
> Qing
>> On Sep 27, 2018, at 7:19 AM, Martin Jambor <mjambor@suse.cz> wrote:
>> 
>> Hi,
>> 
>> (this message is a part of the thread originating with
>> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)
>> 
>> On Thu, Sep 27 2018, Jan Hubicka wrote:
>>>>> If you make this to be INTERPOSABLE (which means it can be replaced by different
>>>>> implementation by linker and that is probably what we want for live patching)
>>>>> then also inliner, ipa-sra and other optimization will give up on these.
>>>> 
>>>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>>>> is present? then we should avoid all issues?
>>> 
>>> It seems to be reasonable direction I think, because it is what really happens
>>> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
>>> happen at runtime, but it is an approximation and we may introduce something like
>>> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
>>> I wonder if -finline-only-static is good name for the flag though, because it
>>> does a lot more than that.  Maybe something like -flive-patching?
>>> How much is this all tied to one particular implementation of the feature?
>> 
>> We have just had a quick discussion with two upstream maintainers of
>> Linux kernel live-patching about this and the key points were:
>> 
>> 1. SUSE live-patch creators (and I assume all that use the upstream
>>   live-patching method) use Martin Liska's (somewhat under-documented)
>>   -fdump-ipa-clones option and a utility he wrote
>>   (https://github.com/marxin/kgraft-analysis-tool) to deal with all
>>   kinds of inlining, IPA-CP and generally all IPA optimizations that
>>   internally create a clone.  The tool tells them what happened and
>>   also lists all callers that need to be live-patched.
>> 
>> 2. However, there is growing concern about other IPA analyses that do
>>   not create a clone but still affect code generation in other
>>   functions.  Kernel developers have identified and disabled IPA-RA but
>>   there is more of them such as IPA-modref analysis, stack alignment
>>   propagation and possibly quite a few others which extract information
>>   from one function and use it a caller or perhaps even some
>>   almost-unrelated functions (such as detection of read-only and
>>   write-only static global variables).
>> 
>>   The kernel live-patching community would welcome if GCC had an option
>>   that could disable all such optimizations/analyses for which it
>>   cannot provide a list of all affected functions (i.e. which ones need
>>   to be live-patched if a particular function is).
>> 
>>   I assume this is orthogonal to the proposed -finline-only-static
>>   option, but the above approach seems superior in all respects.
>> 
>> 3. The community would also like to be involved in these discussions,
>>   and therefore I am adding live-patching@vger.kernel.org to CC.  On a
>>   related note, they will also have a live-patching mini-summit at the
>>   Linux Plumbers conference in Vancouver in November where they plan to
>>   discuss what they would like GCC to provide.
>> 
>> Thanks,
>> 
>> Martin
>>