Re: [PATCH] riscv: net: bpf: add bpf_jit_supports_private_stack()

Re: [PATCH] riscv: net: bpf: add bpf_jit_supports_private_stack()

[Chen Pei]

Hi JaeJoon,

Thanks for the report. I have been looking at what still blocks
sched_ext on riscv64, and the private stack is indeed an important part
of it.

> $ sudo ./build/bin/scx_simple
> libbpf: prog 'simple_dispatch': BPF program load failed: -EACCES
> libbpf: prog 'simple_dispatch': -- BEGIN PROG LOAD LOG --
> Private stack not supported by jit

I don't think we can take the hook on its own, though.

The other architectures paid for this with real JIT work rather than
with the hook alone: arm64 (6c17a882d380), x86 (7d1cd70d4b16) and
powerpc64 (156d985123b6) each added the per-CPU allocation with
overflow/underflow guard regions, the prologue work that puts the
program on that stack, and the guard check plus free on the program
free path.

> It seems that it should be defined in the same way in RISCV as well.

Defining it the same way means that JIT work, not just the hook. With
the hook alone the verifier would let these programs load while riscv64
still runs them on the per-task stack and has no guard region, turning
the clean -EACCES above into a silent stack overflow.

Going through those three commits, this is what I expect the riscv64
side to need, and I plan to post it as an RFC series:

  1) per-CPU private stack allocation with overflow/underflow guard
     regions, plus the guard check and free_percpu() on program free;
  2) pointing BPF_REG_FP (S5) at priv_sp + the program's stack size
     while leaving SP on the kernel stack, the way arm64 does;
  3) emitting the per-CPU lookup that produces that pointer after the
     tail-call entry point, since RV_TAILCALL_OFFSET is a constant
     added to the target program's bpf_func;
  4) bpf_jit_supports_private_stack() returning true only once the
     above is in place.

Aiming to send RFC v1 within the next couple of weeks. JaeJoon, I hope
we can go over the testing together once it is posted.

Thanks,
Pei