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

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

[Song Liu]

Add a sample module that demonstrates how BPF struct_ops can work
together with kernel livepatch. The module livepatches
cmdline_proc_show() and delegates the output to a BPF struct_ops
callback. When no BPF program is attached, a fallback message is
shown; when a BPF struct_ops program is attached, it controls the
/proc/cmdline output via the bpf_klp_seq_write kfunc.

This builds on the existing livepatch-sample.c pattern but shows how
livepatch and BPF struct_ops can be combined to make livepatched
behavior programmable from userspace.

The module is built when both CONFIG_SAMPLE_LIVEPATCH and
CONFIG_BPF_JIT are enabled.

Signed-off-by: Song Liu <song@kernel.org>
---
 samples/livepatch/Makefile        |   3 +
 samples/livepatch/livepatch-bpf.c | 202 ++++++++++++++++++++++++++++++
 2 files changed, 205 insertions(+)
 create mode 100644 samples/livepatch/livepatch-bpf.c

diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
index 9f853eeb6140..1ab4ecbf1f0f 100644
--- a/samples/livepatch/Makefile
+++ b/samples/livepatch/Makefile
@@ -6,3 +6,6 @@ obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix2.o
 obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-demo.o
 obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-mod.o
 obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-busymod.o
+ifdef CONFIG_BPF_JIT
+obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-bpf.o
+endif
diff --git a/samples/livepatch/livepatch-bpf.c b/samples/livepatch/livepatch-bpf.c
new file mode 100644
index 000000000000..4a702a3b4726
--- /dev/null
+++ b/samples/livepatch/livepatch-bpf.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * livepatch-bpf.c - BPF struct_ops + Kernel Live Patching Sample Module
+ *
+ * Copyright (c) 2026 Meta Platforms, Inc. and affiliates.
+ *
+ * This sample demonstrates how BPF struct_ops can control kernel
+ * behavior through livepatch. The module livepatches cmdline_proc_show()
+ * and delegates output to a BPF struct_ops callback. A BPF program can
+ * then attach to override /proc/cmdline output via the bpf_klp_seq_write
+ * kfunc.
+ *
+ * Example:
+ *
+ * $ insmod livepatch-bpf.ko
+ * $ cat /proc/cmdline
+ * livepatch_bpf: no struct_ops attached
+ *
+ * (attach a BPF struct_ops program implementing set_cmdline, e.g.)
+ *
+ * SEC("struct_ops/set_cmdline")
+ * int BPF_PROG(set_cmdline, struct seq_file *m)
+ * {
+ *     char custom[] = "klp_bpf: custom cmdline\n";
+ *     bpf_klp_seq_write(m, custom, sizeof(custom) - 1);
+ *     return 0;
+ * }
+ *
+ * $ cat /proc/cmdline
+ * klp_bpf: custom cmdline
+ *
+ * $ echo 0 > /sys/kernel/livepatch/livepatch_bpf/enabled
+ * $ cat /proc/cmdline
+ * <your cmdline>
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/bpf.h>
+#include <linux/btf.h>
+#include <linux/btf_ids.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/livepatch.h>
+#include <linux/seq_file.h>
+#include <linux/bpf_verifier.h>
+
+struct klp_bpf_cmdline_ops {
+	int (*set_cmdline)(struct seq_file *m);
+};
+
+static struct klp_bpf_cmdline_ops *active_ops;
+
+/* --- kfunc: allow BPF struct_ops programs to write to seq_file --- */
+
+__bpf_kfunc_start_defs();
+
+__bpf_kfunc void bpf_klp_seq_write(struct seq_file *m,
+				    const char *data, u32 data__sz)
+{
+	seq_write(m, data, data__sz);
+}
+
+__bpf_kfunc_end_defs();
+
+BTF_KFUNCS_START(klp_bpf_kfunc_ids)
+BTF_ID_FLAGS(func, bpf_klp_seq_write)
+BTF_KFUNCS_END(klp_bpf_kfunc_ids)
+
+static const struct btf_kfunc_id_set klp_bpf_kfunc_set = {
+	.owner = THIS_MODULE,
+	.set   = &klp_bpf_kfunc_ids,
+};
+
+/* --- Livepatch replacement for cmdline_proc_show --- */
+
+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);
+
+	seq_printf(m, "%s: no struct_ops attached\n", THIS_MODULE->name);
+	return 0;
+}
+
+static struct klp_func funcs[] = {
+	{
+		.old_name = "cmdline_proc_show",
+		.new_func = livepatch_cmdline_proc_show,
+	}, { }
+};
+
+static struct klp_object objs[] = {
+	{
+		/* name being NULL means vmlinux */
+		.funcs = funcs,
+	}, { }
+};
+
+static struct klp_patch patch = {
+	.mod = THIS_MODULE,
+	.objs = objs,
+};
+
+/* --- struct_ops registration --- */
+
+static int klp_bpf_cmdline_reg(void *kdata, struct bpf_link *link)
+{
+	struct klp_bpf_cmdline_ops *ops = kdata;
+
+	if (cmpxchg(&active_ops, NULL, ops))
+		return -EBUSY;
+
+	return 0;
+}
+
+static void klp_bpf_cmdline_unreg(void *kdata, struct bpf_link *link)
+{
+	WRITE_ONCE(active_ops, NULL);
+}
+
+static int klp_bpf_cmdline_init(struct btf *btf)
+{
+	return 0;
+}
+
+static int klp_bpf_cmdline_init_member(const struct btf_type *t,
+				       const struct btf_member *member,
+				       void *kdata, const void *udata)
+{
+	return 0;
+}
+
+static bool klp_bpf_cmdline_is_valid_access(int off, int size,
+					    enum bpf_access_type type,
+					    const struct bpf_prog *prog,
+					    struct bpf_insn_access_aux *info)
+{
+	return bpf_tracing_btf_ctx_access(off, size, type, prog, info);
+}
+
+static int klp_bpf_cmdline_btf_struct_access(struct bpf_verifier_log *log,
+					     const struct bpf_reg_state *reg,
+					     int off, int size)
+{
+	return -EACCES;
+}
+
+static const struct bpf_verifier_ops klp_bpf_cmdline_verifier_ops = {
+	.is_valid_access = klp_bpf_cmdline_is_valid_access,
+	.btf_struct_access = klp_bpf_cmdline_btf_struct_access,
+};
+
+/* CFI stubs */
+static int klp_bpf_cmdline__set_cmdline(struct seq_file *m)
+{
+	return 0;
+}
+
+static struct klp_bpf_cmdline_ops __bpf_klp_bpf_cmdline_ops = {
+	.set_cmdline = klp_bpf_cmdline__set_cmdline,
+};
+
+static struct bpf_struct_ops bpf_klp_bpf_cmdline_ops = {
+	.verifier_ops = &klp_bpf_cmdline_verifier_ops,
+	.init = klp_bpf_cmdline_init,
+	.init_member = klp_bpf_cmdline_init_member,
+	.reg = klp_bpf_cmdline_reg,
+	.unreg = klp_bpf_cmdline_unreg,
+	.cfi_stubs = &__bpf_klp_bpf_cmdline_ops,
+	.name = "klp_bpf_cmdline_ops",
+	.owner = THIS_MODULE,
+};
+
+/* --- Module init/exit --- */
+
+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;
+
+	return klp_enable_patch(&patch);
+}
+
+static void __exit livepatch_bpf_exit(void)
+{
+}
+
+module_init(livepatch_bpf_init);
+module_exit(livepatch_bpf_exit);
+MODULE_LICENSE("GPL");
+MODULE_INFO(livepatch, "Y");
+MODULE_AUTHOR("Song Liu");
+MODULE_DESCRIPTION("Sample: BPF struct_ops + livepatch integration");
-- 
2.52.0

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

[Song Liu]

On Wed, Apr 15, 2026 at 5:16 PM Song Liu <song@kernel.org> wrote:
>
> Add a sample module that demonstrates how BPF struct_ops can work
> together with kernel livepatch. The module livepatches
> cmdline_proc_show() and delegates the output to a BPF struct_ops
> callback. When no BPF program is attached, a fallback message is
> shown; when a BPF struct_ops program is attached, it controls the
> /proc/cmdline output via the bpf_klp_seq_write kfunc.
>
> This builds on the existing livepatch-sample.c pattern but shows how
> livepatch and BPF struct_ops can be combined to make livepatched
> behavior programmable from userspace.
>
> The module is built when both CONFIG_SAMPLE_LIVEPATCH and
> CONFIG_BPF_JIT are enabled.
>
> Signed-off-by: Song Liu <song@kernel.org>

Forgot to add

Assisted-by: Claude:claude-opus-4-6

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

[Yafang Shao]

On Thu, Apr 16, 2026 at 8:16 AM Song Liu <song@kernel.org> wrote:
>
> Add a sample module that demonstrates how BPF struct_ops can work
> together with kernel livepatch. The module livepatches
> cmdline_proc_show() and delegates the output to a BPF struct_ops
> callback. When no BPF program is attached, a fallback message is
> shown; when a BPF struct_ops program is attached, it controls the
> /proc/cmdline output via the bpf_klp_seq_write kfunc.
>
> This builds on the existing livepatch-sample.c pattern but shows how
> livepatch and BPF struct_ops can be combined to make livepatched
> behavior programmable from userspace.
>
> The module is built when both CONFIG_SAMPLE_LIVEPATCH and
> CONFIG_BPF_JIT are enabled.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
>  samples/livepatch/Makefile        |   3 +
>  samples/livepatch/livepatch-bpf.c | 202 ++++++++++++++++++++++++++++++
>  2 files changed, 205 insertions(+)
>  create mode 100644 samples/livepatch/livepatch-bpf.c
>
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 9f853eeb6140..1ab4ecbf1f0f 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -6,3 +6,6 @@ obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix2.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-demo.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-mod.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-busymod.o
> +ifdef CONFIG_BPF_JIT
> +obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-bpf.o
> +endif
> diff --git a/samples/livepatch/livepatch-bpf.c b/samples/livepatch/livepatch-bpf.c
> new file mode 100644
> index 000000000000..4a702a3b4726
> --- /dev/null
> +++ b/samples/livepatch/livepatch-bpf.c
> @@ -0,0 +1,202 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * livepatch-bpf.c - BPF struct_ops + Kernel Live Patching Sample Module
> + *
> + * Copyright (c) 2026 Meta Platforms, Inc. and affiliates.
> + *
> + * This sample demonstrates how BPF struct_ops can control kernel
> + * behavior through livepatch. The module livepatches cmdline_proc_show()
> + * and delegates output to a BPF struct_ops callback. A BPF program can
> + * then attach to override /proc/cmdline output via the bpf_klp_seq_write
> + * kfunc.
> + *
> + * Example:
> + *
> + * $ insmod livepatch-bpf.ko
> + * $ cat /proc/cmdline
> + * livepatch_bpf: no struct_ops attached
> + *
> + * (attach a BPF struct_ops program implementing set_cmdline, e.g.)
> + *
> + * SEC("struct_ops/set_cmdline")
> + * int BPF_PROG(set_cmdline, struct seq_file *m)
> + * {
> + *     char custom[] = "klp_bpf: custom cmdline\n";
> + *     bpf_klp_seq_write(m, custom, sizeof(custom) - 1);
> + *     return 0;
> + * }
> + *
> + * $ cat /proc/cmdline
> + * klp_bpf: custom cmdline
> + *
> + * $ echo 0 > /sys/kernel/livepatch/livepatch_bpf/enabled
> + * $ cat /proc/cmdline
> + * <your cmdline>
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/bpf.h>
> +#include <linux/btf.h>
> +#include <linux/btf_ids.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/livepatch.h>
> +#include <linux/seq_file.h>
> +#include <linux/bpf_verifier.h>
> +
> +struct klp_bpf_cmdline_ops {
> +       int (*set_cmdline)(struct seq_file *m);
> +};
> +
> +static struct klp_bpf_cmdline_ops *active_ops;
> +
> +/* --- kfunc: allow BPF struct_ops programs to write to seq_file --- */
> +
> +__bpf_kfunc_start_defs();
> +
> +__bpf_kfunc void bpf_klp_seq_write(struct seq_file *m,
> +                                   const char *data, u32 data__sz)
> +{
> +       seq_write(m, data, data__sz);
> +}
> +
> +__bpf_kfunc_end_defs();
> +
> +BTF_KFUNCS_START(klp_bpf_kfunc_ids)
> +BTF_ID_FLAGS(func, bpf_klp_seq_write)
> +BTF_KFUNCS_END(klp_bpf_kfunc_ids)
> +
> +static const struct btf_kfunc_id_set klp_bpf_kfunc_set = {
> +       .owner = THIS_MODULE,
> +       .set   = &klp_bpf_kfunc_ids,
> +};
> +
> +/* --- Livepatch replacement for cmdline_proc_show --- */
> +
> +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);
> +
> +       seq_printf(m, "%s: no struct_ops attached\n", THIS_MODULE->name);
> +       return 0;
> +}
> +
> +static struct klp_func funcs[] = {
> +       {
> +               .old_name = "cmdline_proc_show",
> +               .new_func = livepatch_cmdline_proc_show,
> +       }, { }
> +};
> +
> +static struct klp_object objs[] = {
> +       {
> +               /* name being NULL means vmlinux */
> +               .funcs = funcs,
> +       }, { }
> +};
> +
> +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,

