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

[Thomas Gleixner <tglx@linutronix.de>]

Christophe,

On Wed, Dec 07 2022 at 16:53, Christophe Leroy wrote:
> Le 07/12/2022 à 16:36, Thomas Gleixner a écrit :
>> The "use free space in existing mappings" mechanism is not required to
>> be PMD_SIZE based, right?

Correct. I just used it for the example.

>> Large page size, strict separation:
>> 
>> struct mod_alloc_type_params {
>>     	[MOD_ALLOC_TYPE_TEXT] = {
>>          	.mapto_type	= MOD_ALLOC_TYPE_TEXT,
>>                  .flags		= FLAG_SHARED_PMD | FLAG_SECOND_ADDRESS_SPACE,
>>                  .granularity	= PMD_SIZE,
>>                  .alignment	= MOD_ARCH_ALIGNMENT,
>>                  .start[0]	= MODULES_VADDR,
>>                  .end[0]		= MODULES_END,
>>                  .start[1]	= MODULES_VADDR_2ND,
>>                  .end[1]		= MODULES_END_2ND,
>>                  .pgprot		= PAGE_KERNEL_EXEC,
>>                  .fill		= text_poke,
>>                  .invalidate	= text_poke_invalidate,
>> 	},
>
> Don't restrict implementation to PMD_SIZE only.
>
> On powerpc 8xx:
> - PMD_SIZE is 4 Mbytes
> - Large pages are 512 kbytes and 8 Mbytes.
>
> It even has large pages of size 16 kbytes when build for 4k normal page 
> size.

@granularity takes any size which is valid from the architecture side
and can handle the @pgprot distinctions.

That's why I separated functionality and configuration.

Note, it's not strict compile time configuration. You can either build
it completely dynamic at boot or have a static configuration structure
as compile time default.

That static default might be __initconst for architectures where there
is no boot time detection and change required, but can be __initdata for
those which need to adjust it to the needs of the detected CPU/platform
before feeding it into the module allocator init function.

Does that answer your question?

Thanks,

        tglx