[PATCH bpf-next v2 2/2] bpf,riscv: Implement bpf_addr_space_cast instruction

[Conor Dooley]

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 at kernel.org> 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 at gmail.com>
> >
> > 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20240325/e35f93d0/attachment.sig>