On Wed, Sep 28, 2016 at 11:04:54AM +0100, Ross Lagerwall wrote: > 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.
It might be nice to do incremental patching instead of the cumulative patching we do today. But to do that, kpatch-build and livepatch/kpatch.ko would need to modified to be able to detect and manage dependencies between patches. I don't think we've really looked into what it would take to achieve that, but my feeling is that it wouldn't be trivial. -- Josh _______________________________________________ kpatch mailing list [email protected] https://www.redhat.com/mailman/listinfo/kpatch
