On Tue, 2022-11-15 at 17:20 -0800, Song Liu wrote:
> To clarify, are you suggesting we need this logic in this set? I
> would
> rather wait until we handle module code. This is because BPF JIT uses
> module_alloc() for archs other than x86_64. So the fall back of
> execmem_alloc() for these archs would be module_alloc() or
> something similar. I think it is really weird to do something like
>
> void *execmem_alloc(size_t size)
> {
> #ifdef CONFIG_SUPPORT_EXECMEM_ALLOC
> ...
> #else
> return module_alloc(size);
> #endif
> }
>
> WDYT?
Hmm, that is a good point. It looks like it's plugged in backwards.
Several people in the past have expressed that all the text users
calling into *module*_alloc() also is a little wrong. So I think in
some finished future, each architecture would have an execmem_alloc()
arch breakout of some sort that modules could use instead of it's
module_alloc() logic. So basically all the module_alloc() arch
specifics details of location and PAGE_FOO would move to execmem.
I guess the question is how to get there. Calling into module_alloc()
does the job but looks wrong. There are a lot of module_alloc()s, but
what about implementing an execmem_alloc() for each bpf jit
architecture that doesn't match the existing default version. It
shouldn't be too much code. I think some of them will work with just
the EXEC_MEM_START/END heuristic and wont need a breakout.
But if this thing just works for x86 BPF JITs, I'm not sure we can say
we have unified anything...
