Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs

[Christophe Leroy <christophe.leroy@csgroup.eu>]

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