On 09/22/2016 09:38 PM, Jessica Yu wrote:
+++ 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...
Have you ever considered building kpatch modules as differentials
against the previous kpatch? i.e. if you have one kpatch module loaded,
the second kpatch is built against the original source plus the source
patch for the first kpatch module.
In this case, the second kpatch could use the global variable from the
1st kpatch rather than introducing a second copy of it.
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.
Interesting approach :-)
--
Ross Lagerwall
_______________________________________________
kpatch mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/kpatch
