Re: [RFC PATCH v4 3/4] livepatch: Implement replace set for scoped atomic replace

Yafang Shao <[email protected]>
Newsgroups org.kernel.vger.live-patching
Message-ID <CALOAHbBVgoKR-tUHndGUUCjF2uDSPa0yEG=u8GK_=-BTnbkxxQ@mail.gmail.com>
On Wed, Aug 5, 2026 at 7:06 AM Song Liu <[email protected]> wrote:
>
> On Mon, Aug 3, 2026 at 11:50 PM Yafang Shao <[email protected]> wrote:
> [...]
> >  /*
> > - * Check that the new livepatch will not break the existing system states.
> > - * Cumulative patches must handle all already modified states.
> > - * Non-cumulative patches can touch already modified states.
> > + * Refuse loading a livepatch which would want to modify a
> > + * function which is already livepatched with the livepatch
> > + * with another "provides".
> >   */
>
> The comment above is not really accurate. This function doesn't
> really check "provides" or "obsoletes". Also, as long as the old
> patch's "provides" is in the new patches "obsoletes" or "provides",
> this replace is allowed (the comment doesn't mention "obsoletes". )

This is already handled by klp_patch_replaceable() in
klp_is_patch_compatible(). However, it would be clearer to move the
klp_patch_replaceable() check into klp_has_function_conflict() and
update the comments accordingly.

>
> > +static bool klp_has_function_conflict(struct klp_patch *patch,
> > +                                     struct klp_patch *old_patch)
> > +{
> > +       struct klp_object *obj, *old_obj;
> > +       struct klp_func *func;
> [...]
> >
> > +       # Always add provides ID to obsoletes (even if provides=0)
> > +       # This ensures the new patch replaces old patches with the same provides ID
>
> Do we really need th toolchain to enforce this? AFAICT, the kernel already
> guranteed "provides" means "obsoletes".

Dropping this enforcement simplifies the code logic. I will remove it
in the next version.

>
> Also, it will be great if we can add some basic tests for this. We are
> working on some new test framework for klp-build toolchain. But we
> don't have to wait for that. It is always good to add some tests for
> a major feature change.

Sure. I will add self tests in the next version.

-- 
Regards
Yafang
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.