On Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote:

On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport [off-list ref] wrote:

quoted

quoted

quoted

I'm looking at execmem_types more as definition of the consumers, maybe I
should have named the enum execmem_consumer at the first place.

I think looking at execmem_type from consumers' point of view adds
unnecessary complexity. IIUC, for most (if not all) archs, ftrace, kprobe,
and bpf (and maybe also module text) all have the same requirements.
Did I miss something?

It's enough to have one architecture with different constrains for kprobes
and bpf to warrant a type for each.

AFAICT, some of these constraints can be changed without too much work.

But why?
I honestly don't understand what are you trying to optimize here. A few
lines of initialization in execmem_info?
What is the advantage in forcing architectures to have imposed limits on
kprobes or bpf allocations?

quoted

Where do you see unnecessary complexity?

quoted

IOW, we have

enum execmem_type {
        EXECMEM_DEFAULT,
        EXECMEM_TEXT,
        EXECMEM_KPROBES = EXECMEM_TEXT,
        EXECMEM_FTRACE = EXECMEM_TEXT,
        EXECMEM_BPF = EXECMEM_TEXT,      /* we may end up without
_KPROBE, _FTRACE, _BPF */
        EXECMEM_DATA,  /* rw */
        EXECMEM_RO_DATA,
        EXECMEM_RO_AFTER_INIT,
        EXECMEM_TYPE_MAX,
};

Does this make sense?

How do you suggest to deal with e.g. riscv that has separate address spaces
for modules, kprobes and bpf?

IIUC, modules and bpf use the same address space on riscv

Not exactly, bpf is a subset of modules on riscv.

while kprobes use vmalloc address.

The whole point of using the entire vmalloc for kprobes is to avoid
pollution of limited modules space.
 

Thanks,
Song

-- 
Sincerely yours,
Mike.