On Tue, Aug 31, 2021 at 7:59 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Tue, Aug 31, 2021 at 7:27 PM Kumar Kartikeya Dwivedi > <memxor@xxxxxxxxx> wrote: > > > > @@ -5327,6 +5340,7 @@ bpf_object__relocate_data(struct bpf_object *obj, struct bpf_program *prog) > > > > ext = &obj->externs[relo->sym_off]; > > > > insn[0].src_reg = BPF_PSEUDO_KFUNC_CALL; > > > > insn[0].imm = ext->ksym.kernel_btf_id; > > > > + insn[0].off = ext->ksym.offset; > > > > > > Just a few lines above we use insn[1].imm = > > > ext->ksym.kernel_btf_obj_fd; for EXT_KSYM (for variables). Why are you > > > inventing a new form if we already have a pretty consistent pattern? > > > > > > > That makes sense. This is all new to me, so I went with what was described in > > e6ac2450d6de (bpf: Support bpf program calling kernel function), but I'll rework > > it to encode the btf fd like that in the next spin. It also makes the everything > > far simpler. > > Hmm. kfunc call is a call insn. There is no imm[1]. Doh, right :( Never mind, we'll need to use fd_array for this. Either way, I don't think hashmap use is warranted here to find a BTF slot. Let's just do linear search, it's not like we are going to have thousands of module BTFs used by any single BPF program, right?