Other than that, it looks good to me:

  Tested-and-acked-by: Yafang Shao <laoar.shao@gmail.com>

[...]

-- 
Regards
Yafang

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

[Song Liu]

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.

For this sample, I guess we are OK either way.

>
> Other than that, it looks good to me:
>
>   Tested-and-acked-by: Yafang Shao <laoar.shao@gmail.com>

Thanks,
Song

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

[Yafang Shao]

On Fri, Apr 17, 2026 at 12:33 AM Song Liu <song@kernel.org> 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.

Right.
Replacement seems to break struct_ops registration and BPF
re-attachment. On the livepatch side, we should add support for the
'livepatch tag' to prevent these types of livepatches from being
replaced ;)

>
> For this sample, I guess we are OK either way.

OK

-- 
Regards
Yafang

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

[Song Liu]

On Fri, Apr 17, 2026 at 12:45 AM Yafang Shao <laoar.shao@gmail.com> wrote:
>
> On Fri, Apr 17, 2026 at 12:33 AM Song Liu <song@kernel.org> 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.
>
> Right.
> Replacement seems to break struct_ops registration and BPF
> re-attachment. On the livepatch side, we should add support for the
> 'livepatch tag' to prevent these types of livepatches from being
> replaced ;)

I somehow knew you were gonna say this. :) But I don't think this
is a strong enough argument (and will probably scare folks more).

