Hi,
Le 18/06/2021 à 19:32, Andrii Nakryiko a écrit :
On Fri, Jun 18, 2021 at 2:13 AM Alex Ghiti <alex@xxxxxxxx> wrote:
Hi guys,
First, pardon my ignorance regarding BPF, the following might be silly.
We were wondering here
https://patchwork.kernel.org/project/linux-riscv/patch/20210615004928.2d27d2ac@xhacker/
if BPF programs that now have the capability to call kernel functions
(https://lwn.net/Articles/856005/) can also call modules function or
vice-versa?
Not yet, but it was an explicit design consideration and there was
public interest just recently. So I'd say this is going to happen
sooner rather than later.
The underlying important fact is that in riscv, we are limited to 2GB
offset to call functions and that restricts where we can place modules
and BPF regions wrt kernel (see Documentation/riscv/vm-layout.rst for
the current possibly wrong layout).
So should we make sure that modules and BPF lie in the same 2GB region?
Based on the above and what you are explaining about 2GB limits, I'd
say yes?.. Or alternatively those 2GB restrictions might perhaps be
lifted somehow?
Actually we have this limit when we have PC-relative branch which is our
current code model. To better understand what happened, I took a look at
our JIT implementation and noticed that BPF_CALL are implemented using
absolute addressing so for this pseudo-instruction, the limit I evoked
does not apply. How are the kernel (and modules) symbol addresses
resolved? Is it relative or absolute? Is there then any guarantee that a
kernel or module call will always emit a BPF_CALL?
Thanks Alexei and Andrii for your answers,
Alex
Thanks,
Alex
