[kpatch] Stacking patches which introduce new data

Jessica Yu jeyu at redhat.com
Thu Sep 22 20:38:50 UTC 2016


+++ Ross Lagerwall [21/09/16 16:47 +0100]:
>On 09/20/2016 03:25 PM, Josh Poimboeuf wrote:
>>On Tue, Sep 20, 2016 at 02:05:36PM +0100, Ross Lagerwall wrote:
>>>Hi,
>>>
>>>The recommended way of applying multiple patches is to apply cumulative
>>>patches on top of the existing ones [1].
>>>
>>>If the first patch introduces some new static/global data, the second patch,
>>>being cumulative, will define the same new static/global data. When the
>>>second patch is loaded, it will use its own copy of the new data which may
>>>not contain the same values as the existing data from patch 1.
>>>
>>>Has this problem been considered at all? Are there any known solutions?
>>>
>>>[1] https://www.redhat.com/archives/kpatch/2015-November/msg00001.html
>>
>>Hi Ross,
>>
>>Hm, I don't think we've ever considered this issue.  At least in my
>>experience, I've never needed to add a global variable which needed to
>>keep its value across a cumulative update.
>
>Fair enough.
>
>>
>>Is this more of a theoretical question, or did you encounter this issue
>>with a real patch?
>>
>
>It's more of a theoretical question. I was wondering if this would 
>cause issues when patching a machine over a long period of time. But 
>if you think these types of patches wouldn't be needed, then perhaps 
>its not a problem.

Interesting question. I don't think we've ever considered this case
directly, but that's not to say it'd never come up. I would imagine
though that handling such dependencies between old and new patch
modules would quickly become cumbersome...

In this particular scenario though, I think the patch author could
probably use load hooks+kallsyms tricks to, for example, copy the old
values of the static/global variables from the old patch module and
assign to its new static/global variables. Hacky, but it'd probably
work.




More information about the kpatch mailing list