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

[Thomas Gleixner <tglx@linutronix.de>]

Song!

On Wed, Dec 07 2022 at 11:26, Song Liu wrote:
> On Wed, Dec 7, 2022 at 7:36 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>> > I think we can handle all these with a single module_alloc() and a few
>> > module_arch_* functions().
>> struct mod_alloc_type {
>>         unsigned int    mapto_type;
>>         unsigned int    flags;
>>         unsigned int    granularity;
>>         unsigned int    alignment;
>>         unsigned long   start[MOD_MAX_ADDR_SPACES];
>>         unsigned long   end[MOD_MAX_ADDR_SPACES];
>>         pgprot_t        pgprot;
>>         void            (*fill)(void *dst, void *src, unsigned int size);
>>         void            (*invalidate)(void *dst, unsigned int size);
>> };
>
> Yeah, this is a lot better than arch_ functions.

Remember the order of things to worry about: #3 :)

> We probably want two more function pointers here:
>
> int (*protect)(unsigned long addr, int numpages);
> int (*unprotect)(unsigned long addr, int numpages);
>
> These two functions will be NULL for archs that support text_poke;
> while legacy archs use them for set_memory_[ro|x|rw|nx]. Then, I
> think we can get rid of VM_FLUSH_RESET_PERMS.

Depends. You can implement

fill()
	memcpy(...);
        set_memory_ro();

and

invalidate()
	set_memory_rw();
        memset();

as global helpers which can be used by the architecture for the init
struct or used as default for certain types.

> I think I am ready to dive into the code and prepare the first RFC/PATCH.
> Please let me know if there is anything we should discuss/clarify before that.

I think we covered most of it by now, so sure a POC is probably due, but
please yell when you find a gap in step #1 - #3 which we did not cover
yet.

Thanks,

        tglx