On Tue, 13 Jun 2017, Joe Lawrence wrote: > 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. Ok, I mixed two different things into one. Yes, this is a valid use case. > 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 I'm gonna pretend I didn't read this. > 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. I'd worry about that later. If we ever come upon that. Thanks, Miroslav -- 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
