DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6069619D5F2
Date: Thu, 27 Jul 2017 16:36:00 -0500
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>, live-patching@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
        Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
        Chris J Arges <chris.j.arges@canonical.com>
Subject: Re: [PATCH] livepatch: add (un)patch hooks
Message-ID: <20170727213600.52rwakraq3yddojs@treble>
References: <1499868600-10176-1-git-send-email-joe.lawrence@redhat.com>
 <1499868600-10176-2-git-send-email-joe.lawrence@redhat.com>
 <20170717155144.GF32632@pathway.suse.cz>
 <20170719204952.4fyhtig3rbw7z4w4@treble>
 <20170720041723.35r6qk2fia7xix3t@treble>
 <c00d9372-6da3-e950-5d1d-fb46d86fea0e@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <c00d9372-6da3-e950-5d1d-fb46d86fea0e@redhat.com>
User-Agent: Mutt/1.6.0.1 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1886
Lines: 47

On Thu, Jul 27, 2017 at 04:43:58PM -0400, Joe Lawrence wrote:
> On 07/20/2017 12:17 AM, Josh Poimboeuf wrote:
> > - The pre-patch and pre-unpatch hooks can be run before the
> >   patching/unpatching process begins.
> 
> Hi Josh,
> 
> By "(un)patching process" are you referring to the klp_patch at large or
> each klp_object?  ie, would all klp_objects execute their hooks before
> anything is (un)patched?  Just trying to clarify.

I think they can be interleaved: call pre-patch hook for object A, patch
object A, call pre-patch hook for object B, patch object B, etc.  We'll
just have to document that each hook is specific to its own object, and
no assumptions can be made about the state of other objects.

So maybe the pre-patch hooks could be called from klp_patch_object() and
pre-unpatch hooks could be called from klp_unpatch_object().  That way
they're called from both patch enable/disable and module coming/going
contexts.

Or maybe it would be cleaner to call the hooks from the *callers* of
klp_patch/unpatch_object().  That would mean a couple of more call
sites, but at least the locations of the pre- hooks would be more
symmetrical with the post- hook locations.  For example,
klp_module_coming() would have both pre- and post- hook calls.

> > - The post-patch and post-unpatch hooks will need to be run from either
> >   klp_complete_transition() or klp_module_coming/going(), depending on
> >   whether the to-be-patched module is already loaded or is being
> >   loaded/unloaded.
> 
> You're suggesting that post-(un)patch-hooks:
> 
>   1 - Notify klp_objects when a KLP_(UN)PATCHED transition completes

Right. (From klp_complete_transition())

> and for subsequently loaded klp_objects (ie modules):
> 
>   2 - On load - notify it with current KLP_(UN)PATCHED state,
>       Steady state - same as (1) above.

Right. (From klp_module_coming/going())

-- 
Josh