You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Read backported klp capabilities from <linux/livepatch.h>
Normally kpatch-build infers a kernel's klp API's properties
from KERNEL_VERSION, for patch-generation strategy decisions
like support_klp_replace() and use_klp_arch(), and possibly
other future developments.
There's already one exception to this, for RHEL kernels,
and as the support for more distros clutters kpatch-build,
some of them may also diverge from the version-indicated
semantics and need special handling.
Site-specific builds (aka frankenkernels) may also require
such adaption, which can complicate maintenance, or force
per-version forks of kpatch.
To avoid this, read optional override hints about backported
klp capabilities from <linux/livepatch.h>, when a simple
version check would give the wrong answer.
Such annotations would never be needed for kernels which inherit
their klp implementation from upstream, just for custom codebases
which extend it, by backport or otherwise.
For example, some of google's kernels report 4.15 but have 5.8ish
klp semantics.
This allows kpatch to avoid forking for such cases, and
the target kernel is always the source of truth.
But rather than just inferring from its KERNEL_VERSION, hints from
its <linux/livepatch.h>, used by nothing but kpatch, steer its logic.
I'm not suggesting RHEL-specific logic be dropped, merely avoiding
further unnecessary coupling between two changesets (kernel & kpatch)
when such API evolution happens in the future.
The proliferation of distro-specific build-from-source cases is
less avoidable, but is more localized, so less problematic.
Signed-off-by: Pete Swain <swine@google.com>
0 commit comments