Re: [kpatch] Stacking patches which introduce new data
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/msg1.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 kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
Re: [kpatch] Stacking patches which introduce new data
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/msg1.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 kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
Re: [kpatch] Stacking patches which introduce new data
+++ 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/msg1.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. ___ kpatch mailing list kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
Re: [kpatch] Stacking patches which introduce new data
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/msg1.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. Thanks, -- Ross Lagerwall ___ kpatch mailing list kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
Re: [kpatch] Stacking patches which introduce new data
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/msg1.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. Is this more of a theoretical question, or did you encounter this issue with a real patch? -- Josh ___ kpatch mailing list kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
[kpatch] Stacking patches which introduce new data
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/msg1.html Thanks, -- Ross Lagerwall ___ kpatch mailing list kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
