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

On Wed, Jun 24, 2026 at 9:56 PM Petr Mladek <[email protected]> wrote:
>
> 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 <[email protected]>]
>   + commit adb68ed26a3e922 ("livepatch: Add "replace" sysfs
>         attribute") [Jun 2024, Yafang Shao <[email protected]>]
>
> I am not sure if Wardenjohn and Yafang made the changes for the same
> user or they were independent.

We have migrated all non-replace livepatches to the cumulative
livepatch model. I find the atomic-replace mode particularly
beneficial, as it significantly simplifies kernel development. This
motivates me to continue enhancing the atomic-replace mode to ensure
it covers all use cases.

[...]

-- 
Regards
Yafang