Thanks,
Song

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

[Petr Mladek]

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

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

[Song Liu]

On Fri, Apr 17, 2026 at 6:20 AM Petr Mladek <pmladek@suse.com> 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.
> --->     */
>         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?

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?
>
> Would the support of different replace tags help?
> They would allow to replace only livepatches with the same tag.

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

[Yafang Shao]

On Fri, Apr 17, 2026 at 11:52 PM Song Liu <song@kernel.org> wrote:
>
> On Fri, Apr 17, 2026 at 6:20 AM Petr Mladek <pmladek@suse.com> 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

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

[Miroslav Benes]

Hi,

On Wed, 15 Apr 2026, Song Liu wrote:

> Add a sample module that demonstrates how BPF struct_ops can work
> together with kernel livepatch. The module livepatches
> cmdline_proc_show() and delegates the output to a BPF struct_ops
> callback. When no BPF program is attached, a fallback message is
> shown; when a BPF struct_ops program is attached, it controls the
> /proc/cmdline output via the bpf_klp_seq_write kfunc.
> 
> This builds on the existing livepatch-sample.c pattern but shows how
> livepatch and BPF struct_ops can be combined to make livepatched
> behavior programmable from userspace.
> 
> The module is built when both CONFIG_SAMPLE_LIVEPATCH and
> CONFIG_BPF_JIT are enabled.
> 
> Signed-off-by: Song Liu <song@kernel.org>

Interesting. It does not make me comfortable to be honest. Is this 
something we want to advertise through samples?

Sashiko has comments... 
https://sashiko.dev/#/patchset/20260416001628.2062468-1-song%40kernel.org

Miroslav

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

[Song Liu]

On Fri, Apr 17, 2026 at 1:13 AM Miroslav Benes <mbenes@suse.cz> wrote:
>
> Hi,
>
> On Wed, 15 Apr 2026, Song Liu wrote:
>
> > Add a sample module that demonstrates how BPF struct_ops can work
> > together with kernel livepatch. The module livepatches
> > cmdline_proc_show() and delegates the output to a BPF struct_ops
> > callback. When no BPF program is attached, a fallback message is
> > shown; when a BPF struct_ops program is attached, it controls the
> > /proc/cmdline output via the bpf_klp_seq_write kfunc.
> >
> > This builds on the existing livepatch-sample.c pattern but shows how
> > livepatch and BPF struct_ops can be combined to make livepatched
> > behavior programmable from userspace.
> >
> > The module is built when both CONFIG_SAMPLE_LIVEPATCH and
> > CONFIG_BPF_JIT are enabled.
> >
> > Signed-off-by: Song Liu <song@kernel.org>
>
> Interesting. It does not make me comfortable to be honest. Is this
> something we want to advertise through samples?

I can understand your concern. We don't have to add these to the
samples.

> Sashiko has comments...
> https://sashiko.dev/#/patchset/20260416001628.2062468-1-song%40kernel.org

These are valid points.

Thanks,
Song