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

Song Liu
2026-04-03T21:36:08Z

On Fri, Apr 3, 2026 at 1:55 PM Dylan Hatch <dylanbhatch@google.com> wrote:
[...]
> > IIRC, the use case for this change is when multiple users load various
> > livepatch modules on the same system. I still don't believe this is the
> > right way to manage livepatches. That said, I won't really NACK this
> > if other folks think this is a useful option.
>
> In our production fleet, we apply exactly one cumulative livepatch
> module, and we use per-kernel build "livepatch release" branches to
> track the contents of these cumulative livepatches. This model has
> worked relatively well for us, but there are some painpoints.
>
> We are often under pressure to selectively deploy a livepatch fix to
> certain subpopulations of production. If the subpopulation is running
> the same build of everything else, this would require us to introduce
> another branching factor to the "livepatch release" branches --
> something we do not support due to the added toil and complexity.
>
> However, if we had the ability to build "off-band" livepatch modules
> that were marked as non-replaceable, we could support these selective
> patches without the additional branching factor. I will have to
> circulate the idea internally, but to me this seems like a very useful
> option to have in certain cases.

IIUC, the plan is:

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

I think there are a few issues with this:
1. The "off-band" livepatches cannot be replaced atomically. To upgrade
"off-band' livepatches, we will have to unload the old version and load
the new version later.
2. Any conflict with the off-band livepatches and regular livepatches will
be difficult to manage. IOW, we kind removed the benefit of cumulative
livepatches. For example, what shall we do if we really need two fixes
to the same kernel functions: one from the original branch, the other
from the off-band branch?

Thanks,
Song