Hi Yafang, On Thu, 2 Apr 2026 17:26:03 +0800 Yafang Shao <[email protected]> wrote:
> Livepatching allows for rapid experimentation with new kernel features > without interrupting production workloads. However, static livepatches lack > the flexibility required to tune features based on task-specific attributes, > such as cgroup membership, which is critical in multi-tenant k8s > environments. Furthermore, hardcoding logic into a livepatch prevents > dynamic adjustments based on the runtime environment. > > To address this, we propose a hybrid approach using BPF. Our production use > case involves: > > 1. Deploying a Livepatch function to serve as a stable BPF hook. > > 2. Utilizing bpf_override_return() to dynamically modify the return value > of that hook based on the current task's context. First of all, I don't like this approach to test a new feature in the kernel, because it sounds like allowing multiple different generations of implementations to coexist simultaneously. The standard kernel code is not designed to withstand such implementations. For example, if you implement a well-designed framework in a specific subsystem, like Schedext, which allows multiple implementations extended with BPF to coexist, there's no problem (at least it's debatable). But if it is for any function, it is dangerous feature. Bugs that occur in kernels that use this functionality cannot be addressed here. They need to be treated the same way as out-of-tree drivers or forked kernels. I mean, add a tainted flag for this feature. And we don't care of it. > > A significant challenge arises when atomic-replace is enabled. In this > mode, deploying a new livepatch changes the target function's address, > forcing a re-attachment of the BPF program. This re-attachment latency is > unacceptable in critical paths, such as those handling networking policies. > > To solve this, we introduce a hybrid livepatch mode that allows specific > patches to remain non-replaceable, ensuring the function address remains > stable and the BPF program stays attached. Can you share your actual problem to be solved? If the specific problem and the specific subsystem are clear, I think there is room to discuss it with the subsystem maintainer. > > Furthermore, this mechanism provides a lower-maintenance alternative to > out-of-tree BPF hooks. Given the complexities of upstreaming custom BPF > hooks (e.g., [0], [1]), this hybrid mode allows for the maintenance of > stable, minimal hook points via livepatching with significantly reduced > maintenance burden. Maintenance cost is the same. We need to add out-of-tree BPF hooks on source code. Maybe deploying cost will be reduced. Thank you, > > Link: https://lwn.net/Articles/1054030/ [0] > Link: https://lwn.net/Articles/1043548/ [1] > > Yafang Shao (4): > trace: Simplify kprobe overridable function check > trace: Allow kprobes to override livepatched functions > livepatch: Add "replaceable" attribute to klp_patch > livepatch: Implement livepatch hybrid mode > > include/linux/livepatch.h | 2 ++ > kernel/livepatch/core.c | 50 +++++++++++++++++++++++++++++++ > kernel/trace/Kconfig | 14 +++++++++ > kernel/trace/bpf_trace.c | 14 ++++++--- > kernel/trace/trace_kprobe.c | 49 ++++++++++++------------------ > kernel/trace/trace_probe.h | 59 +++++++++++++++++++++++++++---------- > 6 files changed, 139 insertions(+), 49 deletions(-) > > -- > 2.47.3 > -- Masami Hiramatsu (Google) <[email protected]>
