Re: [PATCH 1/3] perf/bpf: Remove prologue generation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 13, 2022 at 09:57:15PM -0800, Andrii Nakryiko wrote:
> On Sun, Feb 13, 2022 at 7:02 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> >
> > On Thu, Feb 10, 2022 at 09:28:51PM -0800, Andrii Nakryiko wrote:
> > > On Thu, Feb 10, 2022 at 1:31 PM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
> > > >
> > > > On Thu, Feb 10, 2022 at 04:18:10PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > Em Sun, Jan 23, 2022 at 11:19:30PM +0100, Jiri Olsa escreveu:
> > > > > > Removing code for ebpf program prologue generation.
> > > > > >
> > > > > > The prologue code was used to get data for extra arguments specified
> > > > > > in program section name, like:
> > > > > >
> > > > > >   SEC("lock_page=__lock_page page->flags")
> > > > > >   int lock_page(struct pt_regs *ctx, int err, unsigned long flags)
> > > > > >   {
> > > > > >          return 1;
> > > > > >   }
> > > > > >
> > > > > > This code is using deprecated libbpf API and blocks its removal.
> > > > > >
> > > > > > This feature was not documented and broken for some time without
> > > > > > anyone complaining, also original authors are not responding,
> > > > > > so I'm removing it.
> > > > >
> > > > > So, the example below breaks, how hard would be to move the deprecated
> > > > > APIs to perf like was done in some other cases?
> > > > >
> > >
> > > Just copy/pasting libbpf code won't work. But there are three parts:
> > >
> > > 1. bpf_(program|map|object)__set_priv(). There is no equivalent API,
> > > but perf can maintain this private data by building hashmap where the
> > > key is bpf_object/bpf_map/bpf_program pointer itself. Annoying but
> > > very straightforward to replace.
> > >
> > > 2. For prologue generation, bpf_program__set_prep() doesn't have a
> > > direct equivalent. But program cloning and adjustment of the code can
> > > be achieved through bpf_program__insns()/bpf_program__insn_cnt() API
> > > to load one "prototype" program, gets its underlying insns and clone
> > > programs as necessary. After that, bpf_prog_load() would be used to
> > > load those cloned programs into kernel.
> >
> > hm, I can't see how to clone a program.. so we need to end up with
> > several copies of the single program defined in the object.. I can
> > get its intructions with bpf_program__insns, but how do I add more
> > programs with these instructions customized/prefixed?
> 
> You can't add those clones back to bpf_object, of course. But after
> grabbing (and modifying) instructions, you can use bpf_prog_load()
> low-level API to create BPF programs and get their FDs back. You'll
> have to keep track of those prog FDs separately from libbpf' struct
> bpf_object.

ok so loaded on the side with bpf_prog_load

thanks,
jirka



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux