On Wed, Jun 17, 2026 at 03:52:27PM +0200, Petr Mladek wrote:

On Tue 2026-06-16 16:15:17, Joe Lawrence wrote:

quoted

On Thu, Jun 11, 2026 at 02:58:39PM +0200, Petr Mladek wrote:

quoted

On Tue 2026-06-09 18:00:55, Petr Mladek wrote:

quoted

On Sun 2026-06-07 21:16:55, Yafang Shao wrote:

[ ... snip ... ]

quoted

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 ... ]

quoted

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