[PATCH v3 06/13] mm/execmem: introduce execmem_data_alloc()
Christophe Leroy
christophe.leroy at csgroup.eu
Fri Sep 22 00:16:52 PDT 2023
Le 22/09/2023 à 00:52, Song Liu a écrit :
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport <rppt at kernel.org> wrote:
>>
> [...]
>> diff --git a/include/linux/execmem.h b/include/linux/execmem.h
>> index 519bdfdca595..09d45ac786e9 100644
>> --- a/include/linux/execmem.h
>> +++ b/include/linux/execmem.h
>> @@ -29,6 +29,7 @@
>> * @EXECMEM_KPROBES: parameters for kprobes
>> * @EXECMEM_FTRACE: parameters for ftrace
>> * @EXECMEM_BPF: parameters for BPF
>> + * @EXECMEM_MODULE_DATA: parameters for module data sections
>> * @EXECMEM_TYPE_MAX:
>> */
>> enum execmem_type {
>> @@ -37,6 +38,7 @@ enum execmem_type {
>> EXECMEM_KPROBES,
>> EXECMEM_FTRACE,
>
> In longer term, I think we can improve the JITed code and merge
> kprobe/ftrace/bpf. to use the same ranges. Also, do we need special
> setting for FTRACE? If not, let's just remove it.
How can we do that ? Some platforms like powerpc require executable
memory for BPF and non-exec mem for KPROBE so it can't be in the same
area/ranges.
>
>> EXECMEM_BPF,
>> + EXECMEM_MODULE_DATA,
>> EXECMEM_TYPE_MAX,
>> };
>
> Overall, it is great that kprobe/ftrace/bpf no longer depend on modules.
>
> OTOH, I think we should merge execmem_type and existing mod_mem_type.
> Otherwise, we still need to handle page permissions in multiple places.
> What is our plan for that?
>
Christophe
More information about the linux-riscv
mailing list