Le 02/12/2022 à 02:38, Thomas Gleixner a écrit :
>
>>> Alternatively, instead of splitting the module address space, the
>>> allocation mechanism can keep track of the types (text, data, rodata)
>>> and manage large mapping blocks per type. There are pros and cons for
>>> both approaches, so that needs some thought.
>>
>> AFAICT, the new allocator (let's call it module_alloc_new here)
>> requires quite some different logic than the existing vmalloc logic (or
>> module_alloc logic):
>
> Obviously.
>
>> 1. vmalloc is at least PAGE_SIZE granularity; while ftrace, bpf etc would
>> benefit from a much smaller granularity.
>
> Even modules can benefit from that. The fact that modules have all
> sections (text, data, rodata) page aligned and page granular is not due
> to an requirement of modules, it's so because that's how module_alloc()
> works and the module layout has been adopted to it.
Sections are page aligned only when STRICT_MODULE_RWX is selected.
See commit 3b5be16c7e90 ("modules: page-align module section allocations
only for arches supporting strict module rwx")
Today it is implemented as follows:
static inline unsigned int strict_align(unsigned int size)
{
if (IS_ENABLED(CONFIG_STRICT_MODULE_RWX))
return PAGE_ALIGN(size);
else
return size;
}
Christophe
