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

[Petr Mladek <pmladek@suse.com>]

On Wed 2026-09-30 11:03:19, 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 any 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, or
> 3. The new patch's provides id is listed in its obsoletes list
>    (the obsoletes relationship is symmetric).
> 
> The obsoletes relationship is symmetric: two livepatches that
> obsolete each other are mutually exclusive. Loading either one
> atomically removes the other, so they can never be enabled at the
> same time. This allows swapping between two independently prepared
> livepatches that cover the same scope, in either direction.

Honestly, I am confused by the 3rd rule and by the last paragraph.
It is not compatible with my understanding of the provides/obsoletes
semantic.

In my mental model, the provides and obsoletes define which
way is supported. Let me show an example, let's have:

 Livepatch A:
   + provides: 1
   + obsoletes:

 Livepatch B:
   + provides: 2
   + obsoletes: 1

 Livepatch C:
   + provides: 3
   + obsoletes: 1,2

 Livepatch D:
   + provides: 2
   + obsoletes: 1,3

How is this supposed to work, please?

In my mental model:

  Livepatch A:
     + can be replaced by B, C, or D because they all obsolete 1
     + can _not_ replace B, C, D because A does not obsolete 2 and/or 3.

  Livepatch B:
    + can be replaced by C because C obsoletes both 1 and 2
    + can be replaced by D beause D provides 2 and obsoletes 1
    + can't replace C or D because B neither provides not obsoletes 3.

  Livepatch C:
    + can be replaced by D because D provides and obsoletes
       all ids which are proviced and obsoleted by D

    + can replace D from the same reasons.


OK, I understand that it might be practical to allow replacing
the patches just because they are "conflicting". As a kind
of revert/downgrade.

It might help to rename "obsoletes" to "conflicts". And just
say that the livepatch replaces livepatch with the same id
in provides and also all conflicting patches.

But then I see another problem. We have three types of conflicts:

  1. same id in provides/obsoletes/conflicts
  2. same livepatches function
  3. same livepatch state id

It is weird that we would silently replace livepatches with 1st
type conflict. But we would refuse to load the livepatch with
the 2nd and/or 3rd type conflict.

Note that the inconsistent handling of conflicts exists in
this patch even when the array is called "obsoletes". My proposal
to rename it to "conflicts" just helped me to see this
inconsistence.

Any option/idea? Yet another naming?

One more thing, the commit message does not describe that
the livepatches might conflict when livepatching the same
function or using the same state id. It is important part
of the semantic and must be documented.

Best Regards,
Petr

PS: I am sorry but I won't be able to finish the review before
    the Plumbers conference. But I am happy that I have found
    the above problem. We could discuss it at the conference
    and come up with some sane naming and semantic.