Re: [PATCH] samples/livepatch: Add BPF struct_ops integration sample

[Yafang Shao]

On Fri, Apr 17, 2026 at 11:52 PM Song Liu <song@xxxxxxxxxx> wrote:
>
> On Fri, Apr 17, 2026 at 6:20 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
> >
> > On Thu 2026-04-16 09:32:46, Song Liu wrote:
> [...]
> > Let' use the code from this patch:
> >
> > static int __init livepatch_bpf_init(void)
> > {
> >         int ret;
> >
> >         ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS,
> >                                         &klp_bpf_kfunc_set);
> >         ret = ret ?: register_bpf_struct_ops(&bpf_klp_bpf_cmdline_ops,
> >                                              klp_bpf_cmdline_ops);
> >         if (ret)
> >                 return ret;
> >
> > --->    /*
> > --->     * We would need to wait here until the BPF program gets loaded.
> > --->     * for the new bpf_struct_ops in this new livepatch.
> > --->     */

No waiting is necessary. If the BPF program is not attached, the
default logic can be executed instead. Consider Song's test case: we
can handle it as follows.

static int livepatch_cmdline_proc_show(struct seq_file *m, void *v)
{
    struct klp_bpf_cmdline_ops *ops = READ_ONCE(active_ops);

    if (ops && ops->set_cmdline)
        return ops->set_cmdline(m);

    // If no BPF program is attached, the default kernel function runs.
    return cmdline_proc_show(m, v);
}

However, as Song explained below, if we want atomic replace to work,
we may need to wait for the new BPF program here. But that would make
the combination of livepatch and BPF more complex.

Currently, on our production servers, we handle this through a user
script, such as:

  stop_traffic_relying_on_livepatch_bpf
  kpatch load new-livepatch-bpf-module.ko
  reattach_the_bpf_program
  start_the_traffic_again

Although this approach requires restarting the affected traffic, other
services running on the same server remain unaffected.

> >         return klp_enable_patch(&patch);
> > }
>
> Yes, something in this direction is needed to make atomic replace work.
> We have no plan to use this in production. I will let Yafang figure out
> his plan.
>
> > Or maybe, the bpf_struct_ops can be _allocated dynamically_ and
> > the pointer might be _passed via shadow variables_.
> >
> > One problem is that shadow variables would add another overhead
> > and need not be suitable for hot paths.
> >
> >
> > Anyway, I think that I have similar feelings as Miroslav.
> > The combination of livepatches and BPF programs increases
> > the complexity for all involved parties: core kernel maintainers,
> > livepatch and BPF program authors, and system maintainers.
> >
> > Do we really want to propagate it?
> > Is there any significant advantage in combining these two, please?
> > Is it significantly easier to write BPF program then a livepatch?
> > Is it significantly easier to update BPF programs then livepatches?

This is an important feature for avoiding server restarts,
particularly in a VM host environment. Since only one VM on the host
may be affected by this feature, we can deploy it rapidly without
impacting other VMs on the same host.

>
> Some combination like this will probably make sense for Yafang's use
> cases. But I agree maybe we don't want this in the samples, because
> it is indeed complicated and could be more dangerous.
>
> Thanks,
> Song
>
> > IMHO, the livepatches should allow enough flexibility. And it might
> > be easier to update the livepatch when needed.
> >
> > Or do you install more independent livepatches as well?

If we want certain livepatches to be persistent on the server, we will
need to support independent livepatches — and we do have such use
cases.

> >
> > Would the support of different replace tags help?
> > They would allow to replace only livepatches with the same tag.

Right, it will help.

-- 
Regards
Yafang