[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v4 04/12] livepatch: Implement pre-|post- apply|revert hooks



On 9/28/19 4:12 PM, Pawel Wieczorkiewicz wrote:
> This is an implementation of 4 new livepatch module vetoing hooks,
> that can be optionally supplied along with modules.
> Hooks that currently exists in the livepatch mechanism aren't agile
> enough and have various limitations:
> * run only from within a quiescing zone
> * cannot conditionally prevent applying or reverting
> * do not have access to the module context
> To address these limitations the following has been implemented:
> 1) pre-apply hook
>   runs before the apply action is scheduled for execution. Its main
>   purpose is to prevent from applying a livepatch when certain
>   expected conditions aren't met or when mutating actions implemented
>   in the hook fail or cannot be executed.
> 
> 2) post-apply hook
>   runs after the apply action has been executed and quiescing zone
>   exited. Its main purpose is to provide an ability to follow-up on
>   actions performed by the pre- hook, when module application was
>   successful or undo certain preparation steps of the pre- hook in
>   case of a failure. The success/failure error code is provided to
>   the post- hooks via the rc field of the payload structure.
> 
> 3) pre-revert hook
>   runs before the revert action is scheduled for execution. Its main
>   purpose is to prevent from reverting a livepatch when certain
>   expected conditions aren't met or when mutating actions implemented
>   in the hook fail or cannot be executed.
> 
> 4) post-revert hook
>   runs after the revert action has been executed and quiescing zone
>   exited. Its main purpose is to perform cleanup of all previously
>   executed mutating actions in order to restore the original system
>   state from before the current module application.
>   The success/failure error code is provided to the post- hooks via
>   the rc field of the payload structure.
> 
> The replace action performs atomically the following actions:
> - revert all applied modules
> - apply a single replacement module.
> With the vetoing hooks in place various inter-hook dependencies may
> arise. Also, during the revert part of the operation certain vetoing
> hooks may detect failing conditions that previously were satisfied.
> That could in turn lead to situation when the revert part must be
> rolled back with all the pre- and post- hooks re-applied, which again
> can't be guaranteed to always succeed.
> The simplest response to this complication is to disallow the replace
> action completely on modules with vetoing hooks.
> 
> Signed-off-by: Pawel Wieczorkiewicz <wipawel@xxxxxxxxx>
> Reviewed-by: Andra-Irina Paraschiv <andraprs@xxxxxxxxxx>
> Reviewed-by: Petre Eftime <epetre@xxxxxxxxxx>
> Reviewed-by: Martin Pohlack <mpohlack@xxxxxxxxx>
> Reviewed-by: Norbert Manthey <nmanthey@xxxxxxxxx>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Reviewed-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.