On Mon, Mar 25, 2024 at 08:13:10PM +0100, Puranjay Mohan wrote: > On Mon, Mar 25, 2024 at 8:10 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > On Mon, Mar 25, 2024 at 03:54:34PM +0000, Puranjay Mohan wrote: > > > LLVM generates bpf_addr_space_cast instruction while translating > > > pointers between native (zero) address space and > > > __attribute__((address_space(N))). The addr_space=0 is reserved as > > > bpf_arena address space. > > > > > > rY = addr_space_cast(rX, 0, 1) is processed by the verifier and > > > converted to normal 32-bit move: wX = wY > > > > > > rY = addr_space_cast(rX, 1, 0) has to be converted by JIT. > > > > > > Signed-off-by: Puranjay Mohan <puranjay12@xxxxxxxxx> > > > > Doesn't compile for allmodconfig: > > ../arch/riscv/net/bpf_jit_comp64.c:1086:7: error: call to undeclared function 'insn_is_cast_user'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > > > > Cheers, > > Conor. > > Yes, > I mentioned in the cover letter that a patch is required. > It just got merged in bpf-next/master: > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=770546ae9f4c1ae1ebcaf0874f0dd9631d77ec97 > > So, rebasing on the latest bpf-next/master should fix the issue. Ah, I see now that there was a mention in the cover letter that I did not see first time around. Bjorn, do you think there's anything we can do about these kinda misleading CI failures for bpf stuff? Some stuff that touches bpf definitely is worth us building, but should we try and build it on top of the bpf tree instead?
Attachment:
signature.asc
Description: PGP signature
