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