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

[Petr Mladek <pmladek@suse.com>]

On Tue 2026-06-23 11:40:31, Miroslav Benes wrote:
> Hi,
> 
> On Sun, 7 Jun 2026, Yafang Shao wrote:
> 
> > Convert the replace attribute from a boolean to a u32 to function as a
> > "replace set." A newly loaded livepatch will now atomically replace any
> > existing patch belonging to the same set. There can only ever be one active
> > livepatch for a given replace_set number.
> > 
> > This change currently supports function replacement only. Livepatches that
> > belong to different replace sets cannot modify the same function. If a new
> > livepatch attempts to modify a function already modified by an older
> > livepatch from a different replace_set, the loading of the new livepatch
> > will be refused.
> > 
> > Similarly, for the KLP state, livepatches belonging to different replace
> > sets cannot use the same state ID. The system will refuse to load a new
> > livepatch if it uses a state ID already in use by an older livepatch from
> > a different replace_set.
> > 
> > For the KLP shadow variable mechanism, developers must assign unique shadow
> > IDs to livepatches that belong to different replace sets.
> > 
> > Support for replace_set compatibility with KLP state and shadow variables
> > will be implemented after Petr's KLP state transfer work is completed [0].
> > 
> > Other user-visible changes include:
> > - The non-replace model is now deprecated
> > - /sys/kernel/livepatch/livepatch_XXX/replace attribute is replaced by
> >   /sys/kernel/livepatch/livepatch_XXX/replace_set
> 
> I will add my feedback here because the thread where it would belong to is 
> more about details now. I am sorry that I got to it later than I wanted 
> to.
> 
> What I like about the current state (non-replace and replace_all patches) 
> is that it is simple when it comes to the code and it is agnostic to 
> different use cases as we know them. Yes, it can lead to really 
> problematic scenarios on users' side but the kernel code is 
> relatively simple and flexible to allow that. As a distributor we chose 
> something that suits our needs and what we think suits our customers as 
> well. However, it is a downstream choice and implementation.
> 
> Now we learnt that some users would welcome a specific use case of keeping 
> parallel live patches applied on their system and they lack the kernel 
> support for that. That is ok and we should do something about that. There 
> are two things which I am concerned about though.
> 
> 1. I think that we should not leave our existing users (which we do not 
> know much about) behind and regress. I mean we should still allow the same 
> level of flexibility. If not possible, it should be seriously thought 
> through. I am talking about non-replace patches here.

Good point! We do not know about all existing users.

We have already changed the behavior in the past but it has been
relatively long time ago. And it was related to introducing
the "atomic replace":

  + commit 0b3d52790e1cfd6b ("livepatch: Remove signal sysfs attribute
	[Jan 2019]
  + commit d67a53720966f2ef ("livepatch: Remove ordering (stacking)
	of the livepatches")  [Jan 2019]
  + commit e1452b607c48c642c ("livepatch: Add atomic replace")
	[Jan 2019]
  + commit 958ef1e39d24d6cb8 ("livepatch: Simplify API by removing
	registration step") [Jan 2019]

IMHO, we hoped that people would start using the concept of
"cumulative livepatches" and stop using the no-replace mode at all.

Obviously, some users keep using the no-replace mode. And it causes
problems. I am pretty sure that it motivated the following changes:

  + commit 3dae09de4061671 ("livepatch: Add stack_order sysfs
	attribute") [Oct 2024. Wardenjohn <zhangwarden@gmail.com>]
  + commit adb68ed26a3e922 ("livepatch: Add "replace" sysfs
	attribute") [Jun 2024, Yafang Shao <laoar.shao@gmail.com>]

I am not sure if Wardenjohn and Yafang made the changes for the same
user or they were independent.

Another question is whether there are other users who are managing
the dependencies another way or were not able to contribute
to the kernel.

My view:

I believe that there are only very few users who create livepatches.
And they should have capable kernel developers. Because creating
livepatches is not trivial, requires kernel development knowledge,
and some infrastructure.

It is clear that some companies use the non-replace mode for some
reason. But I believe that they have problems to manage them
a safe way.


> 2. Slightly connected. We should not optimize too much for specific 
> scenarios. It seems perfectly fine to introduce a specific feature which 
> helps someone but I am concerned about restricting different use cases at 
> the same time. The latest discussion next door dives into very specific 
> scenarios and my question is "Do we really care?". The user (either a 
> distributor or anyone else) can choose what they want to implement in the 
> end (policy) and how to maintain it (a distributor will typically refuse 
> to support a system with a user applied live patches not provided by the 
> distributor).

> I think that latest proposals in the other thread go in the right 
> direction if I understand them correctly but I also think that we should 
> keep the above in mind (or disagree with me please).

I personally see the proposed changes as another evolution/replacement
of the too-wild and hard-to-manage no-replace mode.

IMHO, the gain is:

    + atomic replace even for livepatches installed in parallel
    + more safety by avoiding conflicts in livepatched functions
	and shadow variable IDs.

the drawback is:

   + loose of a complete freedom (jungle)
   + atomic replace must be used to replace already livepatched function
   + two or more livepatches need to be replaced using a single
     cumulative livepatch when a new change brings dependency
     between them


> It might be difficult to keep the code simple and maintainable in the end 
> and it certainly would not have benefits as the original replace_set 
> proposal where it would all be very simple in the end (only one live patch 
> per function allowed which might lead to substantial code simplification 
> all around the stack).

I agree that we do not want to maintain three modes. We should add the
new approach only when it replaces to old unrestricted no-replace mode.

I personally believe that it is a good step forward and it should be
acceptable. 

Best Regards,
Petr