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

[Miroslav Benes <mbenes@suse.cz>]

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.

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

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

Regards,
Miroslav