On Fri, Apr 17, 2026 at 6:20 AM Petr Mladek <[email protected]> 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.
