[RFC] GCC support for live-patching

[Qing Zhao]

> On Oct 19, 2018, at 8:45 AM, Andi Kleen <ak@linux.intel.com> wrote:
> 
> Qing Zhao <qing.zhao@oracle.com> writes:
> 
> I think you first need to define the problem better.
> 
>> If we want to control the patch code size,
> 
> Why is it even a useful goal to limit patch code size?

one of the initial major motivation of the whole task is for controlling the patch code size explosion due to too much inlining. 
please take a look at the original discussion on this:

https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html 
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html

> 
> Is it because you generate something manually and want to limit that
> work,

I think that this is one of the reasons. 
and as mentioned in my writeup, the targeted users of this new functionality is for live-patching users who generate
patches by hand. 

please take a look at section 1. A study of Kernel live patching schemes.

in which, it explains that these new options are for helping live-patching users who create patches entirely by hand, including kernel
live-patching scheme kGraft, and one of our internal customers. 

the major reason is to control the code size explosion of manual patches. It’s the request from our internal customer. 

> or is there some other reasons why patches cannot be as big as
> needed?

debuggability is another reason.

As Jeff law already mentioned in a very previous email:

“Presumably one of the cases where this capability is really helpful is
things like ksplice.   If you have a function with global scope that has
been potentially inlined, then it's a lot harder track down those
inlining points at DTRT.

We ran into this internally when looking at hot patching some of the
spinlock code in the kernel.  It would have been real helpful if the
kernel had been compiled with this kind of option :-)

So conceptually I can see value in this kind of option.
“

> 
> If it's the first perhaps the better fix would be better tools
> that automatically handle all IPA clones?

I think that the current option 
-fease-live-patching=inline-clone  -flive-patching-list

should automatically ONLY enabling inline+clone optimization (disable all other ipa optimization/analyses at the same time) and generate the impacted function
list for each of the function.

is this what you want?

or you have other idea on this?

thanks.

Qing

> AFAIK there is nothing else in the linux kernel life patching at least
> that would favour smaller patches over larger.
> 
> -And