[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180406221050.y7avkxjt4e23jojc@treble>
Date: Fri, 6 Apr 2018 17:10:50 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>,
Jason Baron <jbaron@...mai.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Jessica Yu <jeyu@...nel.org>,
Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] livepatch: Atomic replace feature
On Fri, Mar 23, 2018 at 01:00:20PM +0100, Petr Mladek wrote:
> The atomic replace allows to create cumulative patches. They
> are useful when you maintain many livepatches and want to remove
> one that is lower on the stack. In addition it is very useful when
> more patches touch the same function and there are dependencies
> between them.
>
> This version is heavily refactored and cleaned based on feedback from Josh.
> There are actually only three functional changes.
>
> It still passes the first draft of the selfttest from Joe that can
> be found at https://lkml.kernel.org/r/1520881024-29386-1-git-send-email-joe.lawrence@redhat.com
>
>
> Changes against v10:
>
> + Bug fixes and functional changes:
> + Handle Nops in klp_ftrace_handled() to avoid infinite loop [Mirek]
> + Really add dynamically allocated klp_object into the list [Petr]
> + Clear patch->replace when transition finishes [Josh]
>
> + Refactoring and clean up [Josh]:
> + Replace enum types with bools
> + Avoid using ERR_PTR
> + Remove too paranoid warnings
> + Distinguish registered patches by a flag instead of a list
> + Squash some functions
> + Update comments, documentation, and commit messages
> + Squashed and split patches to do more controversial changes later
Thanks again for all the changes. I think I like the general direction
of the patches now, even some of the later ones ;-)
Along with the minor comments from my other emails, I still have the
question about "does it make sense to enforce a stack anymore".
And of course I would really like to see the selftests in place first.
--
Josh
Powered by blists - more mailing lists