Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 15 Jun 2019 15:47:36 -0500
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
        Joe Lawrence <joe.lawrence@redhat.com>,
        Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
        Nicolai Stange <nstange@suse.de>,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/5] livepatch: new API to track system state changes
Message-ID: <20190615204736.coc2gbgffahkirnz@treble>
References: <20190611135627.15556-1-pmladek@suse.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20190611135627.15556-1-pmladek@suse.com>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jun 11, 2019 at 03:56:22PM +0200, Petr Mladek wrote:
> Hi,
> 
> this is another piece in the puzzle that helps to maintain more
> livepatches.
> 
> Especially pre/post (un)patch callbacks might change a system state.
> Any newly installed livepatch has to somehow deal with system state
> modifications done be already installed livepatches.
> 
> This patchset provides, hopefully, a simple and generic API that
> helps to keep and pass information between the livepatches.
> It is also usable to prevent loading incompatible livepatches.
> 
> There was also a related idea to add a sticky flag. It should be
> easy to add it later. It would perfectly fit into the new struct
> klp_state.
> 
> Petr Mladek (5):
>   livepatch: Keep replaced patches until post_patch callback is called
>   livepatch: Basic API to track system state changes
>   livepatch: Allow to distinguish different version of system state
>     changes
>   livepatch: Documentation of the new API for tracking system state
>     changes
>   livepatch: Selftests of the API for tracking system state changes

I confess I missed most of the previous discussion, but from a first
read-through this seems reasonable, and the code looks simple and
self-contained.

-- 
Josh