Date: Wed, 14 Jun 2017 10:02:36 +0200 (CEST)
From: Miroslav Benes <mbenes@suse.cz>
To: Joe Lawrence <joe.lawrence@redhat.com>
cc: Jiri Kosina <jikos@kernel.org>, live-patching@vger.kernel.org,
        linux-kernel@vger.kernel.org, Josh Poimboeuf <jpoimboe@redhat.com>,
        Jessica Yu <jeyu@redhat.com>, Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH 0/3] livepatch: add shadow variable API
In-Reply-To: <8a4711b9-9536-3843-c737-50fab2536aa5@redhat.com>
Message-ID: <alpine.LSU.2.20.1706140957550.2139@pobox.suse.cz>
References: <1496341526-19061-1-git-send-email-joe.lawrence@redhat.com> <alpine.LSU.2.20.1706012202490.26873@cbobk.fhfr.pm> <bf7958e9-27c0-85a6-7de6-027051a25dae@redhat.com> <alpine.LSU.2.20.1706131217400.29266@pobox.suse.cz>
 <8a4711b9-9536-3843-c737-50fab2536aa5@redhat.com>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1613
Lines: 37

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