Hi,
first, I am sorry that I answer this non-trivial mail so late.
I know that it might be hard to remember the context.
On Mon 2019-06-24 12:26:07, Nicolai Stange wrote:
> Petr Mladek writes:
> > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> > index 24c4a13bd26c..61464271982
On Tue 2019-06-11 15:56:25, Petr Mladek wrote:
> It might happen that an older change is not enough and the same system
> state has to be modified another way. Different changes need to get
> distinguished by a version number added to struct klp_state.
>
> The version can also be used to prevent l
Petr Mladek writes:
> ---
> include/linux/livepatch.h | 2 ++
> kernel/livepatch/core.c | 8
> kernel/livepatch/state.c | 40 +++-
> kernel/livepatch/state.h | 9 +
> 4 files changed, 58 insertions(+), 1 deletion(-)
> create mode 10064
On Fri, Jun 21, 2019 at 10:09:11AM -0400, Joe Lawrence wrote:
> More word play: would it be any clearer to drop the use of
> "modification" when talking about klp_states? Sometimes I read
> modification to mean a change to a klp_state itself rather than the
> system at large.
After reading throug
On Tue, Jun 11, 2019 at 03:56:25PM +0200, Petr Mladek wrote:
> The atomic replace runs pre/post (un)install callbacks only from the new
> livepatch. There are several reasons for this:
>
> + Simplicity: clear ordering of operations, no interactions between
> old and new callbacks.
>
> +
> +/* Check if the patch is able to deal with the given system state. */
> +static bool klp_is_state_compatible(struct klp_patch *patch,
> + struct klp_state *state)
> +{
> + struct klp_state *new_state;
> +
> + new_state = klp_get_state(patch, state->id);
>
The atomic replace runs pre/post (un)install callbacks only from the new
livepatch. There are several reasons for this:
+ Simplicity: clear ordering of operations, no interactions between
old and new callbacks.
+ Reliability: only new livepatch knows what changes can already be made
7 matches
Mail list logo
