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: Martin Jambor <mjambor at suse dot cz>
- To: Qing Zhao <qing dot zhao at oracle dot com>, live-patching at vger dot kernel dot org
- Cc: gcc Patches <gcc-patches at gcc dot gnu dot org>, Martin Liska <mliska at suse dot cz>, live-patching at vger dot kernel dot org
- Date: Tue, 02 Oct 2018 10:33:26 +0200
- 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>
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
>>