Re: [RFC] GCC support for live-patching

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

Hi, Nicolai and Miroslav,

both of you asked for the details why our internal customer “is so keen about live patch code size” (why -flive-patching=inline-only-static is so 
important to them).  here is more details I got from them (with some update):

   Our use case is different from kGraft. Linux kernel patching involves modification of a single copy of text, in our case we can have thousands of user processes we'll have to patch. As number of candidate functions increase, so will the set of pages that will have to be modified for each process. We attempt to minimize amount of private memory consumed by each process.

   We use different infrastructure and tools from kGraft implementation. Solutions or tools that work there do not necessarily work or can be adopted by us.

   My strong preference is to not adapt online patching to global function inlining.

I hope that the above is clear. and for them to use GCC’s live patching feather, -flive-patching=inline-only-static is a must. 

thanks.

Qing


> On Oct 23, 2018, at 2:33 PM, Qing Zhao <qing.zhao@oracle.com> wrote:
>>> 
>>> however,  -flive-patching = [only-inline-static | inline-clone] are
>>> necessary.
>> 
>> It would be interesting to learn why that internal customer is so keen
>> about live patch code size? I mean either their live patch creation is
>> somehow automated or not.
> 
> My understanding is that their patch creation is mainly by hand. as you mentioned before,  it will be very tedious and
> error-prone in step 3, therefore they want to control the impacted function list as small as possible with reasonable run-time
> performance. 
> 
> I am not sure how easily for them to come up with a good tool for step 3 for their application. 



>>>>> On Oct 23, 2018, at 4:11 AM, Miroslav Benes <mbenes@suse.cz> wrote:
>>> the major functionality we want is:   to Only enable static inlining for live patching for one 
>>> of our internal customers.   the major purpose is to control the patch code size explosion and
>>> debugging complexity due to too much inlining of global functions for the specific application.
>> 
>> I hoped for more details, but ok.
> at this time, this is the details I have. I can ask more if more details are needed.