On 06/13/2017 06:19 AM, Miroslav Benes wrote: >> If you are referring to stacking livepatches ... to be honest I hadn't >> thought of that scenario. In that case, we might be able to get away >> with pushing something like this into the hash: >> >> klp #1: klp_shadow_attach(ptr, "shadow_var", ...) >> klp #2: klp_shadow_attach(ptr, "shadow_var_v2", ...) > > I thought this was the reason to have a string there. Otherwise, a > pointer to original data would be enough, wouldn't it? Well, one could attach multiple shadow variables to the same data structure, ie, one for each new data element. In the stacking case, you might add a spinlock in patch 1, then a linked-list in patch 2. Patched codepaths would then use klp_shadow_get(obj, "spinlock") or klp_shadow_get(obj, "list") as needed. Versioning shadow variables would be a bit more involved. You'd have to figure out if you A) convert existing shadow variables to the new format on livepatch module load, or B) convert on the fly, or C) handle none, v1, and v2 instances of the shadow variables. /head spins To be honest, I don't think we've never needed anything beyond basic shadow variables in kpatch, so I'm only speculating about their potential (ab)uses :) That said, since this patchset is introducing the API, it would be good to be reasonably flexible. -- Joe -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
