On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > So perhaps the answer is to have text_alloc() not with a 'where'
> > argument but with a 'why' argument. Or more simply, just have separate
> > alloc/free APIs for each case, with generic versions that can be
> > overridden by the architecture.
>
> Well, there only seem to be 2 cases here, either the pointer needs to
> fit in some immediate displacement, or not.
>
> On x86 we seem have the advantage of a fairly large immediate
> displacement as compared to many other architectures (due to our
> variable sized instructions). And thus have been fairly liberal with our
> usage of it (also our indirect jmps/calls suck, double so with
> RETCH-POLINE).
>
> Still, the indirect jump, as mentioned by Russel should work for
> arbitrarily placed code for us too.
>
>
> So I'm thinking that something like:
>
> enum ptr_type {
> immediate_displacement,
> absolute,
> };
>
> void *text_alloc(unsigned long size, enum ptr_type type)
> {
> unsigned long vstart = VMALLOC_START;
> unsigned long vend = VMALLOC_END;
>
> if (type == immediate_displacement) {
> vstart = MODULES_VADDR;
> vend = MODULES_END;
> }
>
> return __vmalloc_node_range(size, TEXT_ALIGN, vstart, vend,
> GFP_KERNEL, PAGE_KERNEL_EXEC, 0,
> NUMA_NO_NODE, _RET_IP_);
> }
>
> void text_free(void *ptr)
> {
> vfree(ptr);
> }
>
> Should work for all cases. Yes, we might then want something like a per
> arch:
>
> {BPF,FTRACE,KPROBE}_TEXT_TYPE
>
> to help with text_alloc() usage in generic code, but I think
> fundamentally, there's only these two options.
There is one arch (nios2), which uses a regular kzalloc(). This means
that both text_alloc() and text_memfree() need to be weaks symbols and
nios2 needs to have overriding text.c to do its thing.
/Jarkko
