From: "Mauricio Vásquez Bernal" <mauricio@kinvolk.io> To: Andrii Nakryiko <andrii.nakryiko@gmail.com> Cc: Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>, Quentin Monnet <quentin@isovalent.com>, Rafael David Tinoco <rafaeldtinoco@gmail.com>, Lorenzo Fontana <lorenzo.fontana@elastic.co>, Leonardo Di Donato <leonardo.didonato@elastic.co> Subject: Re: [PATCH bpf-next v3 1/3] libbpf: split bpf_core_apply_relo() Date: Wed, 12 Jan 2022 09:26:52 -0500 [thread overview] Message-ID: <CAHap4ztB7BWxXX3DerY2AVvV54vdhi+4wgTrrM9RzbiQ9KjhrQ@mail.gmail.com> (raw) In-Reply-To: <CAEf4BzZw2RBPSxE0j8uQd8-75qOfq=iPnhB73ONErsHYUaF+pg@mail.gmail.com> > > -static int bpf_core_apply_relo(struct bpf_program *prog, > > - const struct bpf_core_relo *relo, > > - int relo_idx, > > - const struct btf *local_btf, > > - struct hashmap *cand_cache) > > +static int bpf_core_calc_relo_res(struct bpf_program *prog, > > bpf_core_calc_relo_res is almost indistinguishable from > bpf_core_calc_relo... Let's call this one bpf_core_resolve_relo()? > That's a much better name! Deciding the name of that function was probably the most complicated part of this patch. > > @@ -5636,12 +5627,31 @@ bpf_object__relocate_core(struct bpf_object *obj, const char *targ_btf_path) > > if (!prog->load) > > continue; > > > > - err = bpf_core_apply_relo(prog, rec, i, obj->btf, cand_cache); > > + err = bpf_core_calc_relo_res(prog, rec, i, obj->btf, cand_cache, &targ_res); > > if (err) { > > pr_warn("prog '%s': relo #%d: failed to relocate: %d\n", > > prog->name, i, err); > > goto out; > > } > > + > > + if (rec->insn_off % BPF_INSN_SZ) > > + return -EINVAL; > > + insn_idx = rec->insn_off / BPF_INSN_SZ; > > + /* adjust insn_idx from section frame of reference to the local > > + * program's frame of reference; (sub-)program code is not yet > > + * relocated, so it's enough to just subtract in-section offset > > + */ > > + insn_idx = insn_idx - prog->sec_insn_off; > > + if (insn_idx >= prog->insns_cnt) > > + return -EINVAL; > > + insn = &prog->insns[insn_idx]; > > this is sort of like sanity checks, let's do them before the core_calc > step, so after that it's a clean sequence of calc_relo + pathc_insn? > Makes sense. > > @@ -1177,18 +1152,18 @@ static void bpf_core_dump_spec(const char *prog_name, int level, const struct bp > > * between multiple relocations for the same type ID and is updated as some > > * of the candidates are pruned due to structural incompatibility. > > */ > > -int bpf_core_apply_relo_insn(const char *prog_name, struct bpf_insn *insn, > > - int insn_idx, > > - const struct bpf_core_relo *relo, > > - int relo_idx, > > - const struct btf *local_btf, > > - struct bpf_core_cand_list *cands, > > - struct bpf_core_spec *specs_scratch) > > +int bpf_core_calc_relo_insn(const char *prog_name, > > please update the comment for this function, it's not "CO-RE relocate > single instruction" anymore, it's more like "Calculate CO-RE > relocation target result" or something along those lines. > Updated with your suggestion. > > @@ -1223,12 +1198,12 @@ int bpf_core_apply_relo_insn(const char *prog_name, struct bpf_insn *insn, > > /* TYPE_ID_LOCAL relo is special and doesn't need candidate search */ > > if (relo->kind == BPF_CORE_TYPE_ID_LOCAL) { > > /* bpf_insn's imm value could get out of sync during linking */ > > - memset(&targ_res, 0, sizeof(targ_res)); > > - targ_res.validate = false; > > - targ_res.poison = false; > > - targ_res.orig_val = local_spec->root_type_id; > > - targ_res.new_val = local_spec->root_type_id; > > - goto patch_insn; > > + memset(targ_res, 0, sizeof(*targ_res)); > > + targ_res->validate = true; > > hm.. original code sets it to false here, please don't regress the logic > ops, I introduced this by mistake while rebasing.
next prev parent reply other threads:[~2022-01-12 14:27 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-12-17 18:56 [PATCH bpf-next v3 0/3] libbpf: Implement BTFGen Mauricio Vásquez 2021-12-17 18:56 ` [PATCH bpf-next v3 1/3] libbpf: split bpf_core_apply_relo() Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal [this message] 2021-12-17 18:56 ` [PATCH bpf-next v3 2/3] libbpf: Implement changes needed for BTFGen in bpftool Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal 2021-12-17 18:56 ` [PATCH bpf-next v3 3/3] bpftool: Implement btfgen Mauricio Vásquez 2021-12-23 0:33 ` Andrii Nakryiko 2022-01-12 14:26 ` Mauricio Vásquez Bernal 2021-12-17 23:11 ` [PATCH bpf-next v3 0/3] libbpf: Implement BTFGen Daniel Borkmann 2021-12-20 22:43 ` Mauricio Vásquez Bernal
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHap4ztB7BWxXX3DerY2AVvV54vdhi+4wgTrrM9RzbiQ9KjhrQ@mail.gmail.com \ --to=mauricio@kinvolk.io \ --cc=andrii.nakryiko@gmail.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=daniel@iogearbox.net \ --cc=leonardo.didonato@elastic.co \ --cc=lorenzo.fontana@elastic.co \ --cc=netdev@vger.kernel.org \ --cc=quentin@isovalent.com \ --cc=rafaeldtinoco@gmail.com \ --subject='Re: [PATCH bpf-next v3 1/3] libbpf: split bpf_core_apply_relo()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).