Re: [PATCH v12 5/9] livepatch: Implement provides and obsoletes for scoped atomic replace

[Petr Mladek <pmladek@suse.com>]

On Fri 2026-10-16 13:37:04, Yafang Shao wrote:
> The current bool replace flag is too coarse: it is either all or
> nothing. A livepatch with .replace=true replaces ALL existing
> livepatches, which is safe but inflexible. There is no way to have
> multiple independent livepatch sets coexist on the same system.
> 
> Replace it with a more flexible model using two new fields in
> struct klp_patch:
> 
> - provides: an unsigned int id identifying the changes made by
>   the related livepatch. Where the changes are a set
>   of modified objects, functions, and used callbacks,
>   shadow variable ids, and state ids.
> 
> - obsoletes: an optional array of unsigned int ids specifying
>   additional provides ids to be replaced. This allows a new patch
>   to explicitly obsolete patches from different scopes.
> 
> A new livepatch atomically replaces any existing livepatch that
> meets either of the following conditions:
> 
> 1. It has the same provides id as the new patch,
> 2. Its provides id is listed in the new patch's obsoletes list.
> 
> A new livepatch that does not replace an existing one can coexist
> with it. In this case, the two livepatches must not modify the same
> function, or use the state with the same id. Any attempt to load an
> incompatible livepatch will be rejected by the kernel.
> 
> klp-build gains -p/--provides and -r/--obsoletes options.  The two
> parameters are not validated in klp-build, since the compiler and the
> kernel handle invalid values.
> 
> Enable the CONFIG_KLP_HAS_PROVIDES compile-time marker now that the
> provides/obsoletes interface is implemented.
> 
> --- a/Documentation/ABI/testing/sysfs-kernel-livepatch
> +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
> @@ -47,13 +47,25 @@ Description:
>  		disabled when the feature is used. See
>  		Documentation/livepatch/livepatch.rst for more information.
>  
> -What:		/sys/kernel/livepatch/<patch>/replace
> -Date:		Jun 2024
> -KernelVersion:	6.11.0
> +What:		/sys/kernel/livepatch/<patch>/provides
> +Date:		Jun 2026
> +KernelVersion:	7.4.0
>  Contact:	live-patching@vger.kernel.org
>  Description:
> -		An attribute which indicates whether the patch supports
> -		atomic-replace.
> +		An attribute to show the provides id of this livepatch.
> +		Livepatches with the same provides id replace each other.
> +
> +What:		/sys/kernel/livepatch/<patch>/obsoletes
> +Date:		Jun 2026
> +KernelVersion:	7.4.0
> +Contact:	live-patching@vger.kernel.org
> +Description:
> +		An attribute to show the obsoletes ids of this livepatch.
> +		The obsoletes ids are a comma-separated list of provides
> +		ids that this patch obsoletes. When this livepatch is
> +		loaded, any existing livepatch whose provides id matches
> +		either this patch's provides id or any id in the obsoletes
> +		list will be atomically replaced.

This still describes the behavior in v10 where the obsoletes were
handled symetrically. It should remove patches only with the matching
provides.

>  
>  What:		/sys/kernel/livepatch/<patch>/stack_order
>  Date:		Jan 2025
> diff --git a/Documentation/livepatch/cumulative-patches.rst b/Documentation/livepatch/cumulative-patches.rst
> index 1931f318976a..5ce04424e09d 100644
> --- a/Documentation/livepatch/cumulative-patches.rst
> +++ b/Documentation/livepatch/cumulative-patches.rst
> @@ -2,33 +2,71 @@
>  Atomic Replace & Cumulative Patches
>  ===================================
>  
> -There might be dependencies between livepatches. If multiple patches need
> -to do different changes to the same function(s) then we need to define
> -an order in which the patches will be installed. And function implementations
> -from any newer livepatch must be done on top of the older ones.
> -
> -This might become a maintenance nightmare. Especially when more patches
> -modified the same function in different ways.
> -
> -An elegant solution comes with the feature called "Atomic Replace". It allows
> -creation of so called "Cumulative Patches". They include all wanted changes
> -from all older livepatches and completely replace them in one transition.
> -
> -Usage
> ------
> -
> -The atomic replace can be enabled by setting "replace" flag in struct klp_patch,
> -for example::
> -
> -	static struct klp_patch patch = {
> -		.mod = THIS_MODULE,
> -		.objs = objs,
> -		.replace = true,
> -	};
> -
> -All processes are then migrated to use the code only from the new patch.
> -Once the transition is finished, all older patches are automatically
> -disabled.
> +Livepatches are used to fix kernel bugs. New fixes need to be added over time.
> +The fixes might be independent, but they might also depend on each other. This
> +brings a challenge of how to keep the livepatched system safe and consistent.
> +
> +Part of the solution is the "Atomic Replace" feature, which allows the kernel to
> +atomically replace an existing livepatch with another one. These newer
> +livepatches are designed as "Cumulative Patches". They include all wanted
> +changes from all older livepatches and completely replace them in one
> +transition.
> +
> +The second part of the solution are ``provides`` and ``obsoletes`` fields in
> +``struct klp_patch``, which allow the installation of multiple livepatches in
> +parallel. A livepatch will atomically replace any already installed livepatch
> +whose ``provides`` id matches either the new patch's ``provides`` id or any id
> +in the new patch's ``obsoletes`` list.

Same here.

> This might be used to fix independent
> +problems separately, for example, the livepatches might be prepared by separate
> +teams focusing on particular functionality or a subsystem.

Otherwise, I like the patch. The code and documentation is nice a clean.

Note: We repeate some things several times in the documentation. It makes
      it harder to keep it consistent. But it is an existing problem.
      I think that we could do better but it is beyond the scope of
      this patchset.


With fixing the two outdated pieces of documentation:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

PS: I have to leave now. I hope that I'll be able to finish the review
    by the end of the week. I think that we are getting close to
    get it into linux-next. Well, I would like to put it there
    on top of the merge commit for-7.4. I still have to send
    the pull request...