Re: [PATCH v3 3/7] livepatch: Support scoped atomic replace using replace_set

[Joe Lawrence <joe.lawrence@redhat.com>]

On Wed, Jun 17, 2026 at 03:52:27PM +0200, Petr Mladek wrote:
> On Tue 2026-06-16 16:15:17, Joe Lawrence wrote:
> > On Thu, Jun 11, 2026 at 02:58:39PM +0200, Petr Mladek wrote:
> > > On Tue 2026-06-09 18:00:55, Petr Mladek wrote:
> > > > On Sun 2026-06-07 21:16:55, Yafang Shao wrote:
> [ ... snip ... ]
> > I'm not against supercedes functionality, but continuing the
> > brainstorming: what about solution 1 (.replace_set=0 special) with a
> > special zero-day overlay?
> 
> I continue with the brainstorming ;-)
> 

Thanks for walking through it with me.  Your reply crossed with my note
to Yafang at nearly the same time.

> [ ... snip ... ]
> > So maybe it boils down to: is the supercedes big hammer desired and safe
> > enough to deploy?
> 
> I personally like the solution with a zero-terminated array of
> replace_sets:
> 
> 	struct patch {
> 	       [...]
> 	       unsigned int *replace_sets;
> 	       [...],
> 	};
> 
> , which would allow to build a cumulative livepatch which replaces
> known hotfixes out of box.
> 

Question on this at the bottom ...

> Note that the hotfix should not be allowed to modify a function or
> livepatch state which is modified by another livepatch. It would
> be dangerous. We should allow to solve this only by a cumulative
> livepatch.
> 

Agreed.

> IMHO, the OS vendor should not touch customer specific livepatches
> by default. The customer installed them for a reason. We should
> just refuse to install two conflicting livepatches. Where
> we could reliably compare only the livepatched functions.
> But it still is good because most livepatches only modify
> functions.
> 
> Plus, I would still allow to resolve the possible conflict by using
> the atomic replace. It could be done by a module-specific parameter.
> I would call it: override_replace_sets=X[,Y]... or so.
> 

Naming nitpick: "override_replace_sets" sounds like it may override the
"replace_sets" value and not supplement it.  But that's just an
implementation detail to bikeshed later :D 

> Finally, I assume that most users will keep using only the default
> replace_sets=0 [*]. They will never have to deal with another sets.
> 
> The non-default replace sets will be only for adventurous users
> who want to deal with the complexity and accept the risks.
> 
> [*] It we allow the zero-terminated array of replace_sets then
>     zero should not be the default. Or it could be but it would
>     be a special set which could never be replaced by anything
>     else than another zero replace set.
> 
>     The zero replace set might be for users who do not want to
>     deal with the complexity at all. For example, for an os-vendor
>     who does not want to release separate hotfixes.
> 

Hmm, I do like the default replace_sets=0 not dealing with the
complication of the replace sets.

But first, back to the larger question I mentioned at the beginning.

Originally there was:

  unsigned int replace_set;            /* the set I belong to */
  const unsigned int *supersedes;      /* other sets I also replace */

and now it's just:

  unsigned int *replace_sets;          /* sets I belong to AND replace? */

Could you trace through a few cycles of cumulative + hotfix releases with
this approach?  For example:

  Wed: klp-1a: cumulative    (replace_sets={1})
  Thu: klp-1b: hotfix        (replace_sets={2})     <- coexists with klp-1a
  Fri: klp-1c: hotfix v2     (replace_sets={2})     <- replaces klp-1b (same set)
  Mon: klp-2a: cumulative    (replace_sets={1,2})   <- replaces klp-1a AND wipes klp-1c *
  Tue: klp-2b: hotfix        (replace_sets={2})     <- coexists with klp-2a

[*] After klp-2a loads with {1, 2}, is it permanently in both sets?  Or
    does it just evict set 2 and then only occupy set 1 going forward?  The
    latter makes klp-2b's load straightforward.

I can read replace_sets two ways:

  1. Positional: { set [, eviction_set ...] } where the first element is
     the patch's own set and the rest are evicted on load.

  2. Flat: the patch belongs to every listed set equally.  But then how
     could klp-2b load into set 2 without replacing the entire
     cumulative klp-2a that also occupies it?

Thanks,
--
Joe