Alexei Starovoitov wrote:
On 3/1/18 12:51 AM, Naveen N. Rao wrote:
Daniel Borkmann wrote:
Worst case if there's nothing better, potentially what one could do in
bpf_prog_get_info_by_fd() is to dump an array of full addresses and
have the imm part as the index pointing to one of them, just unfortunate
that it's likely only needed in ppc64.
Ok. We seem to have discussed a few different aspects in this thread.
Let me summarize the different aspects we have discussed:
1. Passing address of JIT'ed function to the JIT engines:
Two approaches discussed:
a. Existing approach, where the subprog address is encoded as an
offset from __bpf_call_base() in imm32 field of the BPF call
instruction. This requires the JIT'ed function to be within 2GB of
__bpf_call_base(), which won't be true on ppc64, at the least. So,
this won't on ppc64 (and any other architectures where vmalloc'ed
(module_alloc()) memory is from a different, far, address range).
it looks like ppc64 doesn't guarantee today that all of module_alloc()
will be within 32-bit, but I think it should be trivial to add such
guarantee. If so, we can define another __bpf_call_base specifically
for bpf-to-bpf calls when jit is on.
Ok, we prefer not to do that for powerpc (atleast, not for all of
module_alloc()) at this point.
And since option (c) below is not preferable, I think we will implement
what Daniel suggested above. This patchset already handles communicating
the BPF function addresses to the JIT engine, and enhancing
bpf_prog_get_info_by_fd() should address the concerns with bpftool.
- Naveen
