GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)
Qing Zhao
qing.zhao@oracle.com
Thu Sep 27 16:40:00 GMT 2018
Thanks, Martin, for all these interesting information.
Looks like that a more general option to help live-patching is needed.
I will do a little more study on this direction.
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
>
> ...
>>>>>
>>>>>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
>>>>>> comdat_can_be_unshared_p predicates. Similar problem happens to clones created
>>>>>> by ipa-cp.
>>>>>>
>>>>>> I guess we want to disable localization and cloning in this case as well.
>>>>>> I wonder what else.
>>>>>
>>>>> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
>>>>>
>>>>> Qing
>>>>>>
>>>>>> Honza
>>>
More information about the Gcc-patches
mailing list