On Thu, Apr 13, 2023 at 12:14 PM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > On Thu, Apr 13, 2023 at 01:06:32AM +0200, Ilya Leoshkevich wrote: > > test_ksyms_module fails to emit a kfunc call targeting a module on > > s390x, because the verifier stores the difference between kfunc > > address and __bpf_call_base in bpf_insn.imm, which is s32, and modules > > are roughly (1 << 42) bytes away from the kernel on s390x. > > > > Fix by keeping BTF id in bpf_insn.imm for BPF_PSEUDO_KFUNC_CALLs, > > and storing the absolute address in bpf_kfunc_desc. > > > > Introduce bpf_jit_supports_far_kfunc_call() in order to limit this new > > behavior to the s390x JIT. Otherwise other JITs need to be modified, > > which is not desired. > > > > Introduce bpf_get_kfunc_addr() instead of exposing both > > find_kfunc_desc() and struct bpf_kfunc_desc. > > > > In addition to sorting kfuncs by imm, also sort them by offset, in > > order to handle conflicting imms from different modules. Do this on > > all architectures in order to simplify code. > > > > Factor out resolving specialized kfuncs (XPD and dynptr) from > > fixup_kfunc_call(). This was required in the first place, because > > fixup_kfunc_call() uses find_kfunc_desc(), which returns a const > > pointer, so it's not possible to modify kfunc addr without stripping > > const, which is not nice. It also removes repetition of code like: > > > > if (bpf_jit_supports_far_kfunc_call()) > > desc->addr = func; > > else > > insn->imm = BPF_CALL_IMM(func); > > > > and separates kfunc_desc_tab fixups from kfunc_call fixups. > > > > Suggested-by: Jiri Olsa <olsajiri@xxxxxxxxx> > > Signed-off-by: Ilya Leoshkevich <iii@xxxxxxxxxxxxx> > > Acked-by: Jiri Olsa <jolsa@xxxxxxxxxx> Applied. Should be able to delete a few entries from DENYLIST.s390x, right?
