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

[Petr Mladek <pmladek@suse.com>]

On Thu 2026-04-16 09:32:46, Song Liu wrote:
> On Thu, Apr 16, 2026 at 12:46 AM Yafang Shao <laoar.shao@gmail.com> wrote:
> [...]
> > > +
> > > +static struct klp_patch patch = {
> > > +       .mod = THIS_MODULE,
> > > +       .objs = objs,
> >
> >   Nit: I suggest enabling the replace flag for this patch to align
> > with the recommended implementation.
> >
> >     .replace = true,
> 
> This is an interesting topic. To fully take advantage of the replace
> feature, we need more work on the BPF side.

IMHO, this brings a synchronization problem. I do not have practical
experience with BPF but I expect that:

   + The BPF program could be loaded only when the related bpf_struct_ops
     is registered.

   + The bpf_struct_ops is registered when the livepatch module is being
     loaded.

   + The new livepatch module would replace the older one when it
     is being loaded.

Now, we would need to load the BPF problem after the bpf_struct_ops
is registered but before the livepatch gets enabled. Otherwise,
the new livepatch would not continue working as the previous one.

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.
--->     */
	return klp_enable_patch(&patch);
}

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?

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?

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

Best Regards,
Petr