Re: [PATCH v14 00/11] livepatch: Atomic replace feature

[Joe Lawrence]

On 11/29/2018 04:44 AM, Petr Mladek wrote:
> Hi,
> 
> I have an updated present for your mailboxes.
> 
> 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.
> 
> All the changes were simple in principle but they required quite
> some refactoring again :-( IMHO, the biggest change is renaming
> klp_init_lists() ->klp_init_patch_before_free(). It does all
> init actions that need to succeed before klp_free() functions
> can be safely called. The main motivation was the need to
> initialize also the new .kobj_alive flags.
> 
> 
> Changes against v13:
> 
>   + Rename old_addr -> old_func instead of new_func -> new_addr. [Josh]
> 
>   + Do not add the helper macros to define structures. [Miroslav, Josh]
> 
>   + Add custom kobj_alive flag to reliably handle kobj state. [Miroslav]
> 

Aside: I don't suppose that this could ever be folded into the kobject
code/data structure itself?  This seems like a common problem that
kobj-users will need to solve like this.

>   + Avoid renaming .forced flag to .module_put by calling klp_free
>     functions only with taken module reference. [Josh]
> 
>   + Use list_add_tail() instead of list_add() when updating the dynamic
>     lists of klp_object and klp_func structures. Note that this
>     required also updating the order of messages from the pre/post
>     callbacks in the selftest. [Josh, Miroslav]
> 

Updated self-tests ran fine for me, thanks for updating.

>   + Do not unnecessarily initialize ret variable in klp_add_nops(). [Miroslav]
> 
>   + Got rid of klp_discard_replaced_stuff(). [Josh]
> 
>   + Updated commit messages, comments and documentation, especially
>     the section "Livepatch life-cycle" [Josh, Miroslav]

Thank you for adding/revising this part.  It was pretty clear and it
helped to read this before going through the individual patches.

I don't have many code comments as the changes appear to safely and
correctly do what the say.  (We are at v14 after all :)  I mainly
compared the text and comments to the implementation and noted typos
(marked by substitution s/old/new) and awkward wordings (marked by
"re-wording suggestion").  That said, I ack'd each patch as I wouldn't
want these to hold up the patchset.

Thanks,

-- Joe