On Tue, Apr 7, 2026 at 10:54 AM Song Liu <[email protected]> wrote: > > On Mon, Apr 6, 2026 at 2:12 PM Joe Lawrence <[email protected]> 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.
That sounds like a viable solution. I'll look into it and see how we can implement it. > > > > > > 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. Right. -- Regards Yafang
