Re: [PATCH v3 06/13] mm/execmem: introduce execmem_data_alloc()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Le 22/09/2023 à 00:52, Song Liu a écrit :
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport <rppt@xxxxxxxxxx> 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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux