Re: [RFC PATCH 3/4] livepatch: Add "replaceable" attribute to klp_patch

[Song Liu]

On Mon, Apr 6, 2026 at 2:12 PM Joe Lawrence <joe.lawrence@xxxxxxxxxx> wrote:
[...]
> > > > - The regular livepatches are cumulative, have the replace flag; and
> > > >   are replaceable.
> > > > - The occasional "off-band" livepatches do not have the replace flag,
> > > >   and are not replaceable.
> > > >
> > > > With this setup, for systems with off-band livepatches loaded, we can
> > > > still release a cumulative livepatch to replace the previous cumulative
> > > > livepatch. Is this the expected use case?
> > >
> > > That matches our expected use case.
> >
> > If we really want to serve use cases like this, I think we can introduce
> > some replace tag concept: Each livepatch will have a tag, u32 number.
> > Newly loaded livepatch will only replace existing livepatch with the
> > same tag. We can even reuse the existing "bool replace" in klp_patch,
> > and make it u32: replace=0 means no replace; replace > 0 are the
> > replace tag.
> >
> > For current users of cumulative patches, all the livepatch will have the
> > same tag, say 1. For your use case, you can assign each user a
> > unique tag. Then all these users can do atomic upgrades of their
> > own livepatches.
> >
> > We may also need to check whether two livepatches of different tags
> > touch the same kernel function. When that happens, the later
> > livepatch should fail to load.
> >
> > Does this make sense?
> >
>
> I haven't been following the thread carefully, but could the Livepatch
> system state API (see Documentation/livepatch/system-state.rst) be
> leveraged somehow instead of adding further replace semantics?

AFAICT, system state will not help Yafang's use case.

Thanks,
Song