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

[Qing Zhao <qing.zhao@oracle.com>]

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?

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? 

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
>