On Thu, Jun 08, 2023 at 09:41:16PM +0300, Mike Rapoport wrote:

On Tue, Jun 06, 2023 at 11:21:59AM -0700, Song Liu wrote:

quoted

On Mon, Jun 5, 2023 at 3:09 AM Mark Rutland [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

Can you give more detail on what parameters you need? If the only extra
parameter is just "does this allocation need to live close to kernel
text", that's not that big of a deal.

My thinking was that we at least need the start + end for each caller. That
might be it, tbh.

Do you mean that modules will have something like

      jit_text_alloc(size, MODULES_START, MODULES_END);

and kprobes will have

      jit_text_alloc(size, KPROBES_START, KPROBES_END);
?

Yes.

How about we start with two APIs:
     jit_text_alloc(size);
     jit_text_alloc_range(size, start, end);

AFAICT, arm64 is the only arch that requires the latter API. And TBH, I am
not quite convinced it is needed.

 
Right now arm64 and riscv override bpf and kprobes allocations to use the
entire vmalloc address space, but having the ability to allocate generated
code outside of modules area may be useful for other architectures.

Still the start + end for the callers feels backwards to me because the
callers do not define the ranges, but rather the architectures, so we still
need a way for architectures to define how they want allocate memory for
the generated code.

So, the start + end just comes from the need to keep relative pointers
under a certain size. I think this could be just a flag, I see no reason
to expose actual addresses here.