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

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

 



Hi Thomas,

Thanks for all these suggestions!

On Thu, Dec 1, 2022 at 5:38 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>

[...] (everything snipped here makes perfect sense).

>
> You have to be aware, that the rodata space needs to be page granular
> while text and data can really aggregate below the page alignment, but
> again might have different alignment requirements.

I don't quite follow why rodata space needs to be page granular. If text can
go below page granular, rodata should also do that, no?

>
> So you need a configuration mechanism which allows to specify per type:
>
>    - Initial mapping type (RX, RWX, RW)
>    - Alignment
>    - Granularity
>    - Address space restrictions

[...]

>
> Step 1:
>

These steps are really helpful. Thanks!
[...]
>
> For text that's obviously module_write_text(), but for the [ro]data
> mappings memcpy() is still fine. For the rodata mapping you need
> set_memory_ro() right in the module prepare stage and for the
> ro_after_init_data() you do that after the module init function returns
> success, which is pretty much what the code does today.

I guess this is related to rodata needs to be page granular? But I
don't think I got the idea. Do we allow rodata and rwdata share the
same 2MB page? ro_after_init_data seems trickier.

>
> Step 5:
>
[...]

>
> Linus once said:
>
>   "Bad programmers worry about the code. Good programmers worry about
>    data structures and their relationships."
>
> He's absolutely right. Here is my version of it:
>
>   The order of things to worry about:
>
>       1) Problem analysis
>       2) Concepts
>       3) Data structures and their relationships
>       4) Code
>
>       #1 You need to understand the problem fully to come up with
>          concepts
>
>       #2 Once you understand the problem fully you can talk about
>          concepts to solve it
>
>       #3 Maps the concept to data structures and forms relationships
>
>       #4 Is the logical consequence of #1 + #2 + #3 and because your
>          concept makes sense, the data structures and their
>          relationships are understandable, the code becomes
>          understandable too.
>
>       If any of the steps finds a gap in the previous ones, then you
>       have to go back and solve those first.
>
> Any attempt to reorder the above is putting the cart before the horse
> and a guarantee for failure.

Thanks for these advices! They would help me for many years.

>
> Now go back and carefully read up on what I wrote above and in my
> previous mail.
>
> The previous mail was mostly about #1 to explain the problem as broad as
> possible and an initial stab at #2 suggesting concepts to solve it.
>
> This one is still covering some aspects of #1, but it is mostly about #2
> and more focussed on particular aspects of the concept. If you look at
> it carefully then you find some bits which map to #3 but still at the
> conceptual level.
>
> Did I talk about code or implementation details?
>
> Not at all and I'm not going to do so before #1 and #2 are agreed
> on. The above pseudo code snippets are just for illustration and I used
> them because I was too lazy to write a novel, but they all are still at
> the conceptual level.
>
> Now you can rightfully argue that if you stich those snippets together
> then they form a picture which outlines the implementation, but that's
> the whole purpose of this exercise, right?

I guess I will do my homework, and come back with as much information
as possible for #1 + #2 + #3. Then, we can discuss whether it makes
sense at all.

Does this sound like the right approach?

Thanks,
Song




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux